Re: [Sipping] Liaison Statement on offer/answer procedures
"Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com> Thu, 05 June 2008 02:50 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 2A6633A69A0; Wed, 4 Jun 2008 19:50:01 -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 1BE0D3A69A0 for <sipping@core3.amsl.com>; Wed, 4 Jun 2008 19:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gsAk97K-USmC for <sipping@core3.amsl.com>; Wed, 4 Jun 2008 19:49:58 -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 3D12D3A6916 for <sipping@ietf.org>; Wed, 4 Jun 2008 19:49:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,592,1204520400"; d="scan'208";a="10173641"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jun 2008 22:50:02 -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 m552o2Ur000338; Wed, 4 Jun 2008 22:50:02 -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 m552o2oF016528; Thu, 5 Jun 2008 02:50:02 GMT
Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 22:50:02 -0400
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 04 Jun 2008 22:50:00 -0400
Message-ID: <C7FFFFDD779F2047A0FBAC811C5C5A000623FE12@xmb-rtp-201.amer.cisco.com>
In-Reply-To: <484719AF.9060207@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] Liaison Statement on offer/answer procedures
Thread-Index: AcjGlAw0SzS8SvtWTTOSs0Hkt9RZGwAId8IQ
From: "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>
To: "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
X-OriginalArrivalTime: 05 Jun 2008 02:50:02.0385 (UTC) FILETIME=[DA002810:01C8C6B6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12323; t=1212634202; x=1213498202; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20<sanjsinh@cisc o.com> |Subject:=20RE=3A=20[Sipping]=20Liaison=20Statement=20on=20 offer/answer=20procedures |Sender:=20 |To:=20=22Paul=20Kyzivat=20(pkyzivat)=22=20<pkyzivat@cisco. com>,=0A=20=20=20=20=20=20=20=20=22Christer=20Holmberg=22=20 <christer.holmberg@ericsson.com>; bh=aCh/OrltjoE581sNfVjyRYDps94f18FkhRb/L+RGuUg=; b=oD25X0a0dyK5SFXqAT3lb8y2bJF/kCATWuWbxfaTWuYm7nRp43VQIapRnm h0Vckt5jCefYKROa56du1Jzo8JzKL0vgeEmNTF+N2xXbuBqZ0oqL1xIEPIxr fNTm+1jUPW;
Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: "Elwell, John" <john.elwell@siemens.com>, sipping List <sipping@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Mary Barnes <mary.barnes@nortel.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
If precondition is treated as a separate case, then are there other use cases where UAS would need to send answer in provisional response to re-Invite. IMO, in majority of cases 200 OK would carry answer to offer in re-Invite/UPDATE. Sanjay >-----Original Message----- >From: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) >Sent: Wednesday, June 04, 2008 6:40 PM >To: Christer Holmberg >Cc: sipping List; Elwell, John; Gonzalo Camarillo; Mary Barnes >Subject: Re: [Sipping] Liaison Statement on offer/answer procedures > >Regarding SDP: > >I think the likely candidates are: > >1) as specified in 3261, and contrary to 3264, if a reinvite >fails, the SDP/media-session state rolls back to what it was >before the reinvite. This is so even if there answers were >transmitted reliably via PRACK and/or UPDATE. > >2) Once an answer has been transmitted reliably, it is >committed, and is not rolled back if the reinvite subsequently fails. > >Of these, (2) is probably easier to understand and implement. >And its probably semantically reasonable, except for one case: > >That case relates to preconditions. Using preconditions, you >can get into a state where an offer/answer has completed, but >preconditions have not been satisfied, so the media stream is >not usable. It is then expected that a subsequent o/a exchange >will improve upon this, and eventually result in usable media >streams. If each o/a is committed independently, then a >previously working can be replaced with an unusable state >until a further o/a fixes it, and if a further o/a doesn't fix >it then it remains permanently broken. > >(An example of this might be starting from a working low >bandwidth audio session. A reinvite is then sent with an >attempt to upgrade to a wideband codec with preconditions used >to condition the change on obtaining sufficient bandwidth. In >this case you would like to continue to use the low bandwidth >codec until you know if you have obtained the resources for >the wideband.) > >Note that this problem exists even without reinvite. It can >occur if an update to a working session is initiated using >UPDATE with preconditions. > >IMO this is an intrinsic problem with preconditions. Because >they aren't widely used, it may be prudent to split off fixing >that as a separate task. If that is done, then I think (2) >above is probably a good way to solve the rest of the problem. > >To solve the precondition problem I think we need a concept >like o/a-transaction. A single o/a pair is an o/a-transaction >if it contains no unsatisfied preconditions. But an o/a that >has unsatisfied preconditions results in an incomplete >o/a-transaction. Additional o/a pairs continue to be part of >it until a final o/a pair where the preconditions are >satisfied. That ends the o/a-transaction. A failure in the >midst of an o/a-transaction (signaled in the enclosing protocol like >sip) would revert to the session state in effect before the >beginning of the o/a-transaction. > >I would expect this direction for preconditions to be controversial. >(Among the one or two people who actually care about >preconditions.) Which is a good reason to split it off from the rest. > > Thanks, > Paul > >Christer Holmberg wrote: >> Hi, >> >> I agree with Paul that we probably aren't talking about >changes to 3264 here. >> >> Also, I am fine if we want to decouple "committings" of >media data/SDP updates with other types of data updates (contact etc). >> >> But, that means that we need to specify specific >"committing" rules for any type of data which can be affected. >Or, we can of course have a "default committing rule" (e.g. >full rollback), and then specify different rules for specific >type of data when/if needed. >> >> But, for the SDP data, would anyone object to a full rollback? >> >> Regards, >> >> Christer >> >> ________________________________ >> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wed 04/06/2008 17:32 >> To: Gonzalo Camarillo >> Cc: Christer Holmberg; Elwell, John; sipping List; Mary Barnes >> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures >> >> >> >> Gonzalo, >> >> I generally agree with your characterization below. But as I see it >> there likely are no changes needed to 3264. It is intentionally >> focused on the SDP, and not the conveyance of the SDP in some >> containing protocol. The following is about the extent of it in 3264: >> >> Protocol operation begins when one agent sends an >initial offer to >> another agent. An offer is initial if it is outside of >any context >> that may have already been established through the higher layer >> protocol. It is assumed that the higher layer protocol provides >> maintenance of some kind of context which allows the various SDP >> exchanges to be associated together. >> >> The agent receiving the offer MAY generate an answer, or it MAY >> reject the offer. The means for rejecting an offer are >dependent on >> the higher layer protocol. The offer/answer exchange is >atomic; if >> the answer is rejected, the session reverts to the state >prior to the >> offer (which may be absence of a session). >> >> SIP messed this up somewhat with the offerless-invite, and more when >> it introduced PRACK and UPDATE. The offerless-invite creates a case >> when it is impossible to reject an offer. But we aren't discussing >> that case here. Without PRACK and UPDATE, and with an offer in the >> INVITE, it the success or failure of the INVITE that determines the >> acceptance or rejection of the offer. (With an offerless invite, the >> ACK always accepts the offer, for better or worse.) >> >> The use of PRACK and UPDATE while an INVITE transaction is >is progress >> creates an ambiguous situation due to the following from >section 14.1 >> of >> 3261: >> >> If a UA receives a non-2xx final response to a >re-INVITE, the session >> parameters MUST remain unchanged, as if no re-INVITE had >been issued. >> >> This implies that changes made via PRACK and UPDATE during >the INVITE >> transaction must be rolled back. Since the problem created >by 3262 and >> 3311, in conjunction with 3261, I think the fixes will have to apply >> to those, not to 3264. >> >> Also, the issue about changing Contact addresses clearly has nothing >> to do with 3264. And I am becoming increasingly convinced that the >> rules for "committing" a change of Contact address ought to be >> decoupled from the rules for "committing" a change to media sessions. >> >> Before we get into the specifics, does the above make sense? >> >> Thanks, >> Paul >> >> >> >> Gonzalo Camarillo wrote: >>> 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 to offer/answer: >>> >>> >http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswe >>> r-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@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 >>>> >>> >> >> >> >_______________________________________________ >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] Liaison Statement on offer/answer proce… Gonzalo Camarillo
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Elwell, John
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Gonzalo Camarillo
- Re: [Sipping] Liaison Statement on offer/answer p… Sanjay Sinha (sanjsinh)
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Sanjay Sinha (sanjsinh)
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Sanjay Sinha (sanjsinh)
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Ian Elz
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Sanjay Sinha (sanjsinh)
- Re: [Sipping] Liaison Statement on offer/answer p… Anders Kristensen
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… Gonzalo Camarillo
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- Re: [Sipping] Liaison Statement on offer/answer p… hannu.hietalahti
- Re: [Sipping] Liaison Statement on offer/answer p… Paul Kyzivat
- Re: [Sipping] Liaison Statement on offer/answer p… Christer Holmberg
- [Sipping] Current status of response to 3gpp Liai… Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … Rockson Li (zhengyli)
- Re: [Sipping] Current status of response to 3gpp … Christer Holmberg
- Re: [Sipping] Current status of response to 3gpp … Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … Rockson Li (zhengyli)
- Re: [Sipping] Current status of response to 3gpp … Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … Ian Elz
- Re: [Sipping] Current status of response to 3gpp … Christer Holmberg
- Re: [Sipping] Current status of response to 3gpp … Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … Christer Holmberg
- Re: [Sipping] Current status of response to 3gpp … Robert Sparks
- Re: [Sipping] Current status of response to 3gpp … DRAGE, Keith (Keith)
- Re: [Sipping] Current status of response to 3gpp … Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … DRAGE, Keith (Keith)
- Re: [Sipping] Current status of response to 3gpp … Paul Kyzivat
- Re: [Sipping] Current status of response to 3gpp … Robert Sparks