Sarika Gupta wrote:
Hello Paul
So does this mean a UA receiving NOTIFY out of context of a REFER or SUBSCRIBE should discard the same?
Well, I think it deserves an error response.
NOTIFY is *supposed* to be delivered within a dialog, or in certain cases to establish a dialog. So it is supposed to have a From-tag and To-tag. If it does, and no matching dialog is expected (based on prior SUBSCRIBE or REFER), then I think the proper response is 481.
If the NOTIFY has no from/to tags, then I'm not sure what error is appropriate. Perhaps 400.
There are however implementations that accept unsolicited NOTIFY messages outside dialogs. That is a proprietary extension.
And what has been the mistake Is it the text in RFC 3265 or using only 2 methods (REFER/NOTIFY)?
I don't understand what you are asking. What is the wrong with the NOTIFY that doesn't have a dialog?
Please let me know.
Regards
Sarika
*/Paul Kyzivat <[EMAIL PROTECTED]>/* wrote:
Sarika Gupta wrote: > Hi > As per RFC 3265, > "NOTIFY messages are sent to inform subscribers of changes in state to > which the subscriber has a subscription. Subscriptions are typically > put in place using the SUBSCRIBE method; however, it is possible that > other means have been used." > Now what are these other means is it possible to subscribe for some event using provisioning? > Another question is it valid for a UAS to send a NOTIFY to a UA for which no explicit SUBSCRIBE/REFER method request has been received?
The only current example of a subscription established via other means is REFER. And this is now generally acknowledged to have been a mistake.
Paul
------------------------------------------------------------------------ Do you Yahoo!? Meet the all-new My Yahoo! <http://my.yahoo.com> – Try it today!
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
