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