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

[Robert Sparks]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070123/989f67b0/attachment.htm>