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

From: Robert Sparks <[email-masked]>
Date: Thu, 31 May 2012 09:44:32 -0500

(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<[email-masked]>
>
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 11:36:41 -0400

Commenting on the errata itself...

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

Because the retry is a new request, it is governed by all the normative 
requirements that apply to a new request. So the normative statements 
elsewhere about the CSeq value apply in this case.

For the retry of some arbitrary operation (e.g. OPTIONS) outside of a 
dialog there aren't any requirements other than that it be less than 
2^31. So indeed you could use the same CSeq value if you wished.

But if it was a REGISTER, then section 10.2 says the CSeq must be 
incremented by one. And if the request is within a dialog, then section 
12.2.1.1 also says the CSeq value must be incremented by one.

The lack of a normative statement *here* doesn't grant license to 
violate those rules.

So I don't see any error to be corrected.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Thu, 31 May 2012 09:12:39 -0700

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Robert Sparks
> Sent: Thursday, May 31, 2012 10:45 AM
> To: RFC Errata System
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)
> 
> > Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 May 2012 11:38:43 -0500

[as chair]

This list of recipients CCed on the email that started this thread is 
too long, and keeps getting caught up in the mailing list's moderation 
filter. This delays the messages being sent to the list, and requires me 
or Paul to go manually release them from the spam filter.

When replying to mailing list messages, please trim off any unnecessary 
recipients (or, at the very least, move them to your BCC list so they 
don't show up at the mailing list server).

Thanks!

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 31 May 2012 14:43:36 -0500

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

>> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
>> J. Peterson, R. Sparks, M. Handley, E. Schooler

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 31 May 2012 14:44:53 -0500

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

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 31 May 2012 14:50:01 -0500

> don't show up at the mailing list server).

Sorry, I replied to the messages in my inbox before reading to the 
folder that sipcore gets delivered to, so I hadn't seen your request 
before replying. That means my two replies are in the moderation queue 
as well.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 31 May 2012 15:54:13 -0400

[With a lot of people in the Bcc list.]

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

Expanding on what Bret Tate reported, what is "should" about the
statement in 8.1.3.5 is that the new sequence number is *one* higher
than the previous sequence number.  Section 22.2 states that the new
sequence number MUST be *higher*.  Thus, this case is specified in the
same way as all "successor" messages, the CSeq MUST be higher and
SHOULD be 1 higher.

Dale