Hi Paul,
It's 401 unauthorized error.
On 06-Jan-2017 11:15 PM, "Paul Kyzivat" <pkyzi...@alum.mit.edu> wrote:
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
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
