RFC3265 section 3.3.4 "Dialog creation and termination": 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. Rules for comparisons of the "Event" headers are described in section 7.2.1. 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).Usually the 2xx response to SUBSCRIBE creates the dialog on caller side, but if the NOTIFY is received first (which should be rare) it creates one too. The NOTIFY will have both a from-tag and a to-tag, in this sense it is different from the other dialog-creating requests
Jeroen ----- Original Message ----- From: "Michael Procter" <[EMAIL PROTECTED]> To: "Jeroen van Bemmel" <[EMAIL PROTECTED]>; "Matthew Gardiner" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, January 25, 2006 11:03 AM Subject: RE: [Sip-implementors] Dialog creation by SUBSCRIBE Jeroen van Bemmel wrote: > The full list of dialog creating requests is: INVITE, > SUBSCRIBE, NOTIFY, > REFER I'm not convinced about NOTIFY (the other three I completely agree with). I am aware of the 'out-of-dialog' NOTIFY messages used by some UAs, but I don't think they really count as dialog-creating. RFC3265 is somewhat evasive in section 3.2: 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. 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. I don't think I could read this as 'NOTIFYs can create dialogs' unless I squint really hard. It is more easily read as permitting REFER to do what it does, or allowing older devices to continue to send MWI NOTIFYs without an explicit SUBSCRIBE. I'd be interested in any references to prove me wrong though. Regards, Michael _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
