1. GRUU Jonathan Rosenberg Cisco Systems

2. Main Changes Up front discussion of URI properties Opaque URI parameter for constructing GRUU Procedure for EP to remove itself from RR if UA supports GRUU REGISTER response has Require New GRUU construction algorithms using opaque Mechanism for picking gruu in dialog forming req/res Grammar bug: missing for instance Registrar doesn’t delete two registrations with same instance – just uses most recent –Inline with sip-outbound Text on administratively constructed gruu in servers – really easy More detailed discussion on service treatment property for GRUU 404 vs. 480 responses clarified

3. Issue 1: Extraction of AOR from GRUU Currently, opaque parameter contains blob, remove it, you get the AOR: –sip:user@domain;opaque=gruu-blob –sip:user@domain Have gotten a few complaints about this –One suggestion to leave this to another spec –Suggestion on list: sip:Alice@bar;opaque- aor=false;gruu- id=" –Another suggestion: sip:gruu- blobs@example.com;aor=u ser@example.com Do we want to change this? PROPOSAL: NO

4. Issue 2: The double role of GRUU We are using GRUU in two ways: –As a target for mid-dialog requests (consequence of its inclusion in Contact) –As a target for new requests to that UA But there are differences –Service Treatment Would like service treatment for new requests Probably not for mid-dialog –Record-routing and GRUU interactions only for mid-dialog requests Idea 1: GRUU only for new requests –Original design worked this way – carried in a Gruu header field in INVITE request or response, but had backwards compatibility problem –Lose significant GRUU benefit of “moving” dialogs when a UA re-registers mid-dialog Idea 2: Endpoints record-route –Use their IP-address in there –Means Contact is ignored for mid-dialog requests –Fundamental change in SIP usage Proposal: Stay as is