RE: [Sip] Interesting problem with PRACK and resent INVITEs
"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 18 January 2008 05:17 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjbt-0007GY-Ps; Fri, 18 Jan 2008 00:17:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjbq-00070O-Ml for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:17:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjbq-00070F-BK for sip@ietf.org; Fri, 18 Jan 2008 00:17:42 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFjbp-0007WF-I5 for sip@ietf.org; Fri, 18 Jan 2008 00:17:42 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6ABED209DE; Fri, 18 Jan 2008 06:17:40 +0100 (CET)
X-AuditID: c1b4fb3c-a9aebbb0000007e0-00-47903674413e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 457B9203DB; Fri, 18 Jan 2008 06:17:40 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 06:17:39 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs
Date: Fri, 18 Jan 2008 06:17:39 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF041F5175@esealmw113.eemea.ericsson.se>
In-Reply-To: <478FFED9.7080307@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs
Thread-Index: AchZcG4EAvEf/8+nRSe8h70Sn8MxLgAIG1GQ
References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Dale.Worley@comcast.net
X-OriginalArrivalTime: 18 Jan 2008 05:17:39.0848 (UTC) FILETIME=[720A8080:01C85991]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Hi, >Interesting. But I'm not certain I buy it. CSeqs only make >sense within a dialog. F13 doesn't contain the To-tag abc, so >it ought not be expected to use a valid CSeq for that dialog. Correct. And, the INVITEs shall contain different From-tag values (and Call-ID values), so UAS 2 will be able to differentiate the dialogs based on those parameters. Regards, Christer > >A different issue here is that that F13 ought not go to UAS1 >at all. But we treat it as a new transaction, and don't >expect the proxy to maintain any history across transactions, >so we don't have a way to prevent that. > >There ought to be something in F11 that causes the request to >go only to (in this case) UA2. (In general to whichever node generated >the challenge, which might have been a proxy rather than a UA.) > > Paul > > Dale.Worley@comcast.net wrote: > > I was looking at a problem were were having with a phone and > > discovered the following interesting situation with PRACK > and INVITEs > > that have to be resent with authentication. > > > > Consider an INVITE that gets serially forked to two > destinations, the > > first one doesn't answer and the second one demands authentication: > > > > UAC Proxy UAS 1 UAS 2 > > > > | | | | > > F1 | INVITE CSeq 1 | | | > > |--------------->| | | > > F2 | | INVITE CSeq 1 | | > > | |-------------->| | > > F3 | | 180 CSeq 1 | | > > | | to-tag abc | | > > | |<--------------| | > > F4 | 180 CSeq 1 | | | > > | to-tag abc | | | > > |<---------------| | | > > F5 | PRACK CSeq 2 | | | > > | to-tag abc | | | > > |------------------------------->| | > > F6 | | 200 CSeq 2 | | > > | | to-tag abc | | > > |<-------------------------------| | > > | | | | > > ---------------------- delay ------------------------ > > | | | | > > F7 | | CANCEL CSq 1 | | > > | |-------------->| | > > F8 | | 200 CANCEL | | > > | |<--------------| | > > F9 | | 487 CSeq 1 | | > > | | to-tag abc | | > > | |<--------------| | > > F10 | | INVITE CSeq 1 | | > > | |------------------------------>| > > F11 | | | 407 CSeq 1 | > > | | | to-tag def | > > | |<------------------------------| > > F12 | 407 CSeq 1 | | | > > | to-tag def | | | > > |<---------------| | | > > F13 | INVITE CSeq 2 | | | > > |--------------->| | | > > F14 | | INVITE CSeq 2 | | > > | |-------------->| | > > F15 | | 500 CSeq 2 | | > > | | to-tag pqr | | > > | |<--------------| | > > F16 | 500 CSeq 2 | | | > > | to-tag pqr | | | > > |<---------------| | | > > | | | | > > > > Since the PRACK F5 is sent within a forked dialog, we don't > think of > > it as using up CSeq number space in the space of out-of-dialog > > requests. So when it comes time to re-send the INVITE F13, > it's easy > > to think that you can just use a CSeq one higher than the original > > INVITE F1. But transaction processing at UAS 1 is likely to notice > > that it's already seen CSeq 2 with that Call-Id. It looks like one > > must make sure that the re-sent INVITE has a CSeq higher > than has been > > used in any derived dialog of the original INVITE. > > > > Dale > > > > > > _______________________________________________ > > Sip mailing list https://www1.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 > > > > > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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
- [Sip] Interesting problem with PRACK and resent I… Dale.Worley
- RE: [Sip] Interesting problem with PRACK and rese… Sanjay Sinha (sanjsinh)
- Re: [Sip] Interesting problem with PRACK and rese… Theo Zourzouvillys
- Re: [Sip] Interesting problem with PRACK and rese… Paul Kyzivat
- RE: [Sip] Interesting problem with PRACK and rese… Christer Holmberg
- Re: [Sip] Interesting problem with PRACK and rese… Jeroen van Bemmel
- RE: [Sip] Interesting problem with PRACK and rese… Christer Holmberg
- Re: [Sip] Interesting problem with PRACK and rese… Jeroen van Bemmel
- RE: [Sip] Interesting problem with PRACK and rese… Bob Penfield