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

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.

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: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of Robert Sparks
> Sent: Thursday, May 31, 2012 10:45 AM
> To: RFC Errata System
> Cc: jdrosen@dynamicsoft.com; schooler@research.att.com;
> rsparks@dynamicsoft.com; schulzrinne@cs.columbia.edu; sipcore@ietf.org;
> drage@alcatel-lucent.com; alan.johnston@wcom.com; mjh@icir.org;
> jon.peterson@neustar.com; dean.willis@softarmor.com;
> kpfleming@digium.com
> 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<kpfleming@digium.com>
> >
> > 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore