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

"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 16 May 2008 18:06 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 B11273A6B55; Fri, 16 May 2008 11:06: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 A7DE33A6B55 for <sipping@core3.amsl.com>; Fri, 16 May 2008 11:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.157
X-Spam-Level:
X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Ml185S8Jfkqk for <sipping@core3.amsl.com>; Fri, 16 May 2008 11:06:17 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 660263A6B4C for <sipping@ietf.org>; Fri, 16 May 2008 11:06:17 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C1B720A69; Fri, 16 May 2008 20:05:13 +0200 (CEST)
X-AuditID: c1b4fb3c-ae09bbb00000193b-ff-482dccd9281b
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 55CF0206EB; Fri, 16 May 2008 20:05:13 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 20:05:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 May 2008 20:05:11 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF046C77CA@esealmw113.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] Liaison Statement on offer/answer procedures
thread-index: Aci3UbXqkjZHBrp4Tpi9BShfep290gALLytV
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> <482D8058.6030608@cisco.com>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, "Elwell, John" <john.elwell@siemens.com>
X-OriginalArrivalTime: 16 May 2008 18:05:13.0116 (UTC) FILETIME=[6315C5C0:01C8B77F]
X-Brightmail-Tracker: AAAAAA==
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hi,
 
I do NOT think John's case is connected to the rollback issue.
 
The rollback issue is: what happens to data that has been updated between the re-INVITE request and failure response? It of course included the target, but is not related to where responses are sent.
 
Responses are, afaik, always sent to where the request came from, so if one updates the local target he has to make sure that he listens to the "old" port if there are ongoing transactions.
 
Regards,
 
Christer
 
 

________________________________

Lähettäjä: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Lähetetty: pe 16.5.2008 14:38
Vastaanottaja: Elwell, John
Kopio: Christer Holmberg; sipping List
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures



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