1 / 14

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

MARTINI with OLIVE draft-kaplan-martini-with-olive-00. Hadriel Kaplan. 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

zanthe
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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??

More Related