GRUU

1. GRUU Jonathan Rosenberg Cisco Systems

2. Instance ID param has to be a URN Equality rules for URN are scheme specific if scheme understood, else lexical Will not be an issue Introduction motivates the draft Question was: doesn’t RFC3261 already require GRUU property in Contact? GRUU property of long-livedness is back Was there before, but too weak GRUUs resolved using rfc3263 New UML Model and updated behavior sections to be clearer Changes

3. UML Model +-----------+ +-----------+ | | associated | | | |1 with 1| | | AOR |<----------------| GRUU | | | | | | | | | +-----------+ +-----------+ ^1 is ^^ |1 | bound // | is| to// |associated bound| // |with to| // | | // | |0..n // V1 +-----------+ // +-----------+ | | / 0..1 | | | | | | | contact |---------------->| Instance | | |1 has 1| ID | | | | | +-----------+ +-----------+

4. Contact expiration handling defined – unbound from GRUU If you register a contact with instance ID already registered Overwrites the previous No longer sending error Not pursuing multiple contacts per GRUU here Redundancy not in scope here – treat elsewhere May need to modify GRUU behavior for those uses SIPS handling SIP and SIPS versions of GRUU both defined and exist URI scheme of GRUU matches scheme of To in REGISTER SIPS handling otherwise identical to RFC3261 Sidenote: horribly underspecified in RFC3261 – need to revisit Changes

5. Changes • Proxy behavior • Was unclear how it interacted with rfc3261 • Now its clear – just an alternate location service, including GRID processing • Path applies to GRUU • If Contact URI had a GRID in REGISTER, it will be clobbered if GRUU has a grid • Can remove all contacts for an instance ID by registering any contact with an instance ID and expires: 0 • Terminology cleanup • Record routing interactions documented

6. RR case #1 (1) + (2): initial INVITE (2) + (3): mid-dialog request (1) +-----------+ (2) +-----------+ ------>| |--------------->| | | | | | (3) | Proxy | (4) | User | ------>| |--------------->| Agent | | | | | +-----------+ +-----------+ Need to make sure proxy knows to execute location service when getting mid-dialog request with Route header for itself

7. RR Case #2 (1) + (2) + (3): initial INVITE (4) - (9): mid-dialog request (1) +-----------+ (2) +-----------+ (3) +-----------+ ---->| |------->| |-------->| | (4) | | (5) | | | | ---->| Home |------->| Edge | | User | | Proxy | (7) | Proxy | (8) | Agent | +-->| |------->| |-------->| | | +-----------+ +-----------+ +-----------+ | | | | +------------------------------+ Soln: EP removes RR from 200 OK from UA if Supported: gruu is there

8. Open Issue #1: Find AOR from GRUU • Long debate about whether this is required • Was deemed an issue with GRUU in SIMPLE • Proposals to fix all completely changed GRUU mechanism, for example by defining gruu with an instance URI param, no registration support • Concluded (sort of) that it was not in the original requirements and thus out of scope • I propose a compromise • Keep current mechanism, but define a naming convention for GRUU that has AOR and instance ID visible • Orit proposes same mechanism discarded per above, back to square 1

9. Open Issue #2: removing RR OK? • RFC3261 allows a proxy to modify RR in response • Says nothing about removing one • Is it OK? • I think so

10. Open Issue #3: Hashed Indices • Appendix provides a way to create a GRUU by hashing AOR and instance ID, storing that on registration • Remove it when registration expires • Incoming call • Extract hash from user part of GRUU • Look up – if found, proceed, if not, 480 • Problem • Doesn’t differentiate between “no contacts registered” and “doesn’t exist” • Spec currently requires different response codes • Proposal • Remove this algorithm, suggest another