open plan local number identifier values for enterprises olive draft kaplan martini with olive 02
Skip this Video
Download Presentation
Hadriel Kaplan

Loading in 2 Seconds...

play fullscreen
1 / 10

Hadriel Kaplan - PowerPoint PPT Presentation

  • Uploaded on

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;[email protected] “Local Numbers”.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Hadriel Kaplan' - bevan

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
open plan local number identifier values for enterprises olive draft kaplan martini with olive 02

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

Hadriel Kaplan

the problem
The Problem
  • Draft-gin handles E.164
  • So how do we handle Local Numbers?

sip:1234;[email protected]

local numbers
“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
two ways to handle it
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., or
    • It REGISTERed the AoR: e.g., sip:1234;[email protected]
  • 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
what this means
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;[email protected]

  • 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?
  • PBX does a draft-gin REGISTER
  • SSP has provisioning for *;phone-context=+5 goes to pbx123




REGISTER sip:ssp.comTo: Contact:

INVITEsip:789;[email protected]

INVITEsip:789;[email protected]

non context local numbers
Non-context Local Numbers
  • But what if the PBX doesn’t know about this “phone-context” stuff?
  • Possible solutions:
    • Describe it as a transformation step, to remove phone-context
    • Or require registering to a unique domain name (e.g.,
other open issues
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??