210 likes | 226 Views
This draft by Jonathan Rosenberg defines the problem of obtaining a Globally Routable User Agent URI (GRUU) and presents a proposed solution for app interaction and consultative transfer. It addresses GRUU lifecycle management issues, dialog reuse challenges, and locally generated GRUUs. The ICE approach is proposed as a solution. The draft also outlines caveats and a proposal for implementing the mechanism.
E N D
GRUU Mechanism Jonathan Rosenberg
Status • Draft-rosenberg-sipping-gruu-reqs-01 defines the problem • Draft-rosenberg-sip-gruu submitted with proposed solution • Needed for • App interaction • Consultative transfer • Presence
Obtaining a GRUU REGISTER request has Supported: gruu Each Contact in the response has a gruu parameter with GRUU Using a GRUU Place into Contact URI of INVITE/200 Include Supported: gruu Mechanism Summary Registrar REGISTER Supported: gruu 200 OK Contact: Sip:a@b; gruu=c@d;
Open Issues • GRUU lifecycle definition • Dialog reuse • Locally generated GRUU
GRUU Lifecycle Management • Can GRUU change during a registration? [N] • What happens if gruu parameter is placed in REG request? [ignored] • What happens if registrar changes gruu in response? [not allowed] • Implication: registrar has to remember gruu for lifetime of registration • Can be different across different registrations of the same contact • GRUU is not randomized across transactions – privacy implications?
Dialog Reuse • GRUU can allow us to eliminate dialog reuse • Many problems with it • Underspecified in RFC3261 • Bad idea • Do we have GRUU spec say that you should not do dialog reuse if your peer supports GRUU? • Will need to fix REFER for that to work or except REFER • Or do we live with the mistake?
Locally Generated GRUU • Putting a GRUU in the Contact will end direct signaling • A UA can try to generate its own local GRUU and use that • But how does it know that it is reachable at that GRUU? • Proposed solution: ICE
ICE Approach Proxy INVITE Contact: sip:a@domain; alt=sip:a@ip-addr Callee Caller
ICE Approach Proxy Doesn’t RR Proxy INVITE Contact: sip:a@domain; alt=sip:a@ip-addr Callee Caller
ICE Approach Proxy 200 OK Contact: sip:b@domain; alt=sip:b@ip-addr2 Callee Caller
ICE Approach Proxy 200 OK Contact: sip:b@domain; alt=sip:b@ip-addr2 Callee Caller
ICE Approach Proxy Callee Caller OPTIONS b@ip-addr2
ICE Approach Proxy B knows that A was able to Reach him @ip-addr2 So he can now Re-invite to update Contact Callee Caller 200 OK
ICE Approach Proxy INVITE Contact: sip:b@ipaddr2; Callee Caller
ICE Approach Proxy INVITE Contact: sip:b@ipaddr2; Callee Caller
ICE Approach Proxy 200 OK Contact: sip:a@domain; sip:a@ip-addr Callee Caller
ICE Approach Proxy 200 OK Contact: sip:a@domain; sip:a@ip-addr Callee Caller
ICE Approach Proxy Callee Caller OPTIONS a@ip-addr
ICE Approach Proxy Callee Caller 200 OK
Caveats • A and B both have to OPTIONS separately • Connectivity must be tested in each direction • OPTIONS is not on the same dialog as INVITE • Need to have randomization on OPTIONS to avoid glare • Doesn’t work if a proxy record-routed INVITE • Connectivity check would need to be from outermost proxy to UA – no easy way to do this • Source routing would reuse dialog route headers – not allowed
Proposal • Add this as an optional mechanism to the draft • Recommend that this is the ONLY way you can use locally generated GRUU