The somewhat amusing part is that MSN Messenger appears to handle this dialog-less NOTIFY request without issues .. :(
So I am caught between following the standard, and following Microsoft. I'm leaning toward the standard. :) On Fri, 2003-07-11 at 04:57, [EMAIL PROTECTED] wrote: > Section 3.1.6.2 > > "Upon successfully accepting or refreshing a subscription, notifiers > MUST send a NOTIFY message immediately to communicate the current > resource state to the subscriber. This NOTIFY message is sent on the > same dialog as created by the SUBSCRIBE response" > > Section 3.2: > > "If any non-SUBSCRIBE mechanisms are defined to create subscriptions, > it is the responsibility of the parties defining those mechanisms to > ensure that correlation of a NOTIFY message to the corresponding > subscription is possible. Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is invalid, and > MUST receive a "481 Subscription does not exist" response" > > Section 3.2.4 > > "Upon receiving a NOTIFY request, the subscriber should check that it > matches at least one of its outstanding subscriptions; if not, it > MUST return a "481 Subscription does not exist" response " > > I think these are enough quotes for now :) > > Hisham > > > -----Original Message----- > > From: ext Natesan Kannan [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 11, 2003 11:27 AM > > To: Khartabil Hisham (NMP/Helsinki); [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Sip-implementors] RFC3265 question > > > > > > On the other hand, RFC (sec 3.2) hints of a NOTIFY outside > > the dialog for a > > subscription created by non-SUBSCRIBE methods, and this > > NOTIFY is deemed > > valid. > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Friday, July 11, 2003 12:38 PM > > Subject: RE: [Sip-implementors] RFC3265 question > > > > > > > The most common proxies are transaction stateful ones. They > > don't know and > > don't care if the request (NOTIFY in your example) within a > > dialog or not. > > > > > > Dialog stateful proxies, on the other hand, know and care > > if a request is > > within a dialog, but will most likely forward requests that > > they don't have > > dialog state for. > > > > > > In any case, if you receive a NOTIFY outside a dialog, you > > should reject > > it with a 481 response (normally NOTIFY must not be sent > > outside a dialog, > > but you never know what people implement out there). > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext David Stuart [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, July 11, 2003 5:09 AM > > > > To: Chris Boulton > > > > Cc: [EMAIL PROTECTED] > > > > Subject: Re: [Sip-implementors] RFC3265 question > > > > > > > > > > > > Thanks for the quick response, > > > > > > > > I agree that this is the right way to do things, but what I'm > > > > wondering > > > > is if there is any situation where NOTIFY requests could > > be validly > > > > received outside of a dialog? For instance, what about > > > > RFC2543 compliant > > > > proxies (was there even the concept of a dialog in those?) .. > > > > > > > > Chris Boulton wrote: > > > > > > > > >David, > > > > > > > > > > Sounds good to me. A 202 response is a 2xx class response and > > > > >creates the dialog - so the Notify messages would also be > > > > part of that > > > > >dialog. I don't see receiving a 202 different from > > receiving a 200 > > > > >response in terms of dialog creation. > > > > > > > > > >Regards, > > > > > > > > > >Chris. > > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: David Stuart [mailto:[EMAIL PROTECTED] > > > > >>Sent: 10 July 2003 15:52 > > > > >>To: [EMAIL PROTECTED] > > > > >>Subject: [Sip-implementors] RFC3265 question > > > > >> > > > > >>Hi All, > > > > >> > > > > >>I have a question regarding SUBSCRIBE and NOTIFY requests > > > > with a proxy > > > > >>in between, relating mostly to Dialogs. Here is the situation: > > > > >> > > > > >>1) One (registered) UA > > > > >>2) One proxy/registrar > > > > >> > > > > >>The UA registers to the proxy and immediately sends a > > > > SUBSCRIBE for a > > > > >>resource (for argument's sake let's use presence as an > > > > example since it > > > > >>is the most well known). > > > > >> > > > > >>The first subscribe request is outside of a dialog, and > > I believe is > > > > >>considered to be a dialog-creating request. As such, there > > > > is a CallId > > > > >>and the From: "tag" is set (but there is no "To:" "tag" yet). > > > > >> > > > > >>The proxy responds with a 202 Pending, and then sends a > > > > NOTIFY request > > > > >>with subscription-state pending. > > > > >> > > > > >>My question is, should this NOTIFY request be inside or > > > > outside of the > > > > >>dialog (I am assuming inside, but want to check).. That is > > > > to say, are > > > > >>the callId and both the From "tag" and To "tag" set at > > this point? > > > > >> > > > > >>-- > > > > >>David Stuart, SIPQuest > > > > >>phone: 254-8886 x234 web: http://www.sipquest.com/ > > > > >> > > > > >>_______________________________________________ > > > > >>Sip-implementors mailing list > > > > >>[EMAIL PROTECTED] > > > > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip-implementors mailing list > > > > [EMAIL PROTECTED] > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [EMAIL PROTECTED] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > -- David Stuart, SIPQuest phone: 254-8886 x234 web: http://www.sipquest.com/ _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
