Presentation is loading. Please wait.

Presentation is loading. Please wait.

Open-plan Local-number Identifier Values for Enterprises (OLIVE) draft-kaplan-martini-with-olive-02 Hadriel Kaplan.

Similar presentations


Presentation on theme: "Open-plan Local-number Identifier Values for Enterprises (OLIVE) draft-kaplan-martini-with-olive-02 Hadriel Kaplan."— 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: 1.It REGISTERed to a specific Domain: e.g., sip:enterprise.com or sip:enterprise.priv.ssp.com 2.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 OriginatorSSPPBX INVITE sip:789;ph=+5@ssp.com INVITE sip:789;ph=+5@192.1.2.3 REGISTER sip:ssp.com To: Contact:

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


Download ppt "Open-plan Local-number Identifier Values for Enterprises (OLIVE) draft-kaplan-martini-with-olive-02 Hadriel Kaplan."

Similar presentations


Ads by Google