Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted]

[Christer Holmberg <[e-mail]>]

Hi,

>>In any case, proxies don't inherently care about subscription state. If
>>you're doing something in your proxy that is attempting to figure out
>>the state of a subscription, you need to take care to figure out what's
>>going on. In that case, yeah, Timer N is going to be of interest to you.
>>But that's not something we need to specify -- it's actually very
>>application-specific.
>
>The draft says that proxies no not need to support anything in addition to 3261, so from that point of view you are correct.
>
>However, at the same time it talks about proxies adding Record-Route if they are interested in the SUBs and NOTs, so I assumed that means that they are "allowed" to actually maintain subscription dialog state - in the same way as they might maintain invite dialog state.
>_______________________________________________
>
>Even if a proxy is keeping subscription-state information, I don't see Timer N introducing a problem.  The proxy sees all the SUBSCRIBEs and NOTIFYs and their responses.  Under 3265bis, the NOTIFYs, actually, the the *responses* to the NOTIFYs show all of the 
>subscription state.  In particular, in seciton 4.1.2.4, I see:
>
>   Until Timer N expires, several NOTIFY messages may arrive from
>   different destinations (see Section 4.4.1).  Each of these messages
>   establish a new dialog and a new subscription.  After the expiration
>   of Timer N, the subscriber SHOULD reject any such NOTIFY messages
>   that would otherwise establish a new dialog with a "481" response
>   code.

Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cause issues, because it allows the NOTIFY to be suppressed. Now, if the proxy does not support that draft, and it doesn't receive a NOTIFY (since it has been suppressed) it could terminate the subsciption dialog state.

Please also note that my issue is related to re/de-subscriptions, when all dialogs already exist.

Regards,

Christer