On 1/6/17 12:52 PM, Rakesh wrote:
Hi Paul,
It's 401 unauthorized error.
Do you then use the challenge to generate new credentials for a retry,
just as you did in the first round?
Thanks,
Paul
On 06-Jan-2017 11:15 PM, "Paul Kyzivat" <pkyzi...@alum.mit.edu
<mailto: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
<tel:1804289384> and Call-ID:
28335007c4047a42
Step 2) 401 with CSequence Number: 1804289384 <tel:1804289384>
and Call-ID: 28335007c4047a42
Step 3) After challenge UE sent the REGISTER with CSequence Number:
1804289385 <tel:1804289385> and Call-ID: 28335007c4047a42
Step 4 ) 200OK with same CSequence Number: 1804289385
<tel:1804289385> and Call-ID:
28335007c4047a42which is expected .
Call Continue... Everything is OK
Step 5) UE sent DE-REGISTRATION with CSequence Number:
1804289386 <tel:1804289386> and
Call-ID: 28335007c4047a42
Step 6) 200OK for DE-REGISTRATION with same with CSequence Number:
1804289386 <tel: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 <tel: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
<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 <mailto: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
<mailto: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
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<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
