Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Feb 2004 01:54:09 -0500

Christian Jansson wrote:

> Perhaps a little late, and hopefully not off topic. Comments inline.

Not too late, not off topic.

> 
> 
>>Jonathan R. wrote
>>This, however, leads me into thinking a bit on the lifecycle
>>management for GRUUs. Currently, GRUU is bound to a single 
>>registration, where the registration is defined by the Contact URI. If
> 
> 
>>the UA should "move", in the sense that it acquires a new IP address, 
>>this will be a new Contact URI, and therefore, a new GRUU. It would be
>>nice if, instead, the GRUU were truly bound to the UA instance, and 
>>that even if the UA instance changed IP addresses, the GRUU could 
>>remain unchanged. In such a case, if the UA moves, there is actually 
>>no need to issue any target refresh requests. The UA would simply 
>>re-register, update the binding of its GRUU to its new IP 
>>address, and 
>>existing calls would be correctly routed.
> 
> 
> But if the ip actually changes, it would be necessary to send an updated
> SDP with the new ip in the c= line.

Yes, that is true. If media relays are used (i.e., TURN), it might be 
possible to avoid even this, but lets leave that aside for now.

> So your idea won't save you from
> having to send a SIP request to the other end every time the ip changes
> in an INVITE session. 

Right. However, it does solve the problem that, previously, if both 
endpoints moved at the same time, the call would fail - neither side 
could signal the other.

> For a non-INVITE session though the idea would
> save a lot of request from being sent if the session only contains
> signaling.

Right, in particular, a long lived presence subscription, for example.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Natesan Kannan <[email-masked]>
Date: Tue, 03 Feb 2004 12:37:10 +0530

I will attempt a wild swing too...
Though we are talking of terminal mobility, it seems to me that this
mobility is restricted because of the fixed routeset in the dialog.
I can see that GRUU mapping to instance id, and the fact that GRUU can be
globally routed, paves a way for an un-restricted terminal mobility, just in
case nobody record-routed.
Was wondering if this could be of any use...
-Kannan
----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Christian Jansson" <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 03, 2004 12:24 PM
Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and
target refresh request

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Feb 2004 02:55:09 -0500

> Was wondering if this could be of any use...

It is true that the signaling path would be nailed down. This might be 
problematic for cases where a user roams into a totally different 
service provider, and that provider requires signaling to go through 
their signaling network in order for media to flow through their access 
network.

In such a case, what makes sense is for the client to generate a totally 
new INVITE, and use Replaces to replace the dialog at the called party. 
The original dialog is then torn down. Lest people complain about 
billing implications, the replaces header would allow for sufficient 
correlation of the two dialogs to account for this as if it was still 
one single call.

-Jonathan R.