Re: [Sip-implementors] CSeq in subsequent Register messages
On 6/28/22 4:19 AM, Gilson Urbano Ferreira Dias wrote: Dale, The three pseudo-dialogs are for different AORs. It would be very helpful if you would post the full messages. Thanks, Paul Does this change anything in the analysis? Regards, Gilson Urbano ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] CSeq in subsequent Register messages
Filippos, They are 3 different (Call-ID, tag, Contact, From, and To) Register requests using the same CSeq, and from the same server. I think the server is not following 10.2 because the second Register message containing a different Contact header is sent before the final response of the first one: >From 10.2: UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Now, suppose we have two subsequent Register requests with a final response and using a different Contact header. Is it undefined behavior if both use the same CSeq? <-Request: Register (Cseq = 1 Contact=1)- --Status: 200 OK(Cseq = 1 Contact=1)-> <-Request: Register (Cseq = 1 Contact=2)- --Status: 200 OK(Cseq = 1 Contact=2)-> Regards, Gilson Urbano ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] CSeq in subsequent Register messages
Dale, The three pseudo-dialogs are for different AORs. Does this change anything in the analysis? Regards, Gilson Urbano ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] CSeq in subsequent Register messages
Gilson Urbano Ferreira Dias writes: > Suddenly, the server decided to send CSeq = 1 in three consecutive Register > messages for different Call-Ids. > > I tried reading https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1 and > https://www.rfc-editor.org/rfc/rfc3261#section-8.1.1.5, but I'm still not > sure if this is the expected behavior. > > Could someone please clarify? > > A--Request: INVITE (Call-ID = A) (Cseq 932841)>B > <--Status: 100 Trying (Call-ID = A) (Cseq 932841) > <--Status: 200 OK (Call-ID = A) (Cseq 932841) > ---Request: ACK (Call-ID = A) (Cseq 932841)> > > <--Request: Register(Call-ID = B) (Cseq 1)- > <--Request: Register(Call-ID = C) (Cseq 1)- > ---Status: 200 OK (Call-ID = B) (Cseq 1)-> > <--Request: Register(Call-ID = D) (Cseq 1)- > ---Status: 200 OK (Call-ID = C) (Cseq 1)-> > ---Status: 403 Forbidden(Call-ID = D) (Cseq 1)-> The crux is that all the REGISTER messages with a given Call-ID value form a "pseudo-dialog" in that they don't form a proper dialog, but they are all associated, in sequence, regarding *one* registration binding. A consequence is that if two REGISTER messages have different Call-IDs, they are not related, and the fact that they have the same CSeq is of no matter. You have not described what AORs the various REGISTER pseudo-dialogs are for. What you describe would be the common behavior if the three pseudo-dialogs were for different AORs. The 403 response for Call-ID D most likely has to do with the authentication presented in the REGISTER for Call-ID. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] CSeq in subsequent Register messages
>From 10.2: CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. So my guess is that if it's the same request (same Contact header, Call-ID, expiration etc), it can be the same CSeq. In any case you should follow the 10.3 to figure out what you should do with the Register request. /Filippos On Mon, Jun 27, 2022 at 5:04 PM Gilson Urbano Ferreira Dias < gilsonur...@gmail.com> wrote: > Can I have the same CSeq numbering originating from the same server in > Register messages? > > Note that the previous messages were being incremented by one as CSeq = > ..., 932840, 932841. > > Suddenly, the server decided to send CSeq = 1 in three consecutive Register > messages for different Call-Ids. > > I tried reading https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1 > and > https://www.rfc-editor.org/rfc/rfc3261#section-8.1.1.5, but I'm still not > sure if this is the expected behavior. > > Could someone please clarify? > > A--Request: INVITE (Call-ID = A) (Cseq = > 932841)>B > <--Status: 100 Trying (Call-ID = A) (Cseq = > 932841) > <--Status: 200 OK (Call-ID = A) (Cseq = > 932841) > ---Request: ACK (Call-ID = A) (Cseq = > 932841)> > > <--Request: Register(Call-ID = B) (Cseq = > 1)- > <--Request: Register(Call-ID = C) (Cseq = > 1)- > ---Status: 200 OK (Call-ID = B) (Cseq = > 1)-> > <--Request: Register(Call-ID = D) (Cseq = > 1)- > ---Status: 200 OK (Call-ID = C) (Cseq = > 1)-> > ---Status: 403 Forbidden(Call-ID = D) (Cseq = > 1)-> > > Regards, > > Gilson Urbano > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] CSeq in subsequent Register messages
Can I have the same CSeq numbering originating from the same server in Register messages? Note that the previous messages were being incremented by one as CSeq = ..., 932840, 932841. Suddenly, the server decided to send CSeq = 1 in three consecutive Register messages for different Call-Ids. I tried reading https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1 and https://www.rfc-editor.org/rfc/rfc3261#section-8.1.1.5, but I'm still not sure if this is the expected behavior. Could someone please clarify? A--Request: INVITE (Call-ID = A) (Cseq = 932841)>B <--Status: 100 Trying (Call-ID = A) (Cseq = 932841) <--Status: 200 OK (Call-ID = A) (Cseq = 932841) ---Request: ACK (Call-ID = A) (Cseq = 932841)> <--Request: Register(Call-ID = B) (Cseq = 1)- <--Request: Register(Call-ID = C) (Cseq = 1)- ---Status: 200 OK (Call-ID = B) (Cseq = 1)-> <--Request: Register(Call-ID = D) (Cseq = 1)- ---Status: 200 OK (Call-ID = C) (Cseq = 1)-> ---Status: 403 Forbidden(Call-ID = D) (Cseq = 1)-> Regards, Gilson Urbano ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
