Subject: Re: [sipcore] Exception in RFC 3261 document

From: "Mojtaba Esfandiari.S" <[email-masked]>
Date: Sun, 27 Feb 2022 11:33:41 +0330

Hello there,
What up about the decision of this Exception in RFC3261 in section (8.1.1.5
CSeq)?
Thanks

On Thu, Dec 23, 2021 at 6:17 PM Mojtaba Esfandiari.S <
[email-masked]> wrote:

> Many thanks.
>
> On Thu, Dec 23, 2021, 18:05 Brian Rosen <[email-masked]> wrote:
>
>> 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.
>> Should I try more to report this?
>> cheers
>>
>> On Wed, Dec 22, 2021 at 1:46 AM Mojtaba Esfandiari.S <
>> [email-masked]> wrote:
>>
>>> 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]> wrote:
>>>
>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> 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]>
>>>>> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>> --
>>>>> 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>
>>>>>
>>>>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>