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

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

On 05/31/2012 11:12 AM, Brett Tate wrote:
> There are normative MUST increment statements else within RFC 3261 concerning the topic.  Thus if a UAC or proxy is ignoring the indication to increment cseq, they should not be surprised if it results in a 482 response.

Agreed; if there's no need to make the suggested change in a future 
update to RFC3261, I'm certainly fine with that. It just seemed like a 
reasonable suggestion :)

>
> Section 22.2:
>
>     "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."
>
> Section 22.3:
>
>    "The use of Proxy-Authenticate and Proxy-Authorization parallel that
>     described in [17], with one difference.  Proxies MUST NOT add values
>     to the Proxy-Authorization header field.  All 407 (Proxy
>     Authentication Required) responses MUST be forwarded upstream toward
>     the UAC following the procedures for any other response.  It is the
>     UAC's responsibility to add the Proxy-Authorization header field
>     value containing credentials for the realm of the proxy that has
>     asked for authentication.
>
>        If a proxy were to resubmit a request adding a Proxy-Authorization
>        header field value, it would need to increment the CSeq in the new
>        request.  However, this would cause the UAC that submitted the
>        original request to discard a response from the UAS, as the CSeq
>        value would be different."
>
> 8.2.2.2 Merged Requests
>
>     If the request has no tag in the To header field, the UAS core MUST
>     check the request against ongoing transactions.  If the From tag,
>     Call-ID, and CSeq exactly match those associated with an ongoing
>     transaction, but the request does not match that transaction (based
>     on the matching rules in Section 17.2.3), the UAS core SHOULD
>     generate a 482 (Loop Detected) response and pass it to the server
>     transaction.
>
>        The same request has arrived at the UAS more than once, following
>        different paths, most likely due to forking.  The UAS processes
>        the first such request received and responds with a 482 (Loop
>        Detected) to the rest of them.
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Robert Sparks
>> Sent: Thursday, May 31, 2012 10:45 AM
>> To: RFC Errata System
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)
>>
>> (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?
>>
>> What current IETF discussions are you pointing to below?
>>
>> 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
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore


-- 
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