GRUU Jonathan Rosenberg Cisco Systems sip and sips

GRUU Jonathan Rosenberg Cisco Systems

sip and sips • General problem – What should gruu say about relationship of sips to gruu? • Specific questions – – If the contact URI is sip, can the gruu be sips? If the contact URI is sips, should the gruu be sips? What if To/From are a mix of sip/sips? Do we require one vs. two registrations? • Meta-question – Are a sip and sips URI for a resource the same resource? [Adam reports yes] – Can a URI be downgraded?

Proposal • If a sip and sips URI exist, they should point to the same resource • Existence of sip doesn’t imply sips and vice a versa • If contact is sip, gruu is a sip URI, but the server creates the sips resource (i. e. , it will accept and handle sips if it can do a secure connection) • If the contact is sips, the gruu is sips, but the server does not create the sip resource – Allows for sips only resources

Connection Reuse/GRUU relationship • draft-jennings-sipping-outbound represents the client to server aspect of connection reuse – Allows multiple connections from a client – Each is to the same instance – Differentiated with connection ID parameter • Those connections represent different contacts to the same instance • No normative reference needed

Multiple contacts allowed? • Currently, can only have one contact per instance • But an instance can be reachable in many ways for redundancy • Propose: allow multiple contacts per GRUU, all to same instance

Conflict Resolution • Current spec allows a single contact per instance – On failure and reboot, need multiple transactions to remove old registered contact – Impacts avalanche restart problem • Options – New contact overwrites previous one (had previously rejected this approach) – New contact gets registered too (only to same instance!) • Replacement does occur if you are using the connection reuse

Does GRUU map to AOR • Right now, AOR maps to a contact – How are redirects handled? Do you redirect to GRUU or contact? • If you have multiple contacts, you would have different proxy behaviors for AOR->GRUU and GRUU->contacts • Proposal – AOR translates to GRUU, translates to Contacts – Registering and refreshing contact registers and refreshes AOR->GRUU mapping and GRUU->contact mapping – AOR->GRUU mapping disappears when no contacts mapped to GRUU

Record-Route Interactions 1 2 Proxy/Reg EP 4 Client 5 3 • EP record routes initial INVITE • Client puts GRUU in Contact • Causes spiral – ideally EP should not record route if client uses GRUU

Solutions • If 200 OK contains Supported: GRUU EP can remove RR in response • Grin and bear it • Others?