Adam is the expert, since he is the author of 3265.
And ignoring that I still agree with him.

3265 says that the NOTIFY will be sent within a dialog, except in the case of forking, where the first NOTIFY may complete the establishment of a dialog.

Its impossible to have a 3265 compliant usage that doesn't somehow have that dialog. All the "unsolicited notify" MWI usages I am aware are sent without an established dialog, and so are non conforming to 3265.

        Paul

Sumit Garg wrote:
It says, knowledge of the subscription (as in for a service/event) and
not the subscribe dialog (as identified by the dialog identifiers, as
there isn't any...thus nothing for the proxy to work on). 481 applies to
knowledge of the dialog identifiers  and thus would be generated by an
unsuspecting UA who does not know about a dynamic (which has dialog ids)
subscription or one negotiated through other means.

"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man."
-- George Bernard Shaw

-----Original Message-----
From: Adam Roach [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 9:40 AM
To: Sumit Garg
Cc: Brian Stucker; Dean Willis; Christer Holmberg; sip; Paul Kyzivat;
Michael Procter; Elwell,John
Subject: Re: [Sip] INFO

Sumit Garg wrote:
Unsolicited NOTIFYs are widely used for Voicemail and are allowed in
RFC3265

Um.... no.

Please refer to the following excerpt from the section you quoted.

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.

/a



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to