On 7/18/17 4:00 AM, Rakesh wrote:
Hi Paul,
Thanks for the update.
So the 200OK in step 4 Registrar should respond with only one contact
header
Contact: ""<sip:+168999@178.21.49.29
<mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=ffffffff-ffffffff;srti=s1_2>;expires=7200
?
Yes.
But since there is a difference in contact so it has to be overwritten
with the previous contact of step1?
I don't understand what you are trying to say with this last sentence.
In my earlier reply I quoted the wrong section of 3261. (It was the
section for clients, not registrars.) The applicable portion is from
steps 7&8 of section 10.3:
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.
...
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. ...
Hence it is clear that new contact value must be recorded by the
registrar and returned in the response.
Currently, the Registrar is working in the below way,
Contact:
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0
Contact:
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=ffffffff-ffffffff;srti=s1_2>;expires=7200
Since the both the contact are same as per 19.1.4 it is only keeping the
contact header value of the second REGISTER request.
Again I don't understand your point. The response enumerate all
*current* bindings. Because it is returning two URIs it must think that
they are both current. Yet they compare equal so the registrar should
have replaced the old one with the new one, and hence there should only
be one current contact - the new one.
Thanks,
Paul
Can you please clarify?
BR///
Rakesh Kumar Mohanty
On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
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
<mailto:sip%3A%2B168999@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
<mailto:sip%3A%2B168999@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:+168999@178.21.49.29
<mailto:sip%3A%2B1689998@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
<mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0
Contact: ""<sip:+168999@178.21.49.29
<mailto:sip%3A%2B1689998@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
