[OpenSIPS-Devel] [ opensips-Bugs-2791077 ] presence: wrong NOTIFY with "reason=timeout"

SourceForge.net noreply at sourceforge.net
Wed May 13 11:23:11 CEST 2009


Bugs item #2791077, was opened at 2009-05-13 11:23
Message generated for change (Tracker Item Submitted) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791077&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: wrong NOTIFY with "reason=timeout"

Initial Comment:
OpenSIPS trunk rev 5694.

I'm experimienting some issues in NOTIFY's from presence server module. "Sometimes" (but really often) when a refresh PUBLISH arrives (matching "SIP-If-Match") presence module generates a NOTIFY with:
  Subscription-State: terminated;reason=timeout

This forces the client to terminate the current subscription dialogs and resend a new initial SUBSCRIBE. Unfortunatelly some clients (as Qutecom) seem to react wrongly when this issue. Anyhow, I think there is some bug in the presence module behaviour.

I attach a SIP trave very simple:

- Just one user 30000 at domain.org.
- It publishes its state and subscribes to its state.

Note how the NOTIFY in line 428 has a strange header value:
  Subscription-State: terminated;reason=timeout
After it, Twinkle (which recats well on it) generates a new out-of-dialog SUBSCRIBE. But if Qutecom is being used, it doesn't generate the SUBSCRIBE (probably a bug inQutecom) and the subscription dissapear from "active_watchers" table.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791077&group_id=232389



More information about the Devel mailing list