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

[Adam Roach <[e-mail]>]

On 4/6/10 15:02, Apr 6, Christer Holmberg wrote:
> 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.

/a