Subject: Re: [Sipping] New I-D - SIP Subscription Mobility using SUBSCRIBE withReplaces Header

From: Horvath Bob-BHORVAT1 <[email-masked]>
Date: Fri, 27 Jan 2006 12:21:08 -0600

Coulas Michael-MCOULAS1 wrote:
> Hi Jeroen,
>
> The UPDATE request is only useful inside an existing dialog and is NOT
> clearly defined as being applicable for the SUBSCRIBE method. If you're
> going to change the state of a subscription by sending a request inside
> the subscription dialog, then a re-SUBSCRIBE would be sufficient.
> However, re-SUBSCRIBE will not solve to problem of migrating the
> subscription to a different network, especially when connectivity to the
> old network is lost (i.e., a re-SUBSCRIBE request cannot be sent in that
> case). For those use cases you need to establish a new subscription
> dialog replacing the old subscription dialog.
>
> Mike Coulas
>   

There were two main motivating use cases - movement of a subscription as 
a device moves, and transfer of a subscription to a new device.  In both 
of these use cases, re-subscription on the existing dialog may not be 
possible. While the device is free to create a new subscription, the 
previous subscription remains until it expires.   This creates 
unnecessary state in the notifier, and also may create problems with the 
end user if there is a cost associated with adding a new subscription 
vs. replacing an existing subscription. 

Bob
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Friday, January 27, 2006 12:43 AM
> To: Jentz Brad-CBJ002; [email-masked]
> Cc: Coulas Michael-MCOULAS1; Horvath Bob-BHORVAT1
> Subject: Re: [Sipping] New I-D - SIP Subscription Mobility using
> SUBSCRIBE withReplaces Header
>
> Brad,
>
> One brief question : why couldn't the mobile device send an UPDATE over
> the new network (with new Contact), instead of terminating / replacing
> its subscriptions?
>
> Jeroen
>
> ----- Original Message -----
> From: Jentz Brad-CBJ002
> To: [email-masked]
> Cc: Coulas Michael-MCOULAS1 ; Horvath Bob-BHORVAT1
> Sent: Thursday, January 26, 2006 11:54 PM
> Subject: [Sipping] New I-D - SIP Subscription Mobility using SUBSCRIBE
> withReplaces Header
>
>
> All:
> I'd like to call your attention to a new I-D contribution.
> http://ietf.org/internet-drafts/draft-jentz-subscribe-with-replaces-00.t
> xt
> It proposes to extend the SIP SUBSCRIBE method to include the Replaces
> header field for the purpose of enabling a more robust solution to SIP
> subscription mobility.
> Your feedback and comments will be appreciated.
> Regards,
> Brad Jentz, Robert Horvath, Michael Coulas
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments of core SIP 
>
>   

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 28 Jan 2006 01:22:40 +0100

Mike,

I agree that the semantics for UPDATE within SUBSCRIBE based dialogs are 
perhaps not well defined (yet), but then again neither is replaces. UPDATE 
wouldn't work for a transfer to another device, so I'm talking about the 
first use case

One argument you could give is that the edge proxies Record-Route the 
SUBSCRIBE / NOTIFY, and hence the dialog's route set becomes unusable 
(inefficient, if not invalid) after a switch to another edge proxy. The 
example in section 4.2 does not show this though. If this is not the case, I 
don't see why it would be needed to logically replace all ongoing dialogs 
with new ones.

Another comment: I think the use of target-dialog in section 5 is 
unnecessary. Refer to the 3rd condition in section 3 of the tdialog draft
The request does not otherwise contain information that indicates
       that the UAC is aware of those dialog identifiers.the request 
contains the Replaces information in the Refer-To header (which BTW needs 
character escaping), so the Target-Dialog is superfluous IMO

Regards,

jeroen

----- Original Message ----- 
From: "Coulas Michael-MCOULAS1" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Jentz Brad-CBJ002" 
<[email-masked]>; <[email-masked]>
Cc: "Horvath Bob-BHORVAT1" <[email-masked]>
Sent: Friday, January 27, 2006 6:07 PM
Subject: RE: [Sipping] New I-D - SIP Subscription Mobility using SUBSCRIBE 
withReplaces Header

