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
Brett Tate wrote: >> 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. Replaces didn't exist with 2543, so a device supporting Replaces must be 3261 compliant. So I guess that is only meaningful if such a device is in a dialog with a 2543 compatible device. > If REFER sent over dialog by rfc2543 device that didn't include tag > during call setup, the NOTIFY will not contain a To tag. REFER also didn't exist with 2543. A REFER-compatible device also ought to be 3261 compatible and so use tags. > I only raise this point because it is the way I see that a NOTIFY > without a To tag complies with rfc3265. :) I guess this would be a good question for Adam, since he is author of 3265. Paul ___ 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
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
Brett Tate wrote: > 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)). The words may be ambiguous, but I don't think the intent is. Certainly the motivation for the existing wording was to accommodate REFER, and I suppose similar arrangements. Because of forking, the initiator of a dialog is really only partially aware initially. It knows that a dialog is expected, but not who it will be with, or even if it will be only one dialog or several. It has partial dialog information, consisting of the callid and the from-tag. This gets filled out by receipt of the to-tag. Normally the to-tag is received in a response before any other messages are sent in the context of the dialog. But that gets messed up by forked subscribes. For them the first awareness of the establishment of a dialog may be receipt of a NOTIFY. In that case the to/from tags are reversed, so that the to-tag and callid will match the subscriber's from-tag and callid, and the from-tag of the NOTIFY will be the missing to-tag of the subscribe. IMO the "implicit subscription" still must indeed be a subscription, which means that both parties are aware of it to the extent above. The to-tag and callid of the initial NOTIFY should contain the values the recipient is expecting to see. And after the initial notify, subsequent ones that are related should have a matching from-tag as well. 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. Its like the distinction between in-dialog MESSAGE and an out-of-dialog MESSAGE, except both of those are defined as valid. Paul ___ 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
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. 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
> 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. > 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
Re: [Sip-implementors] NOTIFY without SUBSCRIBE
This is non-standard unsolicited NOTIFY. You may accepts it for "message-summary" Event as many Voice Mail Servers are sending this unsolicited NOTIFY request. ~Vikram www.veraznetworks.com On Dec 11, 2007 10:39 AM, 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] NOTIFY without SUBSCRIBE
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
