Re: [Sip] [Sipping] INVITE dialogs
"Rockson Li (zhengyli)" <zhengyli@cisco.com> Thu, 06 November 2008 02:23 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3113A68BC; Wed, 5 Nov 2008 18:23:24 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4E83A6838; Wed, 5 Nov 2008 18:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level:
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 JdyfX409U5JX; Wed, 5 Nov 2008 18:23:21 -0800 (PST)
Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id F41C53A6803; Wed, 5 Nov 2008 18:23:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,553,1220227200"; d="scan'208";a="32731725"
Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 06 Nov 2008 02:23:12 +0000
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA62NCax022354; Thu, 6 Nov 2008 10:23:12 +0800
Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA62NAfr012503; Thu, 6 Nov 2008 02:23:12 GMT
Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 10:22:58 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 06 Nov 2008 10:22:55 +0800
Message-ID: <F86B91A10B14744E88408E80B8A30EF303C2166B@xmb-hkg-412.apac.cisco.com>
In-Reply-To: <4911F4B1.1050003@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] [Sip] INVITE dialogs
Thread-Index: Ack/fTuBQE/bcEM+RuiSd3lHavksegAOOEGw
References: <8E3FB58D-1C2C-4452-B4FC-A2027DF1CD85@gmail.com> <4911F4B1.1050003@cisco.com>
From: "Rockson Li (zhengyli)" <zhengyli@cisco.com>
To: "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com>, Pamela Zave <pamelazave@gmail.com>
X-OriginalArrivalTime: 06 Nov 2008 02:22:58.0436 (UTC) FILETIME=[95AAB440:01C93FB6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10909; t=1225938192; x=1226802192; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20<zhengyli@cisco. com> |Subject:=20RE=3A=20[Sipping]=20[Sip]=20INVITE=20dialogs |Sender:=20; bh=v1svyWOABlgH8UsUBIc1Hw1wC3ZVhqjztW23rfv6xEA=; b=GjdTfhds9e4NfVYwrQrjoKyx43VSUxd2eCiQp+mF6o1tgoC/kL9yTuGKWY LvNW3SvtyuwC7TxUazDC8ibviWHU8kaMk5SOeU5TOT6CNXUuG1Aq8SFslXyg nIwYkOkFw7z3EEvCSgS5KM3g1lsILeiZ9qKOqEvkvuL16Z/f04jzY=;
Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; );
Cc: sip@ietf.org, sipping@ietf.org
Subject: Re: [Sip] [Sipping] INVITE dialogs
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
Some comments for scenario 4 below. thanks -Rockson -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, November 06, 2008 3:32 AM To: Pamela Zave Cc: sip@ietf.org; sipping@ietf.org Subject: Re: [Sipping] [Sip] INVITE dialogs Correction. In my earlier response below I totally misread scenario 4. I'm updating my response to it. Paul Pamela, Are you familiar with: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-0 9.txt The race-examples draft and the offeranswer draft got going independently, with different foci, but there is an area of overlap in scope. There is a lot in the offeranswer draft that touches on your cases. In particular, section 4.1 of that document addresses this sort of thing. I'll say more in line. I do appreciate your coming at this from a formal model perspective. We weren't that thorough, and can easily have left holes. We just have to get your models to adequately reflect reality. (And unfortunately the reality is sometimes not pretty.) Thanks, Paul Pamela Zave wrote: > The material appended to this note consists of four scenarios. Each > is (I believe) a race condition not described in > draft-ietf-sipping-race-examples-06 > You will need to view this message in a fixed-width font. > > These were discovered by analysis of a formal model of INVITE dialogs, > as posted on > http://www.research.att.com/~pamela/sip.html > > What do you think? > > Pamela Zave > > > > SCENARIO 1. This scenario occurs within a confirmed dialog. > > UAC UAS > > re-INVITE 1 > <------------------------------------------------------ > no sdp > > 200(re-INVITE 1) > ------------------------------------------------------> > offer > ACK 1 > ------------------------- > / answer > / re-INVITE 2 > ! <--------------------------/--------------------------- > / offer > / > <------------------------ > > 200(re-INVITE 2) > ------------------------------------------------------> > answer > > ACK 2 > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the re-INVITE > immediately. It must buffer this request until it receives ACK 1, > which completes the ongoing offer/answer exchange. I think this is indeed a new case. The UAC can't distinguish this from the case where the re-INVITE 2 was sent even before the prior 200 was received. But it is very close to what is described in section 14.2 of 3261. My thought is that the UAC should send a 491 response to the re-INVITE 2. But this case isn't specifically addressed. The UAC could also try delaying in hope of getting the ACK, but that seems more trouble. This *ought* to be addressed in section 4.1 of offeranswer. I just rewrote that section last weekend because nobody could understand it before. But sadly it misses this case. Table 4 needs another row or two to cover this. > SCENARIO 2. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) 1 > <------------------------------------------------------ > answer > PRACK 1 > ------------------------------------------------------> > no sdp > 200(PRACK 1) > <------------------------------------------------------ > > UPDATE 183(reliable) 2 > ------------------------- ------------------------- > offer \ / offer > x > / \ > ! <------------------------ ------------------------> > > 491(UPDATE) > <------------------------------------------------------ > > PRACK 2 > ------------------------------------------------------> > answer > > 200(PRACK 2) > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the 183 > immediately, although immediate response is required by the standard. > Rather, it must wait until it receives the response to the UPDATE, > which will terminate the ongoing offer/answer exchange. The UAC > CANNOT assume that the update will fail, because it may succeed, as shown in the next scenario. This case is declared to be illegal. The rule (not so clear in the RFCs, clarified in offeranswer) is that after the first o/a exchange of an INVITE, you cannot initiate another o/a exchange using the 1xx/2xx/PRACK for that same INVITE. (If you want another o/a exchange before completing the INVITE you must use UPDATE to do it.) > SCENARIO 3. This scenario has roughly the same problem as Scenario 2, > although the race condition that causes it is different. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) 1 > <------------------------------------------------------ > answer > PRACK 1 > ------------------------------------------------------> > no sdp > 200(PRACK 1) > <------------------------------------------------------ > > UPDATE > ------------------------------------------------------> > offer > > 200(UPDATE) > ------------------------- > / answer > / > ! <--------------------------/--------------------------- > / 183(reliable,offer) 2 > / > <------------------------ > > PRACK 2 > ------------------------------------------------------> > answer > > 200(PRACK 2) > <------------------------------------------------------ Same response as for 2. > SCENARIO 4. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) > <------------------------------------------------------ > answer > PRACK > ------------------------------------------------------> > offer > > 200(PRACK) > ---------------------- > / answer > / > / 200(ini-INVITE) > <----------------------------/------------------------- > / no sdp > / > ACK / > -------------------------/----------------------------> > / > / re-INVITE > ! <---------------------/-------------------------------- > / offer > / > <------------------- > > 200(re-INVITE) > ------------------------------------------------------> > answer > > ACK > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the re-INVITE > immediately. It must buffer this request until it receives > 200(PRACK), which completes the ongoing offer/answer exchange. I think the alarm bells go off for the UAC when it receives the 200 for the ini-invite. It really shouldn't want to send the ACK yet, because as far as it is concerned, it has an unanswered offer outstanding. So my inclination would be that the UAC should just ignore the 200(ini-INVITE), sending no ACK. This will force the UAS to retransmit it. The UAC doesn't know that the PRACK with answer is enroute, but in this case it would then probably arrive before the 200 is retransmitted, so things would recover. But this is an interesting case to call out. As I noted above, I just rewrote section 4.1 of the offer/answer draft, but it is lacking your scenarios 1 & 4. If you have any thoughts on how to better treat section 4.1 I would be pleased to hear them. [RL] actually, I think caller here could respond 491 for re-INVITE with offer here, RFC3311 sec 5.2 has similar case. <snip> If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. </snip> Thanks, Paul _______________________________________________ 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 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- Re: [Sip] INVITE dialogs Paul Kyzivat
- [Sip] INVITE dialogs Pamela Zave
- Re: [Sip] INVITE dialogs Dale.Worley
- [Sip] INVITE dialogs Pamela Zave
- Re: [Sip] [Sipping] INVITE dialogs Paul Kyzivat
- Re: [Sip] [Sipping] INVITE dialogs Mary Barnes
- Re: [Sip] [Sipping] INVITE dialogs Paul Kyzivat
- Re: [Sip] [Sipping] INVITE dialogs Pamela Zave
- Re: [Sip] [Sipping] INVITE dialogs Paul Kyzivat
- Re: [Sip] [Sipping] INVITE dialogs Saverio Niccolini
- [Sip] INVITE dialogs Pamela Zave
- Re: [Sip] INVITE dialogs Paul Kyzivat
- Re: [Sip] INVITE dialogs Paul Kyzivat
- Re: [Sip] [Sipping] INVITE dialogs Rockson Li (zhengyli)
- Re: [Sip] [Sipping] INVITE dialogs Paul Kyzivat
- Re: [Sip] INVITE dialogs Dale.Worley
- Re: [Sip] INVITE dialogs Dale.Worley
- Re: [Sip] INVITE dialogs Paul Kyzivat