1 / 10

Hadriel Kaplan

Open-plan Local-number Identifier Values for Enterprises (OLIVE) draft-kaplan-martini-with-olive-02. Hadriel Kaplan. The Problem. Draft-gin handles E.164 So how do we handle Local Numbers? sip:1234;phone-context=+12125551212@ssp.com. “Local Numbers”.

bevan
Download Presentation

Hadriel Kaplan

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. Open-plan Local-number Identifier Values for Enterprises (OLIVE)draft-kaplan-martini-with-olive-02 Hadriel Kaplan

  2. The Problem • Draft-gin handles E.164 • So how do we handle Local Numbers? sip:1234;phone-context=+12125551212@ssp.com

  3. “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 nor fully in one spot • the scoping model of RFC 3966 creates two tiers of scoping: URI-user and URI level

  4. Two ways 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 • 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

  5. So… • 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

  6. 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 • It could be done with yet-another-header, but what would we set the Request-URI to anyway?

  7. Example • PBX does a draft-gin REGISTER • SSP has provisioning for *;phone-context=+5 goes to pbx123 Originator SSP PBX REGISTER sip:ssp.comTo: <sip:pbx123@ssp.com>Contact: <sip:192.1.2.3;bnc> INVITEsip:789;ph=+5@ssp.com INVITEsip:789;ph=+5@192.1.2.3

  8. Open Issues

  9. Non-context Local Numbers • But what if the PBX doesn’t know about this “phone-context” stuff? • It’s as if the PBX registered “sip:123@ssp.com” – it’s just a username to it • But not really, because 123@ssp.com may overlap with other Enterprises • Possible solutions: • Describe it as a transformation step, to remove phone-context • Or require registering to a unique domain name (e.g., enterprise.ssp.com)

  10. Other Open Issues • Vermouth handling (how to check the list of AoRs on the Registrar) • Can’t have a simple syntax, because names aren’t fully known by registrar • Answer: use wildcarding • 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