Subject: Re: [Sipping] New I-D - Private Header Extension to SIP for Support of Mobility Operations

From: "Anton Tveretin" <[email-masked]>
Date: Sat, 12 Apr 2008 02:09:16 +0600

What's about call linkage? I.e. how to check that the new dialog belongs to
the same call? I think it can be done in two ways:
1. to reuse dialog-id;
2. to indicate the previous dialog-id in the Replaces: header.
This should be clearly stated. As a consequence for (case 1), if the route
does not change, there will be no BYE. If B2BUAs change dialog-id, case 1
will not work. (Case 2 might sometimes).
I also think that such operation is not required for the Simple SIP and this
should be clearly stated.
If this header is purely informative (to my mind it is), why a Require:
option tag?
Best regards, Anton.

_______________________________________________
Sipping mailing list  https://www.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: "Coulas Michael-MCOULAS1" <[email-masked]>
Date: Fri, 11 Apr 2008 18:33:11 -0400

Hi Anton, 

See my comments in blue below.

Mike

-----Original Message-----
From: Anton Tveretin [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 3:09 PM
To: Coulas Michael-MCOULAS1; [email-masked]
Subject: Re: [Sipping] New I-D - Private Header Extension to SIP for
Support of Mobility Operations

What's about call linkage? I.e. how to check that the new dialog belongs
to the same call? I think it can be done in two ways:
For the case of single device mobility, the SDP session ID can be used
to identify the specific session (i.e., call)  that is the target of the
mobility operation. The case of inter-device mobility is a bit more
problematic as the target device needs to learn about the session that
it is replacing. The "Future Considerations" section suggests some
possible extensions to the basic idea that could solve this problem
(e.g., "info" mobility header, call identifier). (With respect to using
dialog as a means of session identification, see my second comment).

1. to reuse dialog-id;
2. to indicate the previous dialog-id in the Replaces: header.
The standard target refresh and INVITE w'Replaces operations work fine
for simple cases where the signaling path to be replaced consists of a
single dialog between the local device and the remote device (or a B2BUA
3pcc server). The draft attempts to address the more generic problem
where the signaling path to be replaced may consist of a sequence of
dialogs (and/or CS connections). We also wanted a solution that avoids
having the device explicitly address mobility related SIP requests to
specific servers.

This should be clearly stated. As a consequence for (case 1), if the
route does not change, there will be no BYE. If B2BUAs change dialog-id,
case 1 will not work. (Case 2 might sometimes).
I also think that such operation is not required for the Simple SIP and
this should be clearly stated.
If this header is purely informative (to my mind it is), why a Require:
option tag?
The header is not informative, the status of the draft is. The
P-Mobility header is not intended to be an extension to the core SIP
specification but rather a private application-level SIP extension to be
used in SIP-based VoIP/multimedia networks including standard ones like
3GPP IMS (RFC 3455 is an example of such a informational spec). The
"Require: mobility-op" is needed to ensure proper operation of the
extension in the network, i.e., SIP request carrying the P-Mobility
header must only be processed by SIP application servers or endpoint UAs
that understand the extension, otherwise if no such node is found, then
an appropriate error response is returned, as per RFC 3261. This is
needed, for example, to prevent an INVITE w/P-Mobility from establishing
a brand new call with the remote party.

Best regards, Anton.