Hi Jeroen,

Mike Coulas

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]]
Sent: Friday, January 27, 2006 12:43 AM
To: Jentz Brad-CBJ002; [email-masked]
Cc: Coulas Michael-MCOULAS1; Horvath Bob-BHORVAT1
Subject: Re: [Sipping] New I-D - SIP Subscription Mobility using

Brad,

Jeroen

----- Original Message -----
From: Jentz Brad-CBJ002
To: [email-masked]
Cc: Coulas Michael-MCOULAS1 ; Horvath Bob-BHORVAT1
Sent: Thursday, January 26, 2006 11:54 PM
Subject: [Sipping] New I-D - SIP Subscription Mobility using SUBSCRIBE
withReplaces Header

All:

---

From: Horvath Bob-BHORVAT1 <[email-masked]>
Date: Sun, 29 Jan 2006 00:41:54 -0600

Jeroen van Bemmel wrote:
> Mike,
>
> I agree that the semantics for UPDATE within SUBSCRIBE based dialogs 
> are perhaps not well defined (yet), but then again neither is 
> replaces. UPDATE wouldn't work for a transfer to another device, so 
> I'm talking about the first use case
The whole point of this draft is to define semantics for Replaces for 
SUBSCRIBE based dialogs.   UPDATE is useful to change parameters of a 
session before it has been accepted.  We are talking about changes to a 
subscription after it has been accepted, so it is more analogous to a 
re-INVITE.  3265 defines the behavior of a re-SUBSCRIBE (subscription 
refresh).  Just as 3891 defined Replaces to cover cases where re-INVITES 
aren't appropriate, SUBSCRIBE with Replaces covers cases where a 
re-SUBSCRIBE is not appropriate.  

> (inefficient, if not invalid) after a switch to another edge proxy. 
> The example in section 4.2 does not show this though. If this is not 
> the case, I don't see why it would be needed to logically replace all 
> ongoing dialogs with new ones.

The case where a edge proxy changes is a reason that you would need 
SUBSCRIBE with Replaces.  I see that section 4.2 does not make this 
completely clear. 

> contains the Replaces information in the Refer-To header (which BTW 
> needs character escaping), so the Target-Dialog is superfluous IMO

OK.

Thanks for your comments. 

Bob

>
> Regards,
>
> jeroen
>
> ----- Original Message ----- From: "Coulas Michael-MCOULAS1" 
> <[email-masked]>
> Subject: RE: [Sipping] New I-D - SIP Subscription Mobility using

---

From: theja reddy <[email-masked]>
Date: Sun, 29 Jan 2006 13:56:49 +0000 (GMT)

Hai All,
   
    The Inclusion of Join Header in Subscribe/Notify, i hope will solve the Subscribtion migration and multiple subscriptions at the same time.
   
  regrads,
   theja reddy.

Horvath Bob-BHORVAT1 <[email-masked]> wrote:

OK.

Bob

> To: "Jeroen van Bemmel" ; "Jentz Brad-CBJ002" 
> ; 
> Cc: "Horvath Bob-BHORVAT1" 

				
---------------------------------
 Jiyo cricket on Yahoo! India cricket

---

From: Horvath Bob-BHORVAT1 <[email-masked]>
Date: Sun, 29 Jan 2006 23:41:50 -0600

theja reddy wrote:
> Hai All,
>  
>   The Inclusion of Join Header in Subscribe/Notify, i hope will solve 
> the Subscribtion migration and multiple subscriptions at the same time.
>  
I am not aware of a a Joins for SUBSCRIBE.  Did I miss it? Or are you 
suggesting Joins is more appropriate than Replaces?  

Joins doesn't seem like a natural fit for subscriptions to me.   Unlike 
INVITEs, where Joins is useful in adding to an existing session, with 
SUBSCRIBE, you can always choose to get added to the list of subscribers 
to which NOTIFYs are sent without Joins by sending another SUBSCRIBE.  
Both of these (SUBSCRIBE with or without Joins) adds another 
subscription and has no effect on the old one.

