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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 16 May 2008 12:38 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 E8C5328C194; Fri, 16 May 2008 05:38:20 -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 9D96028C182 for <sipping@core3.amsl.com>; Fri, 16 May 2008 05:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 3y9g9BzP4T8T for <sipping@core3.amsl.com>; Fri, 16 May 2008 05:38:17 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8590C28C143 for <sipping@ietf.org>; Fri, 16 May 2008 05:38:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,497,1204520400"; d="scan'208";a="8440233"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2008 08:38:12 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4GCcCjb029703; Fri, 16 May 2008 08:38:12 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4GCcCVJ010761; Fri, 16 May 2008 12:38:12 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 08:38:12 -0400
Received: from [10.86.240.46] ([10.86.240.46]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 08:38:11 -0400
Message-ID: <482D8058.6030608@cisco.com>
Date: Fri, 16 May 2008 08:38:48 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens.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> <482C3F25.7070605@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0BB548B@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0BB548B@GBNTHT12009MSX.gb002.siemens.net>
X-OriginalArrivalTime: 16 May 2008 12:38:11.0532 (UTC) FILETIME=[B3B5A8C0:01C8B751]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2278; t=1210941492; x=1211805492; c=relaxed/simple; s=rtpdkim1001; 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 |To:=20=22Elwell,=20John=22=20<john.elwell@siemens.com>; bh=fVPs0gJcOSdOPoVcTKAmKYxxmq2qZSKfcDFQvuN4f5I=; b=YIAcg718kKpYuv4Rsx3RId1SkWfgmHNid2l9DrZ4pQrWYC3TDa7XOgFm7H V1n0eKgMecKSkQX/UHqUiAySie3GnrC/k5XNUO6z2zoqAQj9JmrtGu90gLiO 262uxPK5oQ;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: sipping List <sipping@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
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

John,

This is a good point.

It does expose a potentially long window when address changes are 
problematic. I guess if a quick address change is necessary then the 
INVITE, or reINVITE, can be CANCELed.

IMO this is starting to identify an area that could stand to have more 
specification. I guess this sounds like a best practices draft, but its 
still a little fuzzy to me. And I am far from clear whether this is 
tightly connected to the o/a rollback issue.

	Thanks,
	Paul

Elwell, John wrote:
> Paul,
> 
> 
>> -----Original Message-----
>> From: sipping-bounces@ietf.org 
>> [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 15 May 2008 14:48
>> To: Christer Holmberg
>> Cc: sipping List
>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>
>> 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
> [JRE] So if the contact address changes and we successfully conclude the
> UPDATE transaction, and then the old contact address disappears, it is
> likely that the Via list on the re-INVITE request will have become
> invalidated too, so the final response will not reach the UAC. Correct?
> 
> John
> _______________________________________________
> 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