Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)

["Kevin P. Fleming" <[e-mail]>]

On 05/31/2012 09:44 AM, Robert Sparks wrote:
> (adding the sipcore list)
>
> Kevin -
>
> The important part of "new transaction" is the branch identifier. Are
> the issues you're having
> really with transaction identification? (I could only see that being the
> case if you had 2543 elements
> involved.) Or is the real pain with policy on what a response to a
> digest challenge has to look like?

Neither; the offending UA appears to treat an INVITE retry (caused by 
receiving a 401/407 responses) as some sort of 'partial' new dialog, and 
assigns a random CSeq to it rather using that last CSeq in the dialog 
plus one.

>
> What current IETF discussions are you pointing to below?

I've seen a few threads on the general IETF discussion list about people 
wanting to stop allowing SHOULD/SHOULD NOT in RFCs. In this case, if 
these were MUST, there would be no possibility of misinterpretation.

>
> RjS
>
> On 5/31/12 7:57 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC3261,
>> "SIP: Session Initiation Protocol".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=3237
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Kevin P. Fleming<[e-mail]>
>>
>> Section: 8.1.3.5
>>
>> Original Text
>> -------------
>> In all of the above cases, the request is retried by creating a new
>> request with the appropriate modifications. This new request
>> constitutes a new transaction and SHOULD have the same value of the
>> Call-ID, To, and From of the previous request, but the CSeq should
>> contain a new sequence number that is one higher than the previous.
>>
>> Corrected Text
>> --------------
>> In all of the above cases, the request is retried by creating a new
>> request with the appropriate modifications. This new request
>> constitutes a new transaction and SHOULD have the same value of the
>> Call-ID, To, and From of the previous request, but the CSeq SHOULD
>> contain a new sequence number that is one higher than the previous.
>>
>> Notes
>> -----
>> We have had one implementor claim that they are not required to
>> increment CSeq when retrying the request because the RFC says 'should'
>> and not 'SHOULD'. Based on current IETF discussions, though, these
>> should probably be changed to MUST anyway, but that's a much more
>> substantive change throughout the whole RFC.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC3261 (draft-ietf-sip-rfc2543bis-09)
>> --------------------------------------
>> Title : SIP: Session Initiation Protocol
>> Publication Date : June 2002
>> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
>> J. Peterson, R. Sparks, M. Handley, E. Schooler
>> Category : PROPOSED STANDARD
>> Source : Session Initiation Protocol
>> Area : Real-time Applications and Infrastructure
>> Stream : IETF
>> Verifying Party : IESG


-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [e-mail] | SIP: [e-mail] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org