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

From: "Coulas Michael-MCOULAS1" <[email-masked]>
Date: Mon, 30 Jan 2006 15:35:50 -0500

Jeroen,

With respect to the rule that you refer to ("The request does not
otherwise contain information that indicates that the UAC is aware of
those dialog identifiers"), we did spend some time discussing whether to
include the Target-Dialog header or not, as this information is already
included with the Replaces information in the Refer-To header. We
eventually decided to include it mainly because the Replaces information
in the Refer-To header is not intended to be processed by the recipient
of the REFER request (referee) but instead is intended to be processed
by the recipient of the SUBSCRIBE request (refer target) generated as a
result of processing the REFER request. The header fields of the method
parameter contained in the Refer-To header are simply used to construct
the SUBSCRIBE request that is sent to the refer target, they should have
no meaning to the REFER request. Consequently, the decision to include
the Target-Dialog header. I understand the intent of the rule, i.e., you
don't want the Target-Dialog information to conflict with other dialog
identifying information contained in the request, but I don't think it
is applicable in this case.

The following call flow of a call transfer protecting the transfer
target, taken from "draft-ietf-sipping-cc-transfer-05", illustrates the
use of a REFER request with a Target-Dialog header identifying the same
dialog as the Replaces header field in the Refer-To header (in this case
used to generate an INVITE request).

             Transferor           Transferee             Transfer
                   |                    |                  Target
                   |                    |                    |
         dialog1   | INVITE/200 OK/ACK F1 F2                 |
                   |<-------------------|                    |
         dialog1   | INVITE (hold)/200 OK/ACK                |
                   |------------------->|                    |
         dialog2   | INVITE/200 OK/ACK F3 F4                 |
                   |---------------------------------------->|
         dialog2   | INVITE (hold)/200 OK/ACK                |
                   |---------------------------------------->|
         dialog3   | REFER
(Target-Dialog:1,Refer-To:sips:Transferee?Replaces=1) F5
                   |---------------------------------------->|
         dialog3   | 202 Accepted       |                    |
                   |<----------------------------------------|
         dialog3   | NOTIFY (100 Trying)|                    |
                   |<----------------------------------------|
         dialog3   |                    |            200 OK  |
                   |---------------------------------------->|
         dialog4   |                 INVITE (Replaces:dialog1)/200
OK/ACK F6
                   |                    |<-------------------|
         dialog1   | BYE/200 OK         |                    |
                   |<-------------------|                    |
         dialog3   | NOTIFY (200 OK)    |                    |
                   |<----------------------------------------|
         dialog3   |                    |            200 OK  |
                   |---------------------------------------->|
         dialog2   | BYE/200 OK         |                    |
                   |---------------------------------------->|
                   |                    |  (transferee and target
converse)
         dialog4   |                    |  BYE/200 OK        |
                   |                    |------------------->|

   Figure 6.  Transfer Protecting Transfer Target.

Mike.

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

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.  

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

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. 

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

OK.

Thanks for your comments. 

Bob

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