On 3/23/12 11:36 AM, Kevin P. Fleming wrote:
> On 03/23/2012 10:14 AM, Worley, Dale R (Dale) wrote:
>>> From: Vivek Batra [[email protected]]
>>>
>>> Now Registrar server has two registration bindings of same physical UA viz
>>> IP1 and IP2. Till the timeout of IP1 (by default 3600 seconds), that binding
>>> (IP1) shall remain live in the registrar server. Any proxy module requesting
>>> registrar sever for the location information of UA gets two binding viz IP1
>>> and IP2 however IP1 nowhere exists in the network. Any solution to take care
>>> of this?
>>
>> This situation is not a problem, and therefore does not need a
>> solution: A request sent to the AOR will be parallel forked to both
>> Contact 1 and Contact 2. Clearly, the request to Contact 1 will
>> receive no response. But the request to Contact 2 will reach the UA
>> and receive the proper responses. The request to Contact 1 will be
>> abandoned or terminated either by timeout or when the UA sends a final
>> response.
>
> Well... pedantically, the request to Contact 1 *may* receive a response,
> if the DHCP server in question has reassigned the address within the
> expiration time of the registration and the device at that address
> happens to have a SIP UA listening on the port specified in the Contact
> URI :-) In that case, I'd expect the fork of the INVITE that went to
> Contact 1 to result in a '404' response.
Sure, that *could* happen. But it *shouldn't* happen for well behaved
UAs. If the UA has a dynamically assigned address, it should set the
expiration time for the registration to be no later than the expiration
time for the address.
Regarding the main point, again a well behaved UA can mitigate the
problem. When registering its newly assigned contact IP2, it could also
check for a prior registration by itself. If found, it can remove that
one. Of course to do this it must recognize the contact as its own. It
could use a contact header parameter for that. Or, if outbound is in
use, it can take care of all this.
Thanks,
Paul
> This is yet another case where a UA sending a request can expect
> responses to have some amount of 'reasonableness', but it should be
> prepared for responses to contain completely unexpected contents.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
