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 <sip%3A%2B1689998@178.21.49.29>:3 694;transport=udp;Hpt=8ea2_16;ssn;TRC=ffffffff-ffffffff;srti=s1_2>;expires=7200 ? But since there is a difference in contact so it has to be overwritten with the previous contact of step1? 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. Can you please clarify? BR/// Rakesh Kumar Mohanty On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat <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: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 <sip%3A%2B168999@178.21.49.29>:36 >> 94;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 <sip%3A%2B1689998@178.21.49.29>:3 >> 694;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 <sip%3A%2B168999@178.21.49.29>:36 >> 94;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0 >> >> Contact: ""<sip:+168999@178.21.49.29 <sip%3A%2B1689998@178.21.49.29>:3 >> 694;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
