1 / 13

Globally Identifiable Number (GIN) Registration

Draft document detailing the Globally Identifiable Number (GIN) Registration mechanism for PBX communication, including modifications for Contact URIs, Public and Temporary GRUU procedures, and open issues to address.

Download Presentation

Globally Identifiable Number (GIN) Registration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Globally Identifiable Number (GIN) Registration Adam Roach draft-martini-roach-gin-01 IETF 77 – Anaheim, CA, USA March 22, 2010

  2. Assumptions Driving Design • The PBX cannot be assumed to be assigned a static IP address. • No DNS entry can be relied upon to consistently resolve to the IP address of the PBX.

  3. Overview of Mechanism • Adds new parameter for Contact URI, to indicate that it represents several actual contacts. • Registrar semantically expands this special Contact into one contact for each DID number assigned to the PBX; stores in Location Service. • Proxy/Registrar exhibits normal Proxy/Registrar behavior

  4. Changes Since -00 • Added Proxy-Require • Simplified Contact and GRUU URI formats by removing “()” and “*” syntax • Further detail on Public GRUU procedures • Additional Temp GRUU procedure (minting Temp GRUUs based on Public GRUUs) • Added example for “Wumpus 9” (“Use Case 9” in previous terminology).

  5. Simpler Contact Syntax • REGISTER message now contains Contact URI with no user portion. • MARTINI Contact URI still contains “bnc” parameter to mark it as requiring special handling • SSP inserts called extension into user portion of registered MARTINI contact, removes “bnc” parameter, and follows normal proxy/registrar procedures

  6. Public GRUU Changes • Removed “*” from “gr” parameter; PBX instead uses new “sg” parameter to add its own device identifying token. • Previous text did not completely analyze SSP server behavior: application of normal GRUU procedures at SSP would lose PBX-specific device identifiers. • New procedure defines slight change at SSP: “gr” parameter is copied from GRUU to registered contact.

  7. Additional Temp GRUU Procedure • Created by PBX by starting with the Public GRUU it received from the SSP, and (a) removing user portion, and (b) adding an opaque “sg” parameter. • Note that, per the GRUU RFC, every REGISTER message between the PBX and its terminal generates a new Temp GRUU – this means each will have a new “sg” parameter. • The SSP will route associated requests to the PBX based on the “gr” parameter. • Self-made GRUUs remain an option, require no SSP support.

  8. Example 3

  9. Example 9

  10. Open Issue: user=phone • Current draft doesn’t treat “user=phone” as special. It simply says that parameters from a MARTINI Contact URI must be copied to the URI stores in the location service. • This implies that, if a PBX expects “user=phone” on incoming requests, it needs to include “user=phone” on its registered Contact.

  11. Open Issue: user=phone (options) • Several options exist: • Keep mechanism as-is (i.e., let PBX choose whether it needs “user=phone”) • Forbid “user=phone” on “bnc” URIs, and specify that the SSP must add “user=phone” • Forbid “user=phone” altogether • Proposal: leave as-is, let PBX indicate whether “user=phone” is needed.

  12. Open Issue: List of Phone Numbers? • General direction on list seems to be that neither the register nor its response needs to contain list of DIDs • Objections have focused exclusively around provisioning issues, not behavior of system at registration time. • Omission of DIDs in REGISTER makes it difficult and/or impossible for intermediate nodes to know which AORs might be related to this registration. • Would be trivial to add new header field or contact parameter to indicate number ranges. • Do we really want to paint ourselves into this corner?

  13. Other Pending Items • #7 and #8 : idnits and editorial • #9: Complete registration for new IANA-registered protocol items • #10: Analyze GIN versus requirements document • #11 - #13: Need (external?) security analysis of interaction between Path, Outbound, and Service Route with multiple AORs in a single REGISTER • #14: Need to complete, fix examples (what level of detail do we need?)

More Related