Hi Paul, Thanks now it's clear my idea about the behaviour. You are true on your feedback.
BR/// Rakesh Kumar Mohanty On Tue, Jul 18, 2017 at 9:01 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > 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.2 >> 1.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;Hp >> t=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;Hp >> t=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