[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Liaison Statement on offer/answer procedures
Hi,
we should be providing 3GPP with an answer to their liaison soon:
https://datatracker.ietf.org/liaison/444/
The thing is that when working on the offer/answer usage draft below, we
kept from making normative From sipping-bounces at ietf.org Wed Jun 4 00:03:05 2008
Return-Path: <sipping-bounces at ietf.org>
X-Original-To: sipping-archive at optimus.ietf.org
Delivered-To: ietfarch-sipping-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 547D93A6B03;
Wed, 4 Jun 2008 00:03:05 -0700 (PDT)
X-Original-To: sipping at core3.amsl.com
Delivered-To: sipping at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EC06A3A681B
for <sipping at core3.amsl.com>; Wed, 4 Jun 2008 00:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.816
X-Spam-Level:
X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433,
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 OOKBfsJR67QC for <sipping at core3.amsl.com>;
Wed, 4 Jun 2008 00:02:58 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 474B93A68FC
for <sipping at ietf.org>; Wed, 4 Jun 2008 00:02:16 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
85E44209C4; Wed, 4 Jun 2008 09:02:18 +0200 (CEST)
X-AuditID: c1b4fb3c-ac898bb00000193b-a1-48463dfa875a
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
5E6EF206CE; Wed, 4 Jun 2008 09:02:18 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 4 Jun 2008 09:02:18 +0200
Received: from [159.107.2.19] ([159.107.2.19]) by esealmw127.eemea.ericsson.se
with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 4 Jun 2008 09:02:16 +0200
Message-ID: <48463DF1.7080109 at ericsson.com>
Date: Wed, 04 Jun 2008 10:02:09 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg at ericsson.com>
References: <4822983A.2090906 at ericsson.com> <4822F717.7030903 at cisco.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F826 at esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF062C5DD8 at esealmw113.eemea.ericsson.se> <482C2DE1.1080102 at cisco.com> <CA9998CD4A020D418654FCDEF4E707DF062EC204 at esealmw113.eemea.ericsson.se> <482C3F25.7070605 at cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0BB548B at GBNTHT12009MSX.gb002.siemens.net> <482D8058.6030608 at cisco.com>
<CA9998CD4A020D418654FCDEF4E707DF046C77CA at esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF046C77CA at esealmw113.eemea.ericsson.se>
X-OriginalArrivalTime: 04 Jun 2008 07:02:18.0097 (UTC)
FILETIME=[ED2CC610:01C8C610]
X-Brightmail-Tracker: AAAAAAÌ: sipping List <sipping at ietf.org>, Paul Kyzivat <pkyzivat at cisco.com>, "Elwell,
John" <john.elwell at siemens.com>, Mary Barnes <mary.barnes at nortel.com>
Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
X-BeenThere: sipping at 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 at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping at ietf.org>
List-Help: <mailto:sipping-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org
Hi,
we should be providing 3GPP with an answer to their liaison soon:
https://datatracker.ietf.org/liaison/444/
The thing is that when working on the offer/answer usage draft below, we
kept from making normative changes changes to offer/answer:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
However, it seems that there are a few cases that would require
normative updates to RFC 3264. In this thread, two cases have been
identified: roll back and address changes during ongoing transactions. I
would like to see a list of such pending updates in order to decide
whether we need to revise RFC 3264 at this point or document the current
issues (like we are doing with RFC 3261) for a future update.
Thanks,
Gonzalo
Christer Holmberg wrote:
> 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 at 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 at ietf.org
>>> [mailto:sipping-bounces at 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 at cs.columbia.edu for questions on current sip
>> Use sip at 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 at cs.columbia.edu for questions on current sip
> Use sip at 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP
to offer/answer:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
However, it seems that there are a few cases that would require
normative updates to RFC 3264. In this thread, two cases have been
identified: roll back and address changes during ongoing transactions. I
would like to see a list of such pending updates in order to decide
whether we need to revise RFC 3264 at this point or document the current
issues (like we are doing with RFC 3261) for a future update.
Thanks,
Gonzalo
Christer Holmberg wrote:
> 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 at 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 at ietf.org
>>> [mailto:sipping-bounces at 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 at cs.columbia.edu for questions on current sip
>> Use sip at 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 at cs.columbia.edu for questions on current sip
> Use sip at 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP