Regarding multiple subscriptions in the same dialog

ajay.kasamwipro.com wrote:
> Hi All,
>  
>  Here is the statement from RFC 3265
>     
>    A SUBSCRIBE request MAY include an "id"
parameter in its "Event"
>    header to allow differentiation between multiple
subscriptions in the
>    same dialog.
>  
> Could you please let me know the practical usecases for
this kind of 
> behaviour.

It is fairly obscure, especially since reusing dialogs is
being discouraged.

However a common case for reusing a dialog is to send a
REFER within an 
INVITE dialog. In that case there is no SUBSCRIBE - the
REFER acts as an 
implicit subscribe request, and the cseq of the REFER acts
as the event 
id. This will manifest itself in the resulting NOTIFY. An
actual 
SUBSCRIBE for this may eventually follow to refresh the
initial 
subscription established by the REFER. And in that case it
must contain 
the event id for the subscription it is refreshing.

It is then possible that an initial REFER request is
unsuccessful, and 
the original INVITE remains active in the dialog. And then
later there 
may be *another* attempt to do a REFER. In that case the
second REFER 
would result in a different event id, distinguishing the two
subscriptions.

Of course in this case its not really very important to
distinguish the 
two subscriptions, because they occur serially rather than
in parallel. 
But the way REFER is designed they are to have different
event ids.

Another case that might make sense would be with any kind of

subscription that allows a filter, such as presence. It
would be 
possible to establish one subscription with one filter, and
then later, 
within the same dialog, establish a different subscription
to the same 
event type but with a different filter or no filter at all.
In this case 
the event id would distinguish the two subscriptions.
However this is 
contrary to the current recommendations to establish such
subscriptions 
using separate dialogs.

	Paul


_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple