[prev in list] [next in list] [prev in thread] [next in thread]
List: sip-implementors
Subject: Re: [Sip-implementors] Contact header URI comaprision
From: Rakesh <rakusw () gmail ! com>
Date: 2017-07-19 7:33:15
Message-ID: CANYcYTskf=g1yPDaXYKF5N8V41Aq0hR7xdRKNN_1VLNzL8sQ-g () mail ! gmail ! com
[Download RAW message or body]
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 <pkyzivat@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 <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic