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

From: "Chris Boulton" <[email-masked]>
Date: Tue, 6 Jan 2004 08:58:59 -0000

Comments [in-line]

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: 06 January 2004 07:08
>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:f4@example.
com
>
>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:f4@example.
com
>
>
>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?

[Chris Boulton] Jonathan - I really like this.  It makes the GRUU
mechanism extremely powerful and increases usability and flexibility.
As long as the rule set for this functionality is strong (e.g. ensuring
that any client wishing to alter a binding for a GRUU terminates the
existing binding) I think it should be included.   

Chris.

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

This message has been scanned for viruses by MailControl - www.mailcontrol.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: "Christian Jansson" <[email-masked]>
Date: Wed, 28 Jan 2004 20:38:13 +0100

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

> Jonathan R. wrote

> 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. 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. For a non-INVITE session though the idea would
save a lot of request from being sent if the session only contains
signaling.

/ Christian Jansson