Hi Dale,
Is the understanding correct?
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.
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.
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.
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?
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"?.
Regds
Anil N
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
08/11/2006 07:02 PM
To
sip-implementors@cs.columbia.edu
cc
Subject
Re: [Sip-implementors] Fw: Can there be subscriptions to a setof
dialogs(RFC4235)
From: [EMAIL PROTECTED]
I have a doubt in RFC 4235. Can there be a subscription for
a set of dialogs.
For ex:
Event:
Dialog;call-id=x;to-tag=y;from-tag=z;call-id=a;to-tag=b;from-tag=c
(Is this a valid mechanism for subscribing
to two dialogs)
No. Because the dialog event package subscription is not "to a
dialog". It is "to an address", and (presumably) by default returns
information for all dialogs active that the recipient address. Adding
the "call-id", etc., parameters gives you a subset of the information
that you would otherwise get. Hence, providing multiple "call-id"
parameters is either redundant (if they have the same value), or
contradictory (if they have different values) -- in practice, it is
(or should be) forbidden.
Also if there is a subscription for one dialog and that dialog is not
present, should the notifier
terminate the subscription by sending the notify body only with the
dialog
info element(No dialog elements).
No, it should not terminate the subscription.
No, sending a body with no dialog element does not terminate the
subscription. That can be done only with the Subscription-State
header.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*********************** FSS-Private ***********************
*********************** FSS-Private ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems (FSS)
and is intended solely for the use of
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be
circulated or used for any purpose other than for what it is intended. If you
have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
