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