I agree with all Dale has said on this.
Adding to that - it is also possible that there is *another* device that
is sending register or unregister requests for the *same* contacts as
your UA. Its not a *likely* scenario in most cases, but it is
*possible*. This can lead to all sorts of odd state transitions.
Just get over it - code your UA to cope with the responses it gets,
rather than just the ones it wishes to get.
Thanks,
Paul
Dale Worley wrote:
>> <<Krish-Start>>
>> The contacts A1 & A2 from the UA's perspective are just different ways
>> to get a call delivered to it. UA does not intend to prioritize one over
>> the other. What would be the need for the server in this case to return
>> different expires. While I understand that theoretically it is possible
>> I am not sure I understand why a server would want to (or need to) treat
>> these different.
>
> It doesn't matter *why* a server would do this. You will, sooner or
> later, run into a server that does. If your UA depends on a server not
> doing this, your UA will break.
>
>> 1. Are there servers out in the world that treat the contacts from the
>> same device independently and generate NOTIFYs with different state
>> attributes? If so, in what cases?
>
> There certainly are such servers. I do not personally know of one at
> this moment. But RFC 3261 permits a server to behave this way, so there
> certainly are some correctly functioning servers that do so.
>
>> 2. I can understand the need for a state attribute to be present at the
>> individual contact level in the XML (Two devices can register the same
>> AOR and have independent life cycles). However from a UA that needs to
>> handle reg-events for Contacts that are all associated with the AOR I
>> see unified handling of all contacts as simpler and possible.
>
> However RFC 3680 says that the state of each registration is given
> individually. Hence some server will present different states for two
> contacts in situations where their state is not precisely synchronized.
>
> Dale
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
