martini with olive draft kaplan martini with olive 00 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
MARTINI with OLIVE draft-kaplan-martini-with-olive-00 PowerPoint Presentation
Download Presentation
MARTINI with OLIVE draft-kaplan-martini-with-olive-00

play fullscreen
1 / 14

MARTINI with OLIVE draft-kaplan-martini-with-olive-00

205 Views Download Presentation
Download Presentation

MARTINI with OLIVE draft-kaplan-martini-with-olive-00

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MARTINI with OLIVEdraft-kaplan-martini-with-olive-00 Hadriel Kaplan

  2. The Problem • Draft-gin handles E.164 • How do we handle: sip:bob@ssp.com sip:1234;ext=567;phone-context=+12125551212@ssp.com • Perceived problems: • Non-E.164’s are not globally unique, so draft-gin won’t work • Can’t expand Contact-URI automagically

  3. The Solution • “Bulk” REGISTER any provisioned AoR, as if the PBX had separately Registered for each one • Contact-routing a la RFC3261 still works • If it would have worked for explicit REGISTERs • The Contact-URI “expansion” is the provisioned AoR user portion • The same that would be provisioned for a separate REGISTER

  4. Example • PBX does a draft-gin REGISTER • SSP has provisioning for bob@ssp.com • INVITE to bob@ssp.com follows rfc3261 Originator SSP PBX REGISTER sip:ssp.comTo: <sip:pbx123@ssp.com>Contact: <sip:192.1.2.3;bnc> INVITEsip:bob@ssp.com INVITEsip:bob@192.1.2.3

  5. Perceived Problems don’t apply • Draft-gin really did Register globally unique AoRs • E.g., sip:+123456789@ssp.com • So now we’re bulk Registering other globally unique AoRs, scoped to the Registered domain (ssp.com) • Just like RFC 3261 would do for any AoR

  6. Comparison with loose-route • Draft-gin/olive follows what happens today for normal Subscribers and for Peering • In both cases, the Req-uri host portion identifies the target host/domain • Draft-olive is the “loose-route” model, except: • Instead of the user portion in the req-uri and the PBX’s target IP in a Route header, they’re in one spot: the Request-URI • Draft-olive only covers AoRs of the Registered-to domain (more on that later)

  7. Open Issues and Topics for Discussion/Yelling

  8. What about bob@ssp.co.nl? • Question: • How does the PBX know the call was for bob@ssp.com and not for bob@ssp.co.nl? (if both are handled) • Answer: it won’t • It wouldn’t have in rfc3261 either, if one REGISTER for bob@ssp.com did more • Really the call is being re-targeted to bob@ssp.com – and we have hist-info for figuring out the original target, right?

  9. Other solutions for bob@ssp.co.nl • The PBX can REGISTER to ssp.co.nl • By definition it knows about ssp.co.nl, so it can REGISTER to ssp.co.nl separately • Or we can define a new URI user parameter named “user-context”: sip:bob;user-context=ssp.co.nl@192.1.2.3 • Why is this legit? Same thing as phone-context really, just for any alphanumeric

  10. “Local Numbers” • Technically RFC 3966 defines “Local Numbers” • The phone-context param defines the scope of the user portion, and the users and any other params are only known to the authority of that context • In practice, things aren’t that simple • the Local-Number syntax is only followed in specific cases; e.g., only within the SSP • the “dial-plan” and knowledge of params is not consistently or fully in one spot • there’s an expired draft for P-Private-Network-Indication, tagging incoming requests as belonging to a specific private context • the scoping model of RFC 3966 creates two tiers of scoping: URI-user and URI level • In short: it’s a mess

  11. A straw-man for how to handle it • How would this “work” if the IP-PBX sent separate, explicit REGISTERs? • In Martini we only care about IP-PBX case • We need a way to REGISTER for a Local-Number • I can only see two ways it could have explicitly REGISTERed for a Local-Number: • It REGISTERed to a specific Domain: e.g., sip:enterprise.com or sip:enterprise.priv.ssp.com • It REGISTERed the AoR: e.g., sip:1234;phone-context=pbx.com@ssp.com

  12. Straw-man continued… • The first way (Register to an explicit domain) doesn’t need a new draft • Just have the IP-PBX REGISTER to that domain, separately from “public” numbers • IP-PBX uses a contact param to segregate inbound requests, if that’s an issue • The second way (Register the AoR) is what draft-olive describes • It can just re-use the draft-gin REGISTER, because there’s no name collision or confusion, so long as the whole user portion remains intact to the IP-PBX

  13. What this means… • The Request-URI reaching the PBX, and presumably any coming from it for a private plan, would be expressed as a rfc3966 Local-Number sip:1234;phone-context=pbx.com@192.1.2.3 • Is that reasonable? • I think so – it has to be distinguished somehow, even in a loose-route model • It could be done with yet-another-header, but what would we set the Request-URI to anyway?

  14. Other Open Issues • Reg-event handling • Can’t really do “normal” reg-event for Local-Numbers – all usernames aren’t known • Need a “Bulk-AoR” syntax/semantics for registration state • What to do about Local-Number user parameters • Some are processed by SSP, some by PBX • In theory only the authority of the phone-context knows what to do with them, but who is that authority??