[OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's

SourceForge.net noreply at sourceforge.net
Mon May 25 12:35:36 CEST 2009


Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-25 12:35

Message:
Note that Qutecom has an error in the PUBLISH implementation since it
generates a *new* PUBLISH each time instead of using the SIP-If-Match
header:
  http://trac.qutecom.org/ticket/93

However I'm not sure that this should be the cause (but it could since
Qutecom always sets the same tuple id in the PUBLISH body).

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

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-24 00:49

Message:
I've attached a new file (sequential_crazy_NOTIFY's.txt). It's a SIP
capture of OpenSIPS sending 6 NOTIFY's in less than a second. All of these
NOTIFY's are part of the same subscription dialog, and are sequential
requests (from CSeq: 8 to CSeq:13).
Twinkle replies 200 for each NOTIFY, but other clients, as Qutecom, reply
"500 Retry Later" and the subscription gets lost.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 17:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 16:17

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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



More information about the Devel mailing list