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

Mechanism Summary

• 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

Registrar

REGISTERSupported: gruu

200 OKContact: 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

Caller Callee

INVITEContact: sip:a@domain; alt=sip:a@ip-addr

ICE Approach

Proxy

Caller Callee

INVITEContact: sip:a@domain; alt=sip:a@ip-addr

ProxyDoesn’t RR

ICE Approach

Proxy

Caller Callee

200 OKContact: sip:b@domain; alt=sip:b@ip-addr2

ICE Approach

Proxy

Caller Callee

200 OKContact: sip:b@domain; alt=sip:b@ip-addr2

ICE Approach

Proxy

Caller CalleeOPTIONS b@ip-addr2

ICE Approach

Proxy

Caller Callee200 OK

B knows thatA was able to Reach him @ip-addr2So he can nowRe-invite to update Contact

ICE Approach

Proxy

Caller Callee

INVITEContact: sip:b@ipaddr2;

ICE Approach

Proxy

Caller Callee

INVITEContact: sip:b@ipaddr2;

ICE Approach

Proxy

Caller Callee

200 OKContact: sip:a@domain; sip:a@ip-addr

ICE Approach

Proxy

Caller Callee

200 OKContact: sip:a@domain; sip:a@ip-addr

ICE Approach

Proxy

Caller CalleeOPTIONS a@ip-addr

ICE Approach

Proxy

Caller Callee200 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