reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

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@xxxxxxxxxxx> 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@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?





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@xxxxxxxxxxxxxxxxxxxx


https://list.resiprocate.org/mailman/listinfo/resiprocate-devel



_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel