Re: [reSIProcate] [PATCH] reSUBSCRIBE will fail if the server fails to send NOTIFY
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
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature