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 > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
