Re: [Sip-implementors] NOTIFY without SUBSCRIBE
section 3.2 of rfc 3265 says - 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 (unless some other 400- or 500-class error code is more applicable), as described in section 3.2.4. In other words, knowledge of a subscription must exist in both the subscriber and the notifier to be valid, even if installed via a non-SUBSCRIBE mechanism. So sending 481 in this case is the correct behaviour Jack W. Lix [EMAIL PROTECTED] wrote: Hi all, Please confirm my understanding of subscribe for MWI. NOTIFY should not be sent to a UA unless a SUBSCRIBE has been sent to it. I'm doubting my understanding because I just got an asterisk server running and it immediately sends a NOTIFY after I REGISTER with it. The NOTIFY does not have Subscription-State header. Request-Line: NOTIFY sip:[EMAIL PROTECTED] SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.57:5060;branch=z9hG4bK03865702;rport From: asterisk ;tag=as50084360 To: Contact: Call-ID: [EMAIL PROTECTED] CSeq: 102 NOTIFY User-Agent: Jacks_Asterisk Max-Forwards: 70 Event: message-summary Content-Type: application/simple-message-summary Content-Length: 92 Message body Messages-Waiting: no\r\n Message-Account: sip:[EMAIL PROTECTED] Voice-Message: 0/0 (0/0)\r\n How do other UA's handle such a situation. I'm currently responding with 481. TIA, Jack ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - Save all your chat conversations. Find them online. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
On Dec 11, 2007 12:42 PM, Brett Tate [EMAIL PROTECTED] wrote: Please confirm my understanding of subscribe for MWI. NOTIFY should not be sent to a UA unless a SUBSCRIBE has been sent to it. RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. Some vendors use the concept to allow subscriptions to be created for their users (automatically or by extra configuration); other vendors view it as a violation of rfc3265. Correct me if I am wrong. In non-SUBSCRIBE mechanism that you have stated, the dialog gets created by some non-SUBSCRIBE mechanism and the NOTIFY comes as part of this dialog. Receiving a NOTIFY out of dialog does not imply creation of dialog as part of non-SUBSCRIBE mechanism. Unsolicited NOTIFY is always a violation of RFC. I'm doubting my understanding because I just got an asterisk server running and it immediately sends a NOTIFY after I REGISTER with it. The NOTIFY does not have Subscription-State header. Per rfc3265, Subscription-State header is mandatory within a NOTIFY. How do other UA's handle such a situation. I'm currently responding with 481. The 481 terminates the subscription; however don't be surprised if they automatically create another subscription if they continue to host the user with such configuration. ___ 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
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
Vikram Chhibber wrote: On Dec 11, 2007 12:42 PM, Brett Tate [EMAIL PROTECTED] wrote: Please confirm my understanding of subscribe for MWI. NOTIFY should not be sent to a UA unless a SUBSCRIBE has been sent to it. RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. Some vendors use the concept to allow subscriptions to be created for their users (automatically or by extra configuration); other vendors view it as a violation of rfc3265. Correct me if I am wrong. In non-SUBSCRIBE mechanism that you have stated, the dialog gets created by some non-SUBSCRIBE mechanism and the NOTIFY comes as part of this dialog. Receiving a NOTIFY out of dialog does not imply creation of dialog as part of non-SUBSCRIBE mechanism. Unsolicited NOTIFY is always a violation of RFC. Yes. But as the original poster noticed, this *is* used. It sounds like Asterisk uses it, and I'm sorry to say that a large networking company that I am quite familiar with also uses it, in spite of it being non-conforming. Paul I'm doubting my understanding because I just got an asterisk server running and it immediately sends a NOTIFY after I REGISTER with it. The NOTIFY does not have Subscription-State header. Per rfc3265, Subscription-State header is mandatory within a NOTIFY. How do other UA's handle such a situation. I'm currently responding with 481. The 481 terminates the subscription; however don't be surprised if they automatically create another subscription if they continue to host the user with such configuration. ___ 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 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
On Dec 11, 2007 12:42 PM, Brett Tate [EMAIL PROTECTED] wrote: Please confirm my understanding of subscribe for MWI. NOTIFY should not be sent to a UA unless a SUBSCRIBE has been sent to it. RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. Some vendors use the concept to allow subscriptions to be created for their users (automatically or by extra configuration); other vendors view it as a violation of rfc3265. Correct me if I am wrong. In non-SUBSCRIBE mechanism that you have stated, the dialog gets created by some non-SUBSCRIBE mechanism and the NOTIFY comes as part of this dialog. Receiving a NOTIFY out of dialog does not imply creation of dialog as part of non-SUBSCRIBE mechanism. As part of normal SUBSCRIBE forking, NOTIFY can basically create a dialog since related SUBSCRIBE 2xx might not be received. However I agree that the To tag would already be present. Unsolicited NOTIFY is always a violation of RFC. As far as I know, unsolicited NOTIFY violates rfc3265 (however I don't call notifies related to administrator configured subscriptions unsolicited). And I'm not aware of an RFC allowing NOTIFY to create a dialog (beyond what can occur because of forking). RFC3265 allows subscriptions to be created by non-SUBSCRIBE mechanisms which includes creation by administrator. If you are hosted by a server which enables your desire to receive message-summary without requiring SUBSCRIBE generated subscription and you also enable such configuration on the phone, some might call this solicited instead of unsolicited. I find rfc3265 somewhat ambiguous if such subscriptions MUST have a To tag when acting as a notifier. Thus I think there is some ambiguity about what should occur if no To tag is present within such a NOTIFY (especially when considering concepts like REFER related NOTIFY when tags not used during call setup (i.e. rfc2543 did not require tags)). ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
Certainly the motivation for the existing wording was to accommodate REFER, and I suppose similar arrangements. Yes; and subscriptions created through configuration (section 3.2.2). NOTIFYs that don't contain a to-tag don't identify an expected dialog, so I don't think they are consistent with a dialog established by other means. For backwards compatibility with rfc2543 devices, dialogs can exist without tags. For Replaces, RFC3891 defaults such situations as tag=0. If REFER sent over dialog by rfc2543 device that didn't include tag during call setup, the NOTIFY will not contain a To tag. I only raise this point because it is the way I see that a NOTIFY without a To tag complies with rfc3265. :) ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
