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

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.

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

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

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

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.

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.

Example 3

Example 9

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.

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

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?

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