martini with olive draft kaplan martini with olive 00 n.
Skip this Video
Loading SlideShow in 5 Seconds..
MARTINI with OLIVE draft-kaplan-martini-with-olive-00 PowerPoint Presentation
Download Presentation
MARTINI with OLIVE draft-kaplan-martini-with-olive-00

MARTINI with OLIVE draft-kaplan-martini-with-olive-00

210 Views Download Presentation
Download Presentation

MARTINI with OLIVE draft-kaplan-martini-with-olive-00

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MARTINI with OLIVEdraft-kaplan-martini-with-olive-00 Hadriel Kaplan

  2. The Problem • Draft-gin handles E.164 • How do we handle: sip:1234;ext=567; • Perceived problems: • Non-E.164’s are not globally unique, so draft-gin won’t work • Can’t 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 • INVITE to follows rfc3261 Originator SSP PBX REGISTER sip:ssp.comTo: <>Contact: <sip:;bnc> INVITEsip:bob@

  5. Perceived Problems don’t apply • Draft-gin really did Register globally unique AoRs • E.g., • So now we’re bulk Registering other globally unique AoRs, scoped to the Registered domain ( • 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 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)

  7. Open Issues and Topics for Discussion/Yelling

  8. What about • Question: • How does the PBX know the call was for and not for (if both are handled) • Answer: it won’t • It wouldn’t have in rfc3261 either, if one REGISTER for did more • Really the call is being re-targeted to – and we have hist-info for figuring out the original target, right?

  9. Other solutions for • The PBX can REGISTER to • By definition it knows about, so it can REGISTER to separately • Or we can define a new URI user parameter named “user-context”: sip:bob; • 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 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

  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: • It REGISTERed to a specific Domain: e.g., or • It REGISTERed the AoR: e.g., sip:1234;

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

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

  14. 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??