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.
> 
>You're conflating *initial* NOTIFYs with *refresh* NOTIFYs.
> 
>The subnot-etags document explicitly does not allow 
>suppression of initial NOTIFY messages. They are critical to 
>establishing a dialog.
>
>The text Dale cites relates exclusively to handling of 
>*initial* NOTIFYs. It is unrelated to the kinds of NOTIFY 
>messages that subnot-etags is allows to suppress.

Correct. I've been trying to say that, but I appologise if it didn't apply to Dale's case.

Regards,

Christer