| 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@xxxxxxxxxxxx]
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? 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 mailing list
|