MARTINI with OLIVEdraft-kaplan-martini-with-olive-00 Hadriel Kaplan
The Problem • Draft-gin handles E.164 • How do we handle: sip:firstname.lastname@example.org sip:1234;ext=567;email@example.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 firstname.lastname@example.org • INVITE to email@example.com follows rfc3261 Originator SSP PBX REGISTER sip:ssp.comTo: <sip:firstname.lastname@example.org>Contact: <sip:220.127.116.11;bnc> INVITEsip:email@example.com INVITEsip:firstname.lastname@example.org
Perceived Problems don’t apply • Draft-gin really did Register globally unique AoRs • E.g., sip:+email@example.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)
What about firstname.lastname@example.org? • Question: • How does the PBX know the call was for email@example.com and not for firstname.lastname@example.org? (if both are handled) • Answer: it won’t • It wouldn’t have in rfc3261 either, if one REGISTER for email@example.com did more • Really the call is being re-targeted to firstname.lastname@example.org – and we have hist-info for figuring out the original target, right?
Other solutions for email@example.com • The PBX can REGISTER to ssp.co.nl • By definition it knows about ssp.co.nl, so it can REGISTER to ssp.co.nl separately • Or we can define a new URI user parameter named “user-context”: sip:bob;firstname.lastname@example.org • 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: • It REGISTERed to a specific Domain: e.g., sip:enterprise.com or sip:enterprise.priv.ssp.com • It REGISTERed the AoR: e.g., sip:1234;email@example.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-Number sip:1234;firstname.lastname@example.org • 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, 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??