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

Jeroen van Bemmel <jbemmel@zonnet.nl> Fri, 18 January 2008 07:26 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 1JFlc2-0003Is-45; Fri, 18 Jan 2008 02:26:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFlc1-0003In-0l for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:26:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlc0-0003IR-Lg for sip@ietf.org; Fri, 18 Jan 2008 02:26:00 -0500
Received: from smtp6.versatel.nl ([62.58.50.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFlbz-0002WB-Ld for sip@ietf.org; Fri, 18 Jan 2008 02:26:00 -0500
Received: (qmail 18310 invoked by uid 0); 18 Jan 2008 07:27:04 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jan 2008 07:27:04 -0000
Message-ID: <4790547E.8000009@zonnet.nl>
Date: Fri, 18 Jan 2008 08:25:50 +0100
From: Jeroen van Bemmel <jbemmel@zonnet.nl>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs
References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF041F5175@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF041F5175@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
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

Christer,

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.

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.

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)

Regarding Dale's case below, this can only occur if UAS1 has a broken SIP implementation (F1, F5 and F13 are 3 independent transactions)

Regards,
Jeroen

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