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

"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 18 January 2008 07:36 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 1JFlmc-0006V6-9E; Fri, 18 Jan 2008 02:36:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFlma-0006Uy-45 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:36:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlmZ-0006Uq-QN for sip@ietf.org; Fri, 18 Jan 2008 02:36:55 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFlmY-0000Sm-P4 for sip@ietf.org; Fri, 18 Jan 2008 02:36:55 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1951E20C47; Fri, 18 Jan 2008 08:36:52 +0100 (CET)
X-AuditID: c1b4fb3c-ab2eebb0000007e0-1b-479057135389
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4D6D203CF; Fri, 18 Jan 2008 08:36:51 +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 08:36:51 +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 08:36:50 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF041F53A6@esealmw113.eemea.ericsson.se>
In-Reply-To: <4790547E.8000009@zonnet.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs
Thread-Index: AchZo1917ZPPwjE1QjaDgKmcxOZ04AAACiwg
References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF041F5175@esealmw113.eemea.ericsson.se> <4790547E.8000009@zonnet.nl>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
X-OriginalArrivalTime: 18 Jan 2008 07:36:51.0769 (UTC) FILETIME=[E42C8290:01C859A4]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: 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

Hi, 

>No, see RFC3261 8.1.1.4:
> 
>Note that when requests are retried after certain failure 
>responses that solicit an amendment to a request (for
>example, a challenge for authentication), these retried 
>requests are not considered new requests, and therefore do not need new
Call-ID
>header fields; see Section 8.1.3.5.

Correct.

>Mid-dialog challenges should use the same from-tag + Call-ID, 
>so although it seems allowed to start anew, IMHO it is better 
>to keep them the same. 
>The text could be more clear though (and should have some 
>normative words).
>
> 
>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.
 
>This hints at treating the challenge response as a mid-call 
>request (although it may have no to-tag in case of an initial INVITE)

Personally I think that EVERY new initial INVITE should be update the
Call-ID and/or From-tag, no matter what triggered it.

But, I guess there is a good reason behind the current text...

Regards,

Christer




> Christer Holmberg wrote:
> > 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 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