martini wg interim 2010-04-29 draft-kaplan-martini-with-olive-00 hadriel kaplan
TRANSCRIPT
MARTINI WG Interim2010-04-29
draft-kaplan-martini-with-olive-00Hadriel Kaplan
The Problem
• Draft-gin handles E.164
• How do we handle:sip:[email protected]
sip:1234;ext=567;[email protected]
• 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 [email protected]
• INVITE to [email protected] follows rfc3261
Originator SSP PBX
INVITEsip:[email protected]
INVITEsip:[email protected]
REGISTER sip:ssp.comTo: <sip:[email protected]>Contact: <sip:192.1.2.3;bnc>
Perceived Problems don’t apply
• Draft-gin really did Register globally unique AoRs
– E.g., sip:[email protected]
• 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 [email protected]?
• Question:– How does the PBX know the call was for
[email protected] and not for [email protected]? (if both are handled)
• Answer: it won’t– It wouldn’t have in rfc3261 either, if one
REGISTER for [email protected] did more– Really the call is being re-targeted to
[email protected] – and we have hist-info for figuring out the original target, right?
Other solutions for [email protected]
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;[email protected]– 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;[email protected]
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;[email protected]
• 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??