On 7/17/17 11:08 AM, Rakesh wrote:
Hi Expert,
Now I got the full picture for the problem.
SIP Registrar behavior for the URI contact matching
1) REGISTER request with belwo contact send to Registrar
Contact:
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=7200
2) Registrar sent 200OK with below contact
Contact:
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=7200
3) Now there is another REGISTER request send to the Registrar in
contact with additional parameter mentioned below
Contact:
""<sip:+1689998@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=ffffffff-ffffffff;srti=s1_2>;expires=7200
4) Then Registrar sent 200OK response with below contact headers. Where
the Initial contact has value expires= 0
Contact:
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0
Contact:
""<sip:+1689998@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=ffffffff-ffffffff;srti=s1_2>;expires=7200
So is it a valid behavior from Registrar server? Which leads the earlier
post asked for contact matching.
From 3261:
10.2.4 Refreshing Bindings
Each UA is responsible for refreshing the bindings that it has
previously established. A UA SHOULD NOT refresh bindings set up by
other UAs.
The 200 (OK) response from the registrar contains a list of Contact
fields enumerating all current bindings. The UA compares each
contact address to see if it created the contact address, using
comparison rules in Section 19.1.4. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the
Expires field value. The UA then issues a REGISTER request for each
of its bindings before the expiration interval has elapsed. It MAY
combine several updates into one REGISTER request.
A UA SHOULD use the same Call-ID for all registrations during a
single boot cycle. Registration refreshes SHOULD be sent to the same
network address as the original registration, unless redirected.
We have already discussed those comparison rules. So the second REGISTER
should qualify as a refresh. But apparently the registrar is not
recognizing it as such and instead is treating it as an additional
registration. That appears to be a bug in the registrar.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
