Rakesh,
You don't say, at step 8, what code is the UAS using to reject the new
register request?
Thanks,
Paul
On 1/6/17 7:50 AM, Rakesh wrote:
Hi Expert,
My understanding is this please correct if I am wrong,
Step 1) UE sent REGISTER with CSequence Number: 1804289384 and Call-ID:
28335007c4047a42
Step 2) 401 with CSequence Number: 1804289384 and Call-ID: 28335007c4047a42
Step 3) After challenge UE sent the REGISTER with CSequence Number:
1804289385 and Call-ID: 28335007c4047a42
Step 4 ) 200OK with same CSequence Number: 1804289385 and Call-ID:
28335007c4047a42which is expected .
Call Continue... Everything is OK
Step 5) UE sent DE-REGISTRATION with CSequence Number: 1804289386 and
Call-ID: 28335007c4047a42
Step 6) 200OK for DE-REGISTRATION with same with CSequence Number:
1804289386 and Call-ID: 28335007c4047a42 which is also expected . Here all
contacts are removed (all AOR binding clear)
Step 7) UE now sent another fresh REGISTER request with CSequence Number:
1804289384 and Call-ID: ee74e9624ebe1844
Step 8)
UAS
is now rejecting continuously the REGISTER.
So the question is in Step 7 ) the call id now changed to Call-ID:
ee74e9624ebe1844 and as per RFC 3261 it says ,
10.3 <https://tools.ietf.org/html/rfc3261#section-10.3> Processing REGISTER
Requests
Point 7.
For each address, the registrar then searches the list of
current bindings using the URI comparison rules. If the
binding does not exist, it is tentatively added. *If the*
* binding does exist, the registrar checks the Call-ID value. If*
* the Call-ID value in the existing binding differs from the*
* Call-ID value in the request, the binding MUST be removed if*
* the expiration time is zero and updated otherwise.* If they are
the same, the registrar compares the CSeq value. If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above. If not, the update MUST be
aborted and the request fails.
In our case the Call-ID: ee74e9624ebe1844 value us differ from the previous
one so the UAS should update the binding and accept the REGISTER request
instead rejecting it with 401.
*Best Regards*
*Rakesh Kumar Mohanty*
On Fri, Jan 6, 2017 at 4:44 PM, Mohit Soni <mohitsoni2...@gmail.com> wrote:
Hi Rakesh,
Full trace of your scenario or at least the message body of the fresh
REGISTER message sent from UE with new Call-ID may help figure out things.
Regards,
Mohit Soni
On Fri, Jan 6, 2017 at 4:02 PM, Rakesh <rak...@gmail.com> wrote:
Hi Expert,
I need one info for the following below SIP REGISTER scenario.
Step 1) UE sent REGISTER with CSeq =1 CallID=100001
Step 2) 401 with CSeq =1 CallID=100001
Step 3) After challenge UE sent the REGISTER with CSeq =2 CallID=100001
Step 4 ) 200OK with same CSeq =2 CallID=100001 which is expected .
Call Continue... Everything is OK
Step 5) UE sent DE-REGISTRATION with CSeq =3 CallID=100001
Step 6) 200OK for DE-REGISTRATION with same CSeq =3 CallID=100001 which
is
expected . Here all contacts are removed (all AOR binding clear)
Step 7) UE now sent another fresh REGISTER request with CSeq =1
CallID=100002
Step 8) UAS is now rejecting continuously the REGISTER.
So the question is in Step 7 ) the call id now changed to 100002 and as
per
RFC 3261 it says
The first question is,
It says 8.1.1.4 Call-ID
The Call-ID header field acts as a unique identifier to group together
a series of messages. It MUST be the same for all requests
and responses sent by either UA in a dialogue.
*It SHOULD be the same in each registration from a UA.*
*Best Regards*
*Rakesh Kumar Mohanty*
_______________________________________________
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 mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
