[OpenSIPS-Devel] [Proposal] Destroy subscription if NOTIFY received 408

Anca Vamanu anca.vamanu at gmail.com
Wed Jan 25 19:49:36 CET 2012


Hi Saul,

Totally agree with you. In fact in b2b modules I have respected that part
of RFC and deleted on both 481 and 408 reply codes.
Since I looked in the code for presence, I also did the change and
committed it.

Regards,
Anca

On Wed, Jan 25, 2012 at 11:23 AM, Andrew Pogrebennyk <
apogrebennyk at sipwise.com> wrote:

> Saúl,
> Sounds right. Actually the required behavior is further detailed in RFC
> 3265 paragraph 3.2.2:
>
>  If the NOTIFY request fails (as defined above) due to a timeout
>   condition, and the subscription was installed using a soft-state
>   mechanism (such as SUBSCRIBE), the notifier SHOULD remove the
>   subscription.
> ...
>   If the NOTIFY request fails (as defined above) due to an error
>   response, and the subscription was installed using a soft-state
>   mechanism, the notifier MUST remove the corresponding subscription.
> ...
>   If a NOTIFY request receives a 481 response, the notifier MUST remove
>   the corresponding subscription even if such subscription was
>   installed by non-SUBSCRIBE means (such as an administrative
>   interface).
> http://tools.ietf.org/html/rfc3265#page-14
>
> On 01/24/2012 06:36 PM, Saúl Ibarra Corretgé wrote:
> > Hi all,
> >
> > While running some tests I realized that if a NOTIFY receives a 408
> nothing seems to happen and if another PUBLISH comes in OpenSIPS will try
> to send another NOTIFY.
> >
> > Since NOTIFY requests are sent within a dialog, according to RFC3261
> (sec 12.2.1) if a response within a dialog is a 481 or a 408 it SHOULD be
> destroyed.
> >
> > My proposal is to modify the p_tm_callback in notify.c (presence module)
> so that it will also destroy the subscription if a 408 is returned.
> >
> > Doing this is specially insteresting if TCP is being used as a transport
> and the connection is half-closed: we don't want to keep a broken
> subscription around, that will make OpenSIPS attempt to make an outgoing
> TCP connection for every new NOTIFY, that will most likely fail.
> >
> > If no one is against it I'd like to go ahead and make the change.
> Comments are welcome :-)
> >
> >
> > Regards,
> >
> > --
> > Saúl Ibarra Corretgé
> > AG Projects
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20120125/8b9d70da/attachment.htm>


More information about the Devel mailing list