1. MARTINI WG Interim 2010-04-29 draft-kaplan-martini-with-olive-00 Hadriel Kaplan

2. 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.164s are not globally unique, so draft-gin wont work –Cant expand Contact-URI automagically

3. 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

4. Example PBX does a draft-gin REGISTER SSP has provisioning for bob@ssp.com INVITE to bob@ssp.com follows rfc3261 OriginatorSSPPBX INVITE sip:bob@ssp.com INVITE sip:bob@192.1.2.3 REGISTER sip:ssp.com To: Contact:

5. Perceived Problems dont apply Draft-gin really did Register globally unique AoRs –E.g., sip:+123456789@ssp.com So now were bulk Registering other globally unique AoRs, scoped to the Registered domain (ssp.com) –Just like RFC 3261 would do for any AoR

6. 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 PBXs target IP in a Route header, theyre in one spot: the Request-URI –Draft-olive only covers AoRs of the Registered-to domain (more on that later)

7. Open Issues and Topics for Discussion/Yelling

8. 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 wont –It wouldnt 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?

9. 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

10. 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 or fully in one spot –theres 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: its a mess

11. 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

12. Straw-man continued… 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

13. 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;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?

14. Other Open Issues Reg-event handling –Cant really do normal reg-event for Local-Numbers – all usernames arent 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??