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.
Submitted By: Iñaki Baz Castillo (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: [presence] crazy NOTIFY's
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-26 12:58
I found in the log the reason why so many Notifies are sent one after the
other. And it is indeed due to a bug in the phone.
What happens is that the phone sends Publish messages without Sip-If-Match
headers - so each creats a new record. The presence module has a function
that looks for expired records in database and its default running interval
is 100 seconds.
What happend in the log is that when this function run it found 5 expired
publish records in database. The implementation is that the module sends
Notifies with status closed to all the watchers for each expired publosh
record. An enhancement could indeed be done here - to check and send
Notifies only for disting presenties. Anyhow with a proper implementation
in the phone there shouldn't be so many expired records.
Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-25 15:55
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
Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-05-24 01:49
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.