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 > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors