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

[SourceForge.net]

Bugs item #2791186, was opened at 2009-05-13 16:36
Message generated for change (Settings changed) made by anca_vamanu
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: Anca Vamanu (anca_vamanu)
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: Anca Vamanu (anca_vamanu)
Date: 2009-05-25 15:55

Message:
Hi Inaki,

I can not figure out from the code why such thing will happen. The
multiple Publish should not have anything to do with this. 
Can you please raise the debug level and attach the log file section
starting with the processing of the Subscribe that triggers a series of
Notifies?

regards,
Anca

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

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-25 13: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 01: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 18: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 17: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 17: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 17: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