IETF Logo Mail Archive

RE: [Sip] Interesting problem with PRACK and resent INVITEs

Bob Penfield <BPenfield@acmepacket.com> Fri, 18 January 2008 13:33 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 1JFrM4-0003ee-Rg; Fri, 18 Jan 2008 08:33:56 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFrM3-0003eY-B1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:33:55 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrM3-0003eQ-07 for sip@ietf.org; Fri, 18 Jan 2008 08:33:55 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFrM2-0003Nx-Jm for sip@ietf.org; Fri, 18 Jan 2008 08:33:54 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 08:33:49 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 08:33:50 -0500
From: Bob Penfield <BPenfield@acmepacket.com>
To: Jeroen van Bemmel <jbemmel@zonnet.nl>, Christer Holmberg <christer.holmberg@ericsson.com>
Date: Fri, 18 Jan 2008 08:33:46 -0500
Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs
Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs
Thread-Index: AchZqIcAfmAtjkdgSquu+hXV1gz50QALO77A
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC306E4ED482F@mail.acmepacket.com>
References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF041F5175@esealmw113.eemea.ericsson.se> <4790547E.8000009@zonnet.nl> <CA9998CD4A020D418654FCDEF4E707DF041F53A6@esealmw113.eemea.ericsson.se> <47905D04.6050509@zonnet.nl>
In-Reply-To: <47905D04.6050509@zonnet.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: "sip@ietf.org" <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>
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

I believe that a CSeq of 2 is perfectly valid for the second INVITE (resubmitted with credentials). The RFC 3261 is clear that it should have the same Call-ID and from-tag.  The CSeq number space is per dialog. This second INVITE is not part of any dialog, therefore its CSeq should not be compared with any previous dialog.

If a UA does keep CSeq state for a Call-ID it should be independent of the dialog CSeq state, and not updated by in-dialog requests.

cheers,
(-:bob

-----Original Message-----
From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Friday, January 18, 2008 3:02 AM
To: Christer Holmberg
Cc: sip@ietf.org; Paul Kyzivat
Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs

Christer,
>> .
>>
>>
>> Regarding from tags there is no explicit text, but 22.2 says:
>>
>> When a UAC resubmits a request with its credentials after receiving a
>> 401 (Unauthorized) or 407 (Proxy Authentication Required) response,
>> it MUST increment the CSeq header field value as it would normally
>> when sending an updated request.
>>
>
> So, I guess that means that the second INVITE in Dale's example should
> have Cseq => 3.

I interpreted this as "MUST increment (relative to the INVITE being
challenged)". I guess for initial INVITEs the minimal requirement is
that the CSeq be different, else merged request detection (8.2.2.2)
could kick in and prevent the call from succeeding. So both 2 or 3 are
valid, the text is ambiguous

Regards,
Jeroen


_______________________________________________
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

v2.23.0 | Report a Bug | By Email