Subject: [Simple] Regarding multiple subscriptions in the same dialog

From: <[email-masked]>
Date: Thu, 28 Jun 2007 13:13:01 +0530

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.
 
Regards
Ajay Kasam
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jun 2007 09:10:05 -0400

> Could you please let me know the practical usecases for this kind of 

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