From: [EMAIL PROTECTED]
1. If the Subscription has event header which doesnt share any
dialog identifiers, then a notification is generated every time
there is a change in the state of any dialogs for the user
identified in the request URI of the SUBSCRIBE.
Yes.
2. If Subscription to a specific dialog is requested(A kind of
filtering by subscriber), then the first three
parameters(Call-id,From-tag and To-Tag) of the event header MUST be
present, to identify the dialog that is being subscribed to. Then
a notification is generated every time there is a change in the
state of dialog matched by Event header parameters for the user
identified in the request URI of the SUBSCRIBE and not for all the
dialogs for the user identified in the request URI of the
SUBSCRIBE.
Yes.
In case of subscription to a "set of dialogs", :
1- The Subscription for a dialog and dialogs established due to forking
can be done by sharing the Call-Id
and To-tag(Half dilaog details) in the Event header.
Yes. The details are in section 3.2 of RFC 4235.
2- Can there be a Subscription for different set dialogs that the user
identified in the request URI of the SUBSCRIBE is
involved in(ie different call-id)?(For example :
Event:
Dialog;call-id=x;to-tag=y;from-tag=z;call-id=a;to-tag=b;from-tag=c )
Is this valid and can there be a subscription of the above kind?
No.
Also if there is a subscription for Single dialog(identified by
call-id,from-tag and to-tag in the event
header) and that dialog is not present, the notifier can terminate the
subscription by sending
the notify body only with the dialog info element(No dialog elements)and
subscription-state header
as "terminated"?.
The notifier can *always* terminate the subscription by sending a
notification with a subscription-state header of "terminated". It
must provide a valid notification body in that notification.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
