Open plan local number identifier values for enterprises olive draft kaplan martini with olive 02
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 (OLIVE)

Local numbers
“Local Numbers” (OLIVE)

  • 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 (OLIVE)

  • 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… (OLIVE)

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

Example (OLIVE)

  • PBX does a draft-gin REGISTER

  • SSP has provisioning for *;phone-context=+5 goes to pbx123




REGISTER sip:ssp.comTo: <sip:[email protected]>Contact: <sip:;bnc>

INVITEsip:789;[email protected]

INVITEsip:789;[email protected]

Open issues

Open Issues (OLIVE)

Non context local numbers
Non-context Local Numbers (OLIVE)

  • 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 (OLIVE)

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