Replaces on the other hand implies not only getting added to an existing 
session/subscription, but it does so without adding another subscription 
and takes care of cleaning up the old subscription. This is useful in 
the case where you no longer communicate on  the old dialog route.  In a 
highly mobile environment, SUBSCRIBE with Replaces scales better.

Bob

> regrads,
>  theja reddy.
>
> */Horvath Bob-BHORVAT1 <[email-masked]>/* wrote:
>
>     Jeroen van Bemmel wrote:
>     > Mike,
>     >
>     > Another comment: I thi! nk the use of target-dialog in section 5 is
>     > he! ader field for the purpose of enabling a more robust
>     solution to SIP
>     > subscription mobility.
> ------------------------------------------------------------------------
> <http://us.rd.yahoo.com/mail/in/mailcricket/*http://in.sports.yahoo.com/cricket/>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jan 2006 09:50:45 -0500

[Replying to the whole thread, not just this message.]

I was underwhelmed by this draft until I got to the part about the 
problems of notifier mobility, which seem real and difficult. The 
proposed technique does seem to work pretty well for that.

On the debate about the use of Target-Dialog: I am on undecided. The 
referee is going to have to decode the Refer-To in any case, in order to 
discover it should do a SUBSCRIBE, and what event type to subscribe to, 
so interpretting the Replaces param as well is no big deal. OTOH, the 
values in the Replaces are intended to be meaningful to the subscribe 
target, not the referee. At the least, the local and remote tags need to 
be swapped to understand it.

One small point that isn't mentioned in the draft: the dialog id and 
event type may not be sufficient to identify the subscription. It may be 
necessary to also include an event id. Might be worth including in an 
example.

One advantage of this approach seems false to me. There seems to be an 
assumption that upon receipt of a SUBSCRIBE/Replaces, the notifier will 
just drop the replaced subscription without sending a NOTIFY. That is 
analogous to the recipient of an INVITE/Replaces dropping the replaced 
call without sending a BYE. That isn't how it works. There in general is 
no guarantee that the peer in the old dialog is aware that this is 
happening.

If it is desired to have the old subscription dropped without any 
notification, then I think there needs to be something new added to the 
signaling that explicitly requests that behavior. And, there may be some 
security considerations around that. (I haven't thought this through.)

Regarding use of UPDATE: it pertains to an invite dialog usage. Trying 
to apply it to SUBSCRIBE would be a mistake.

Regarding Join vs Replaces: they are cousins. The difference being that 
one is a request to be added as a third party in a two-party session. It 
makes sense for INVITE. Its not clear that it makes sense for SUBSCRIBE. 
Operationally, for a call, the recipient accepts the INVITE/Join without 
disconnecting the other party. If applied to SUBSCRIBE, that doesn't 
seem to be what is desired here. That behavior can be achieved simply by 
not using either Replaces or Join.  I suppose perhaps the presence of 
Join could mean that the request should fail unless there is an existing 
subscription with the same dialog id.

	Paul

---

From: Horvath Bob-BHORVAT1 <[email-masked]>
Date: Tue, 31 Jan 2006 13:09:12 -0600

> [Replying to the whole thread, not just this message.]
...
> assumption that upon receipt of a SUBSCRIBE/Replaces, the notifier 
> will just drop the replaced subscription without sending a NOTIFY. 
> That is analogous to the recipient of an INVITE/Replaces dropping the 
> replaced call without sending a BYE. That isn't how it works. There in 
> general is no guarantee that the peer in the old dialog is aware that 
> this is happening.
>
> notification, then I think there needs to be something new added to 
> the signaling that explicitly requests that behavior. And, there may 
> be some security considerations around that. (I haven't thought this 
> through.)
>

I agree, although I can see why as written it is not obvious because we 
wrote it from the perspective of the new subscription without much 
discussion on what happens to the existing subscription.  When we said 
the old subscription is removed, we deferred to 3265 to define what that 
means.  3265 indicates that when removing a subscription, the notifier 
should send a NOTIFY to indicate that it is terminating the existing 
subscription.