481 is the appropriate response for your scenario. 489 is intended to be sent by NOTIFIER when it does not understand Event header value.
Regards Pandu On Fri, May 29, 2009 at 10:58 AM, hanifa.mohammed < hanifa.moham...@globaledgesoft.com> wrote: > Hi, > > Also refer Sec "3.3.4. Dialog creation and termination" of same RFC: > > If an initial SUBSCRIBE request is not sent on a pre-existing dialog, > the subscriber will wait for a response to the SUBSCRIBE request or a > matching NOTIFY. > > Responses are matched to such SUBSCRIBE requests if they contain the > same the same "Call-ID", the same "From" header "tag", and the same > "CSeq". Rules for the comparison of these headers are described in > SIP [1]. If a 200-class response matches such a SUBSCRIBE request, > it creates a new subscription and a new dialog (unless they have > already been created by a matching NOTIFY request; see below). > > 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. > > [mohammed] > This is right that the NOTIFY must be matched based on all the > above. > The question is that when there is no match, there are two possibilities > 1 - dialog id itself does not match. So, 481 is opt and the > server cleans the subscrition. > 2 - dialog id matches but Event header does not mtch. So, if 489 > is sent, the server will > not clean the subscription but rather may try to send a corrected NOTIFY/ > or > do some corrective > action. > > Pl suggest. > > Best Regards, > Mohammed Hanifa > > > > _______________________________________________ > 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
