MARTINI WG Interim2010-04-29

draft-kaplan-martini-with-olive-00Hadriel Kaplan

The Problem

• Draft-gin handles E.164

• How do we handle:sip:bob@ssp.com

sip:1234;ext=567;phone-context=+12125551212@ssp.com

• Perceived problems:– Non-E.164’s are not globally unique, so draft-gin

won’t work– Can’t expand Contact-URI automagically

The Solution

• “Bulk” REGISTER any provisioned AoR, as if the PBX had separately Registered for each one

• Contact-routing a la RFC3261 still works– If it would have worked for explicit REGISTERs

• The Contact-URI “expansion” is the provisioned AoR user portion– The same that would be provisioned for a

separate REGISTER

Example

• PBX does a draft-gin REGISTER

• SSP has provisioning for bob@ssp.com

• INVITE to bob@ssp.com follows rfc3261

Originator SSP PBX

INVITEsip:bob@ssp.com

INVITEsip:bob@192.1.2.3

REGISTER sip:ssp.comTo: <sip:pbx123@ssp.com>Contact: <sip:192.1.2.3;bnc>

Perceived Problems don’t apply

• Draft-gin really did Register globally unique AoRs

– E.g., sip:+123456789@ssp.com

• So now we’re bulk Registering other globally unique AoRs, scoped to the Registered domain (ssp.com)

– Just like RFC 3261 would do for any AoR

Comparison with loose-route

• Draft-gin/olive follows what happens today for normal Subscribers and for Peering– In both cases, the Req-uri host portion identifies the

target host/domain

• Draft-olive is the “loose-route” model, except:– Instead of the user portion in the req-uri and the PBX’s

target IP in a Route header, they’re in one spot: the Request-URI

– Draft-olive only covers AoRs of the Registered-to domain (more on that later)

Open Issues and Topics for Discussion/Yelling

What about bob@ssp.co.ca?

• Question:– How does the PBX know the call was for

bob@ssp.com and not for bob@ssp.co.ca? (if both are handled)

• Answer: it won’t– It wouldn’t have in rfc3261 either, if one

REGISTER for bob@ssp.com did more– Really the call is being re-targeted to

bob@ssp.com – and we have hist-info for figuring out the original target, right?

Other solutions for bob@ssp.co.ca

1. The PBX can REGISTER to ssp.co.ca– By definition it knows about ssp.co.ca, so it

can REGISTER to ssp.co.ca separately

2. Or we can define a new URI user parameter named “user-context”:

sip:bob;user-context=ssp.co.ca@192.1.2.3– Why is this legit? Same thing as phone-

context really, just for any alphanumeric

“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 or

fully in one spot– there’s an expired draft for P-Private-Network-Indication, tagging

incoming requests as belonging to a specific private context– the scoping model of RFC 3966 creates two tiers of scoping:

URI-user and URI level– In short: it’s a mess

A straw-man for how 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

• I can only see 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

Straw-man continued…

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

• The Request-URI reaching the PBX, and presumably any coming from it for a private plan, would be expressed as a rfc3966 Local-Numbersip:1234;phone-context=pbx.com@192.1.2.3

• Is that reasonable?– I think so – it has to be distinguished somehow, even

in a loose-route model– It could be done with yet-another-header (e.g., P-

Private-Network-Indication), but what would we set the Request-URI to anyway?

Other Open Issues

• Reg-event handling– Can’t really do “normal” reg-event for Local-Numbers

– all usernames aren’t known– Need a “Bulk-AoR” syntax/semantics for registration

state

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