Globally Identifiable Number (GIN) Registration

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?)