Subject: RE: [Sip] Subscribe dialog and target refresh request

From: [email-masked]
Date: Mon, 5 Jan 2004 13:43:05 +0200

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Jan 2004 16:48:14 -0500

Yes, SUB and NOT are target refresh requests.

However, the question that was asked, I think, had to do with 
establishing a second subscription in the context of a dialog created 
by a first subscription. In such a case, a SUBSCRIBE or NOTIFY would 
be a target refresh request, but what state does it update? For 
example, if a SUBSCRIBE refresh for the second subscription contains a 
new Contact, does that contact apply to both subscriptions, or just 
the second one? I think its both, because the remote target is part of 
the dialog state, and there is but one dialog here.

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.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Jan 2004 18:29:49 -0500

Jonathan Rosenberg wrote:
> establishing a second subscription in the context of a dialog created by 
> a first subscription. In such a case, a SUBSCRIBE or NOTIFY would be a 
> target refresh request, but what state does it update? For example, if a 
> SUBSCRIBE refresh for the second subscription contains a new Contact, 
> does that contact apply to both subscriptions, or just the second one? I 
> think its both, because the remote target is part of the dialog state, 
> and there is but one dialog here.

I agree.

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

	Paul

>> There is a bug in RFC3265. Bug description 
>> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says:
>>
>> 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
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Jan 2004 02:08:17 -0500

inline.

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

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]

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 6 Jan 2004 09:15:03 -0500

one question/comment below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul
> Kyzivat
> Sent: Monday, January 05, 2004 6:30 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sip] Subscribe dialog and target refresh request
>
>
>
>
[TOLGA]Maybe it is not an issue totally black and white but I prefer to
think that such associations are better done on application level, rather
than relying them to be part of the same dialogue. I personally like the
approach, to use dialogue construct more for on-the-wire SIP protocol
procedures. Even for SUBSCRIBE in an INVITE initiated dialogue, IMO, those
are two different signalling relationships, asociated on the application
level, rather than on SIP signalling level -I am not saying it is wrong to
send them on the same dialogue, just I think, one won't loose much, if they
are sent on different one-. For that particular target refresh issue, there
is maybe a minor advantage of sending only one target refresh message
instead of two, if both SUBSCRIBESs (or INVITe and SUBSCRIBE) are sent as
part of the same dialogue, but IMO this is insignifact.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jan 2004 10:05:20 -0500

Jonathan Rosenberg wrote:
> UA instance. Should the UA move around, it would require you to generate 
> a target refresh request on each dialog to update the Contact.

Yes, this is another way to solve that problem. I am not especially 
attached to using shared dialogs this way once all the machinery to do 
otherwise is in place. OTOH, I don't think shared dialogs are going 
away, so they remain *a* way to solve this or related problems.

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

This seems to presume that address changes of this sort are common, and 
a frequent source of target refreshes.

I don't have any useful data on the subject, but it seems likely to me 
that other reasons for target refreshes would be at least as 
significant. For instance load balancing.

> the registrar would allocate a GRUU, and associate it with that instance 
> ID:
> 
> 200 OK
> Contact: 
> 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:
> 
> 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?

In spite of my comment above, I think I like the general approach. 
However there may still be details to work out. Notably, your stateless 
algorithm won't work right if a UA uses the same instance id when 
registering with multiple AORs managed by the same registrar.

(It could be fixed by using: sip:<E(salt,instance-id,AOR)>@example.com.)

Going this way will also require careful specification of instance-id, 
but that is a useful exercise in any case. It will be important to 
specify what the uniqueness properties are for instance-ids, and to 
investigate what the implications are when they are violated. (Since it 
is easy to predict that they will be violated.)

The implications on registrar data storage and retrieval are 
significant, but in practice most registrars will require some alternate 
access path like this in any case.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Jan 2004 17:07:30 -0500

Paul Kyzivat wrote:

> away, so they remain *a* way to solve this or related problems.

Well, I would prefer one way rather than two, but we've already beaten 
this horse a bit...

> a frequent source of target refreshes.

Right. In particular I was thinking about application layer mobility. 
For WiFi SIP phones, this would be particularly attractive, I think.

> significant. For instance load balancing.

Sure. There too, you get interesting benefits from using GRUUs that 
are not bound to a specific IP address. You could migrate 
subscriptions from one server to another without needing to inform the 
watcher; you simply change the routing logic for the gruu to instead 
route to the server that will now handle the subscription (of course, 
you would have to have taken care of transferring subscription state 
in all cases).

> (It could be fixed by using: sip:<E(salt,instance-id,AOR)>@example.com.)

This is much better. Another benefit of doing this is that you could 
extract the AOR, look up the user, and then just do a search of the 
existing contacts to see which one matched the instance-id. It would 
mean that one could add support for gruus, and be stateless, without 
changing the existing schemas for the back-end data stores (I am 
making some assumptions about how the schema looks).

> is easy to predict that they will be violated.)

We can also be sure that there will be cases where the same UA 
instance uses different instance IDs over time. This is particularly 
likely with software agents.

> access path like this in any case.

See above - I think with your proposal they can be minimized.

-Jonathan R.