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

[Jason Fischl]

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