> 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
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to