Re: [Sipping] Liaison Statement on offer/answer procedures

Paul Kyzivat <pkyzivat@cisco.com> Thu, 15 May 2008 13:48 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D8F3A67F9; Thu, 15 May 2008 06:48:33 -0700 (PDT)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693913A67F9 for <sipping@core3.amsl.com>; Thu, 15 May 2008 06:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.386
X-Spam-Level:
X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBtSZEExR+Yp for <sipping@core3.amsl.com>; Thu, 15 May 2008 06:48:29 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ACEA63A67A2 for <sipping@ietf.org>; Thu, 15 May 2008 06:48:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,491,1204531200"; d="scan'208";a="99127680"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 May 2008 06:47:46 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4FDlkBQ024825; Thu, 15 May 2008 06:47:46 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4FDlVra005960; Thu, 15 May 2008 13:47:46 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 09:47:45 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 09:47:44 -0400
Message-ID: <482C3F25.7070605@cisco.com>
Date: Thu, 15 May 2008 09:48:21 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <4822983A.2090906@ericsson.com> <4822F717.7030903@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F826@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF062C5DD8@esealmw113.eemea.ericsson.se> <482C2DE1.1080102@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF062EC204@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF062EC204@esealmw113.eemea.ericsson.se>
X-OriginalArrivalTime: 15 May 2008 13:47:44.0806 (UTC) FILETIME=[40C2FC60:01C8B692]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7983; t=1210859266; x=1211723266; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sipping]=20Liaison=20Statement=20on=20 offer/answer=20procedures |Sender:=20; bh=7zD2u8sX1ZPXjnVmsee2lADZTSFH5dilbdlYDVVLfIQ=; b=sKWnbyXK7djYcaty2t/j16SbZWxe/MR7beICZ+zgcQhQT8trDuiMwtvHZN nqxYTKnQFFPdMLamHyrkh/VYwQERogFmMHdhtwshgPpNo2rUWlqHkEifqIL8 VddsXSDUlU;
Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: sipping List <sipping@ietf.org>
Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Christer,

Saying "you shouldn't do it" to changing contact address or media 
address ignores facts of life that may require doing it. This overlaps 
strongly with the session mobility discussion that is currently going on.

Specifically, if a UA is losing possession of its address, or 
connectivity via that address, then it will have to do *something*. If 
we are going to say that you shouldn't change the contact address in a 
dialog, and shouldn't change the media address in a media session, then 
we need to specify some alternative.

Clearly there are at least two distinct cases here:

- there is a desire to switch to a new address, but the old address
   can continue to be supported until and unless use of the new one
   can be established

- the possession of or connectivity via the old address is going
   away soon, or has already gone away. The UA is trying to preserve
   the session by switching to a viable address. There is a limited
   window of opportunity to achieve this.

So, I think we can't just consider this to be a perverse case to be 
specified, but which will never be used in practice. Rather, I think we 
need to demonstrate how what we specify can indeed work.

