Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion:

Agreed. The key here is to understanding what dialog state needs to be maintained, and the proposal as currently described does not seem to change that. It merely changes formal dialog state into something that does the same thing but is not formally defined.

Of course we could remove all state altogether, but that surely is PUBLISH.

Keith 

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale)
> Sent: Tuesday, January 04, 2011 3:54 PM
> To: gao.yang2@zte.com.cn; sipcore@ietf.org
> Subject: Re: [sipcore] About SUBSCRIBE method's performance 
> and Out-of-Dialog notification suggestion:
> 
> ________________________________________
> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On 
> Behalf Of gao.yang2@zte.com.cn [gao.yang2@zte.com.cn]
> 
> we can make a new type of subscription which would tear down 
> the dialog after the SUBSCRIBE(and the first NOTIFY), while 
> send the subsequent notification out-of-dialog.
> ________________________________________
> 
> I do not see that much saving could be obtained using the new 
> method.  The notifier would still need to maintain knowledge 
> of the pseudo-subscription, as it needs to know that it must 
> send NOTIFYs.  The subscriber would still need to maintain 
> knowledge of the pseudo-subscription, as it needs to be able 
> to interpret the received NOTIFYs, and it needs to refresh 
> the pseudo-subscription.
> 
> The only savings that I can identify are that if the 
> intermediate elements maintain state regarding subscription 
> dialogs.  The simple solution to such overhead is for the 
> intermediate elements *to not maintain state regarding 
> subscription dialogs*, either by being proper proxies (and 
> thus not maintaining state regarding *any* dialog), or by not 
> Record-Routing themselves during the creation of subscription 
> dialogs (and thus not needing to retain state regarding 
> subscription dialogs).
> 
> In either method, the notifier would need to know a URI that 
> routes directly to the subscriber.  In a subscription with no 
> Record-Routes, it would of necessity be the Contact URI in 
> the SUBSCRIBE.  In the new method, it could be defined in 
> another way, but the SUBSCRIBE Contact URI seems to be 
> sufficient.  In either method, the best solution seems to be 
> for the subscriber to have a GRUU to use as its Contact URI.
> 
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 