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

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

• Hadriel Kaplan

2
The Problem

• Draft-gin handles E.164
• So how do we handle Local Numbers?
• sip1234phone-context12125551212_at_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 arent 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.,
  sipenterprise.com or sipenterprise.priv.ssp.com
• It REGISTERed the AoR e.g., sip1234phone-conte
  xtpbx.com_at_ssp.com

5
So

• The first way (Register to an explicit domain)
  doesnt 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 thats an issue
• The second way (Register the AoR) is what
  draft-olive describes
• It can just re-use the draft-gin REGISTER,
  because theres 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
• sip1234phone-contextpbx.com_at_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
Originator
SSP
PBX
REGISTER sipssp.comTo ltsippbx123_at_ssp.comgtCont
act ltsip192.1.2.3bncgt
INVITEsip789ph5_at_ssp.com
INVITEsip789ph5_at_192.1.2.3

• PBX does a draft-gin REGISTER
• SSP has provisioning for phone-context5 goes
  to pbx123

8
Open Issues
9
Non-context Local Numbers

• But what if the PBX doesnt know about this
  phone-context stuff?
• Its as if the PBX registered sip123_at_ssp.com
  its just a username to it
• But not really, because 123_at_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)
• Cant have a simple syntax, because names arent
  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??