Regarding use cases: certainly we can start with the ones already out 
there. But at least we ought to identify which ones we are talking about 
so everyone will know. And we may need others, such as the one in your 
prior message.

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi, 
> 
>>> When thinking about which alternative is the best, I think it's also
> good to keep the following in mind:
>>> It is not only the SDP that may be "updated" by the "intermediate"
>>> transactions. For example, I guess the remote target could also be 
>>> updated (see example below). So, what happens to that if the re-INVITE
> 
>>> then fails?
>>>
>>> So, whatever alternative we go for, I think that we should apply the 
>>> same rule to whatever data (SDP, remote target etc) has been updated 
>>> between the re-INVITE request and error response. Otherwise we will 
>>> really create a mess with confusion and interop problems.
>>> Does anyone have a problem with taking
> the-same-rule-applies-to-all-data approach?
>> I agree that more state is in play that just the offer and answer.
>> Its not entirely clear to me if they should be treated the same or not.
>> Changing the contact address is especially messy since getting it wrong
> can easily get you into a situation where you can no longer communicate
> to update the session. So I think the detailed 
>> process of updating the contact address, including the error cases,
> ought to be studied. Maybe it will turn out to be 1:1 with o/a state,
> and maybe not.
> 
> I think that one should avoid doing these kind of updates, because no
> matter what we decide I am sure there will be problems. But, I still
> think we need to have a rule saying what happens with updated data in
> this case.
> 
>> To provoke the study, perhaps we need to develop a set of use cases.
> The one below is a start.
> 
> Well, I am not sure we need to do that. I think the target- and the
> offer/answer use-cases.
> 
> There are of course also cases where a rollback is not possible. Assume
> you include a message body in the UPDATE with some application control
> message. That will be executed by the receiver when received, and it may
> not be possible to un-execute it when the re-INVITE fails.
> 
>>> Example with updated remote target:
>>>
>>> re-INVITE ------------------->
>>> UPDATE with new rem.target--->
>>> <- 200 (UPDATE) --------------
>>> <- 4xx (re-INVITE) -----------
>> In the above, I gather that the UPDATE carries no SDP, right? So the
> intent of sending it is independent of the reINVITE?
> 
> The UPDATE may contain SDP, but the purpose of the example was to show
> that the same kind of problem exists for the remote target.
> 
>>> What happens to the new remote target? Is it kept, or is there a
> fallback to whatever remote target was used before the UPDATE was sent?
>> Well, if the point of sending it was because the old address was
> becoming (or had become) non-viable, then rolling it back wouldn't be
> helpful.
>> Of course the same can be true of the media addresses in an o/a.
> 
> Exactly, so therefor one should avoid doing it. But, I still think we
> need to have a rule saying what happens with the data IF it happens. If
> a rollback is then not possible, I guess one has to try again, or
> release the session.
> 
> 3261 today says that there is a rollback if the re-INVITE fails, but one
> could of course say that it doesn't take this intermediate transactions
> into consideration.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>  
>>
>> -----Original Message-----
>> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On 
>> Behalf Of Christer Holmberg
>> Sent: 9. toukokuuta 2008 10:19
>> To: Paul Kyzivat; Gonzalo Camarillo
>> Cc: mmusic-chairs@tools.ietf.org; sipping; Mary Barnes
>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>
>>
>> Hi,
>>
>> I agree with Paul. We need to choose *some* solution. So, I think it 
>> would be good that anyone who has a preference indicates that.
>>
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On 
>> Behalf Of Paul Kyzivat
>> Sent: 8. toukokuuta 2008 15:51
>> To: Gonzalo Camarillo
>> Cc: mmusic-chairs@tools.ietf.org; sipping; Mary Barnes
>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>
>> I agree that sipping is the right place for the work, and that it 
>> ought to be done, eventually. It hasn't seemed like especially 
>> pressing, but apparently 3gpp thinks otherwise.
>>
>> I agree that, at least on the surface, it is less important which 
>> solution is chosen than it is that *some* solution be chosen. But 
>> there are pros and cons to the two obvious approaches, so it is best 
>> to do more than just flip a coin.
>>
>> 	Thanks,
>> 	Paul
>>
>> Gonzalo Camarillo wrote:
>>> Folks,
>>>
>>> the SIPPING WG has received the following LS from 3GPP:
>>>
>>> https://datatracker.ietf.org/liaison/444/
>>>
>>> We have talked to the MMUSIC chairs (MMUSIC was in the cc: of this 
>>> LS)
>>> and they are OK with working on this LS in SIPPING. In any case, we 
>>> will send our answer to the MMUSIC folks for comments before getting 
>>> back to 3GPP.
>>>
>>> This LS has to do with the offer/answer method, which was developed 
>>> by
>>> MMUSIC, but is also related to the SIP machinery associated to 
>>> offer/answer (i.e., rejected re-INVITEs). That is why we consider 
>>> SIPPING the right place to discuss it.
>>>
>>> Comments on this LS are appreciated.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>> SIPPING co-chair
>>> _______________________________________________
>>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP Use 
>>> sip-implementors@cs.columbia.edu for questions on current sip Use 
>>> sip@ietf.org for new developments of core SIP
>>>
>> _______________________________________________
>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> sip-implementors@cs.columbia.edu for questions on current sip Use 
>> sip@ietf.org for new developments of core SIP 
>> _______________________________________________
>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> sip-implementors@cs.columbia.edu for questions on current sip Use 
>> sip@ietf.org for new developments of core SIP
>>
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP