Subject: [sipcore] Exception in RFC 3261 document

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Sun, 19 Dec 2021 16:40:41 +0330

Hello Authors,
There is an exception related to RFC 3261.
In section (8.1.1.5 CSeq) mentioned: *" For non-REGISTER requests outside
of a dialog, the sequence number value is arbitrary."*
While in section (22.2 User-to-User Authentication) mentioned:* "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."*
 It should be updated in section 8.1.1.5 CSeq like this:
*" For non-REGISTER requests outside of a dialog and non-requests with
credentials after receiving a 401 (Unauthorized) or 407 (Proxy
Authentication Required) response, the sequence number value is arbitrary."*

With Best Regards

*-- Mojtaba Esfandiari.S*

*-- PhD student and Research Affiliate, *

*-- Technical Manager at IP-PBX Laboratory, Ferdowsi University of Mashhad,
Iran.*

-- Address: IP-PBX Lab., Engineering Faculty, Ferdowsi University Main
Campus, Mashhad, Iran.

-- Mobile: +98-915-117-6713

---

From: Liviu Chircu <[email-masked]>
Date: Mon, 20 Dec 2021 19:19:07 +0200

On 19.12.2021 15:10, Mojtaba Esfandiari.S wrote:
> *"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."*

But that's as arbitrary of a CSeq as it can be, right?  As I read 
8.1.1.5, the caller is simply free to choose their own starting CSeq.  
It can be the number *1* for all initial requests it ever builds - the 
server should still play along.

Best Regards,

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Tue, 21 Dec 2021 01:29:29 +0330

It can be arbitrary on starting initial requests, But for initial requests
after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required)
response, the initial requests with Authentication header, the sequence
number value must be incremented.
I have encountered this issue when working with Sems project.
The UE sends its request to Sems, then Sems relay the request to Asterisk
server. because in all INVITE messages, the Sems used the same CSeq value
(CSeq: 10 INVITE), asterisk goes to LOOP for authentication UE.
With Best.
Mojtaba Esfandiari.S

On Mon, Dec 20, 2021 at 8:49 PM Liviu Chircu <[email-masked]> wrote:

> *"When a UAC resubmits a request with its credentials after receiving a
> 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST
> But that's as arbitrary of a CSeq as it can be, right?  As I read 8.1.1.5,
> the caller is simply free to choose their own starting CSeq.  It can be the
> number *1* for all initial requests it ever builds - the server should
> still play along.
>
> Best Regards,
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>
>

---

From: Liviu Chircu <[email-masked]>
Date: Tue, 21 Dec 2021 06:55:02 +0200

On 20.12.2021 23:59, Mojtaba Esfandiari.S wrote:
> The UE sends its request to Sems, then Sems relay the request to 
> Asterisk server. because in all INVITE messages, the Sems used the 
> same CSeq value (CSeq: 10 INVITE), asterisk goes to LOOP for 
> authentication UE.

Then the UE is not RFC 3261-compliant, as it is disobeying the 
additional restrictions of § 22.2.

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Tue, 21 Dec 2021 13:49:11 +0330

Actually, the UE is obeying the RFC 3261, But the SEMS project is not RFC
3261 compliant.
It occurs because for 401 (Unauthorized) or 407 (Proxy Authentication
Required) response, the value of CSeq does not change.
So for more clarity and more understanding, It would be nice to have a
quiet bit of update in RFC 3261 section 8.1.1.5.
For example, the word "arbitrary" in the CSeq value may be confused with
the same value as before.
Thanks

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 21 Dec 2021 15:04:57 -0500

> the same value as before.

It's probably worth going through the Errata for RFC 3261 to see if this
has been reported before, and if not, adding a new erratum:
https://www.rfc-editor.org/errata_search.php?rfc=3261

Another place to report problems with the text of the RFC is:
http://bugs.sipit.net

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Dec 2021 20:06:36 +0000

Hi Mojtaba,

After an initial thought, your suggested clarification to section 8.1.1.5 seems correct. It could perhaps be more generic, though, and e.g.,say that specific procedures may define rules regarding the CSeq value. The 401/407 case could then be mentioned as an example.

In any case, may I suggest that you send your issue to the SIPCORE list?

Regards,

Christer

From: sipcore <[email-masked]> On Behalf Of Mojtaba Esfandiari.S
Sent: tiistai 21. joulukuuta 2021 12.19
To: Liviu Chircu <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] Exception in RFC 3261 document

Actually, the UE is obeying the RFC 3261, But the SEMS project is not RFC 3261 compliant.
It occurs because for 401 (Unauthorized) or 407 (Proxy Authentication Required) response, the value of CSeq does not change.
So for more clarity and more understanding, It would be nice to have a quiet bit of update in RFC 3261 section 8.1.1.5.
For example, the word "arbitrary" in the CSeq value may be confused with the same value as before.
Thanks

On Tue, Dec 21, 2021 at 8:25 AM Liviu Chircu <[email-masked]<mailto:[email-masked]>> wrote:

--
Liviu Chircu
www.twitter.com/liviuchircu<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-742427605f27b27a&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.twitter.com%2Fliviuchircu> | www.opensips-solutions.com<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-db93e02ae851094d&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.opensips-solutions.com%2F>

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Wed, 22 Dec 2021 01:22:13 +0330

Sure,
I have sent my issue to the SIPCore list and also have reported new Errata.
Thanks
Best Regards.
Mojtaba

On Tue, Dec 21, 2021 at 11:38 PM Christer Holmberg <
[email-masked]> wrote:

> Hi Mojtaba,
>
>
>
> After an initial thought, your suggested clarification to section 8.1.1.5
> seems correct. It could perhaps be more generic, though, and e.g.,say that
> specific procedures may define rules regarding the CSeq value. The 401/407
> case could then be mentioned as an example.
>
>
>
> *From:* sipcore <[email-masked]> *On Behalf Of *Mojtaba
> Esfandiari.S
> *Sent:* tiistai 21. joulukuuta 2021 12.19
> *To:* Liviu Chircu <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [sipcore] Exception in RFC 3261 document
>
>
>
> www.twitter.com/liviuchircu
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-742427605f27b27a&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.twitter.com%2Fliviuchircu>
> | www.opensips-solutions.com
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-db93e02ae851094d&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.opensips-solutions.com%2F>
>
>

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Wed, 22 Dec 2021 01:46:04 +0330

https://www.rfc-editor.org/errata_search.php?rfc=3261&eid=6793

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Thu, 23 Dec 2021 13:33:46 +0330

Hello All,
I have reported this problem here (sipcore mailing list) and the new Errata
for confirmation.
Should I try more to report this?
cheers

On Wed, Dec 22, 2021 at 1:46 AM Mojtaba Esfandiari.S <
[email-masked]> wrote:

>>> After an initial thought, your suggested clarification to section
>>> 8.1.1.5 seems correct. It could perhaps be more generic, though, and
>>> e.g.,say that specific procedures may define rules regarding the CSeq
>>> value. The 401/407 case could then be mentioned as an example.
>>>
>>>
>>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Dec 2021 09:35:17 -0500

No, we will deal with the errata and decide what to do.

Brian (co-chair of SIPCORE)

> On Dec 23, 2021, at 5:03 AM, Mojtaba Esfandiari.S <[email-masked]> wrote:
> 
> Hello All,
> I have reported this problem here (sipcore mailing list) and the new Errata for confirmation.
> On Wed, Dec 22, 2021 at 1:46 AM Mojtaba Esfandiari.S <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.rfc-editor.org/errata_search.php?rfc=3261&eid=6793 <https://www.rfc-editor.org/errata_search.php?rfc=3261&eid=6793>
> On Wed, Dec 22, 2021 at 1:22 AM Mojtaba Esfandiari.S <[email-masked] <mailto:[email-masked]>> wrote:
> Sure,
> On Tue, Dec 21, 2021 at 11:38 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Mojtaba,
> 
>  
> 
> From: sipcore <[email-masked] <mailto:[email-masked]>> On Behalf Of Mojtaba Esfandiari.S
> To: Liviu Chircu <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Tue, Dec 21, 2021 at 8:25 AM Liviu Chircu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> www.twitter.com/liviuchircu <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-742427605f27b27a&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.twitter.com%2Fliviuchircu> | www.opensips-solutions.com <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-db93e02ae851094d&q=1&e=15584eeb-52e0-4596-a64d-ab25cbbb7dcb&u=http%3A%2F%2Fwww.opensips-solutions.com%2F>_______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Thu, 23 Dec 2021 18:17:07 +0330

Many thanks.

On Thu, Dec 23, 2021, 18:05 Brian Rosen <[email-masked]> wrote:

>>>> _______________________________________________
> sipcore mailing list
> [email-masked]