[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