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

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Tue, 6 Jan 2004 10:25:14 -0500

Hi, Jonathan:

I agree. In fact, this should be the basic principle to address the
mobility in the application layer. That is, the URL (e.g.,
[email-masked]) will remain the same no matter where the use moves,
however, the IP address (layer 3) or addresses of the other lower layers
may change.

The change in lower "physical" addresses is called as the "change in
point of contact." The point of contact at different (lower) layer may
change for the mobile user (specially in the case of the terminal
mobility), but its impact may or may not propagate in all upper layers.

If the URL would have been kept same under all circumstances, it would
have been the most elegant solution especially to address the problems
of the terminal mobility.

br,
Radhika

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, January 06, 2004 2:08 AM
To: Paul Kyzivat
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and
target refresh request

inline.

Paul Kyzivat wrote:

>> However, I think its a much better idea to send a second subscription

>> on a different dialog, rather than trying to reuse an existing
dialog.
> 
> 
> I think this actually depends on intent. If the subscriptions are 
> intended to be independent then I agree. OTOH, if it is important that

> the subscriptions always be associated with the same UA even as that 
> moves around, then there is an advantage to using a single dialog.
> 
> Its easier to find such cases in the sharing of a dialog between an 
> invite and a subscribe than it is between two subscribes.

The GRUU would allow you to keep both dialogs attached to a particular 
UA instance. Should the UA move around, it would require you to 
generate a target refresh request on each dialog to update the Contact.

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.

Indeed, this has the interesting benefit that, even if both UA in a 
call should move at the same time, the call would still be able to 
continue, since such updates are never propagated to the peer in the 
call.

For this to work, it would require that the registration have a way of 
identifying the UA instance. This goes back to the instance identifier 
we had (but removed) from callee-caps. If we added it, we could then 
associate the GRUU with this ID, rather than the Contact URI. In other 
words, if the client registered thusly:

REGISTER
To: sip:[email-masked]
Contact: sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a"
Supported: gruu

the registrar would allocate a GRUU, and associate it with that 
instance ID:

200 OK
Contact: 
sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:[email-masked]
om

Now, if the UA should update its registration because it moves:

REGISTER
To: sip:[email-masked]
Contact: sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a"
Contact: sip:1.2.3.4;expires=0

the registrar would return the *same* gruu for the new registration:

200 OK
Contact: 
sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:[email-masked]
om

It is still possible for the registrar to not store additional state 
if GRUU is defined this way. The GRUU URI would be computed thusly:

sip:<E(salt,instance-id)>@example.com

That is, the GRUU now encodes the instance ID. When a request is 
received with a GRUU, the registrar extracts the instance ID. It then 
looks up the registration corresponding to that instance ID, and 
obtains its Contact URI. This doesnt require additional state per se, 
but does require that the registration data be structured to allow 
lookups based on the instance-id.

Thoughts?

-Jonathan R.
> 
>     Paul
> 
>> -Jonathan R.
>>
>> [email-masked] wrote:
>>
>>> Hi
>>>
>>>
>>>> For a dialog initiated with SUBSCRIBE, can a subscription for a new

>>>> event on that dialog also be a target refresh request?
>>>>
>>>> [Natraj] No, it's not a Target refresh request. Target refresh
could
>>>> only happen either through INVITE or UPDATE requests..
>>>
>>>
>>>
>>>
>>> There is a bug in RFC3265. Bug description 
>>> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says:
>>>
>>> "NOTIFY and SUBSCRIBE are target refresh requests
>>>
>>> ...but the text never says this explicitly."
>>>
>>> Haven't seen this bug closed yet... I remember some discussion on 
>>> this on this a while (a year or so) ago, so you might want to check 
>>> the archives for that.
>>>
>>>         Jussi
>>>
>>> _______________________________________________
>>> 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
>>>
>>
> 

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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Jan 2004 17:00:07 -0500

inline.

> of the terminal mobility.

Right. The principal value of this approach would be to allow for 
application layer SIP mobility. Effectively, the Contact URI/GRUU 
would join the AOR as a URI that is independent of the point of 
attachment of the UA.

-Jonathan R.