[reSIProcate] [PATCH] reSUBSCRIBE will fail if the server fails to send NOTIFY

[Robert Sparks]

I'm happiest if DUM does this. Those immediate NOTIFYs are there for  
a reason in the general case.

There are explicit extensions for suppressing the immediate notify  
and notifies due to subscribe refreshes - we can look at supporting
those.

RjS

On Jan 23, 2007, at 4:51 PM, Jason Fischl wrote:

> I thought that we had discussed the correct behavior if a 2XX to the
> SUBSCRIBE is received with no corresponding NOTIFY and decided that
> the watcher should terminate the subscription in this case. I realize
> this won't interop well with ser. Any comments?
>
> Jason
>
>
> On 1/23/07, Robert Sparks <rjsparks at nostrum.com> wrote:
>> If you go down this path, you might run into problems  with ONE of  
>> the
>> dialogs created by the forked subscribe (the one which you saw the  
>> 2xx for).
>> Aren't these timers set with what's an effective serial # anyway? You
>> wouldn't send the extra resubscribe in that case.
>>
>> And _please_ do not introduce any code distinctions between a 200- 
>> SUBSCRIBE
>> and a 202-SUBSCRIBE. There is no case where you won't do
>> exactly the same thing after receiving them. Its presence in the  
>> specs is an
>> artifact of ways we thought we were going to handle authentication  
>> that
>> didn't work out (remember QUATH?).  Several of us will be fighting  
>> hard to
>> remove the distinction from the spec when we rev 3265.
>>
>> RjS
>>
>>
>> On Jan 23, 2007, at 3:59 PM, Byron Campen wrote:
>>
>>  Ah, yes, we don't pass extra 200s up in NITs. Sorry, what I'm  
>> getting at is
>> what happens if this SUBSCRIBE gets forked? We could end up  
>> sending extra
>> reSUBSCRIBEs (if we set timers for both 200 and NOTIFY), or we  
>> could end up
>> failing to send reSUBSCRIBEs to the other targets whose 200s  
>> didn't make it
>> to us (if we set timers only on the 200). On another subject, is it
>> appropriate to set timers for reSUBSCRIBE when we receive a 202?  
>> Should we
>> make sure it is a 200 before we do this sort of thing?
>>
>> Best regards,
>> Byron Campen
>>
>>
>>
>> Will dum even see multiple 200's for a subscribe – are they not  
>> absorbed by
>> the stack?
>>
>>
>>
>>
>>
>> From: Byron Campen [mailto:bcampen at estacado.net]
>> Sent: Tuesday, January 23, 2007 4:34 PM
>> To: Scott Godin
>> Cc: resiprocate-devel; Aron Rosenberg
>> Subject: Re: [reSIProcate] [PATCH] reSUBSCRIBE will fail if the  
>> server fails
>> to send NOTIFY
>>
>>
>>
>>
>>           Will this work properly if we get multiple 200s?
>>
>>
>>
>>
>>
>> Best regards,
>>
>>
>> Byron Campen
>>
>>
>>
>> If you are using subscriptions there is a chance that the stack  
>> will not
>> issue a reSUBSCRIBE. The main way this can happen is if the  
>> presence server
>> does NOT issue a NOTIFY upon resiprocate sending out a reSUBSCRIBE  
>> and no
>> NOTIFY's are issued during the time of the subscription.
>>
>>
>>
>> This patch adds the reSUBSCRIBE timer upon receiving the 200 OK to  
>> the
>> SUBSCRIBE request instead of only adding the timer upon receipt of  
>> a NOTIFY.
>>
>>
>>
>> The OpenSER presence server currently exhibits this broken behavior.
>>
>>
>>
>> There doesn't appear to be any harm to adding the timer on the 200 OK
>> instead of waiting for the NOTIFY and it fixes the bug of the  
>> subscription
>> not getting renewed later.
>>
>>
>>
>>
>>
>> Aron Rosenberg
>>
>> SightSpeed Inc.
>>
>> http://www.sightspeed.com
>>
>>
>>
>>
>> <resiprocate_subscribe_timer.diff>
>>
>>
>> _______________________________________________
>>
>>
>> resiprocate-devel mailing list
>>
>>
>> resiprocate-devel at list.resiprocate.org
>>
>>
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>