2009/7/20 Michael Procter <mich...@voip.co.uk>: >> Sorry, but those other NOTIFY will have a different From-tag so they >> will discarded with 481 by the subscriber as they don't match the >> dialog (From-tag, To-tag and Call-ID) established by the subscriber >> and the server whose 200 arrived to the subscriber. > > RFC 3265 Section 3.3.4, 3rd para: > NOTIFY requests are matched to such SUBSCRIBE requests if they > contain the same "Call-ID", a "To" header "tag" parameter which > matches the "From" header "tag" parameter of the SUBSCRIBE, and the > same "Event" header field. [...] If a matching NOTIFY request > contains a "Subscription-State" of "active" or "pending", it creates > a new subscription and a new dialog (unless they have already been > created by a matching response, as described above).
You are 100% right, thanks for the great clarification. However I consider this specification completely *exotic* and complex. Surely just a few implementations (if any) do it correctly. IMHO forking shouldn't exist for SUBSCRIBE. Presence is 99% handled by presence agents (presence server) so forking makes no sense. And dialog subscription (which theorically is a SUBSCRIBE arriving to the final UA) is also handled by presence agents (PBX). Since this is the real scenario usages (and they will be) IMHO it doesn't make sense so complex specification which just makes it hard to understand and implement, adding no benefict at all in the real world. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
