El Miércoles, 17 de Febrero de 2010, Asterisk User escribió:
Oh I see,
Here is my notify packet,
There is something weird here:
SUBSCRIBE sip:ABC.com SIP/2.0 Via: SIP/2.0/UDP 172.18.100.89:5060;branch=z9hG4bK-4082dbb From: DEF sip:307@ABC.com;tag=802bf23e23f4741 To: DEF sip:307@ABC.com Call-ID: 9f465e4b-2207f239@172.18.100.89 CSeq: 30004 SUBSCRIBE Max-Forwards: 70 Contact: DEF sip:307@172.18.100.89:5060 Accept: application/simple-message-summary Expires: 2147483647 Event: message-summary User-Agent: Linksys/PAP2T-3.1.15(LS) Content-Length: 0
SIP/2.0 202 OK Via: SIP/2.0/UDP 172.18.100.89:5060;branch=z9hG4bK-4082dbb;rport=5060;received=220.224.237.54 From: DEF sip:307@ABC.com;tag=802bf23e23f4741 To: DEF sip:307@ABC.com;tag=0cca86077d334bd53b00d2c8eab3d5fb.dfeb Call-ID: 9f465e4b-2207f239@172.18.100.89 CSeq: 30004 SUBSCRIBE Expires: 3600 Contact: sip:192.168.94.30:5060 Server: Kamailio (1.5.0-notls (i386/linux)) Content-Length: 0
(of course this NOTIFY is for other flow but it doesn't matter now):
NOTIFY sip:307@172.18.100.89:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.94.30;branch=z9hG4bK4e33.2f3848c3.0 To: sip:307@XYZ.com;tag=6341960e5fa2e56f From: sip:307@XYZ.com;tag=0cca86077d334bd53b00d2c8eab3d5fb.118f CSeq: 1 NOTIFY Call-ID: fd0e6dba-442e11b3@172.18.100.89 Content-Length: 0 User-Agent: Kamailio (1.5.0-notls (i386/linux)) Max-Forwards: 70 Event: message-summary Contact: sip:192.168.94.30:5060 Subscription-State: active;expires=3670
As you see the client is proposing a Expires value of 2147483647 but the server decreases it to 3600 in the 200 Ok. But in the instant NOTIFY the server sets Expires: 3670 (greater than 3600!!!).
This causes that the client to send the re-SUBSCRIBE after ~3670 seconds but I suspect that the server terminates the subscription dialog after the original value of 3600.
Some months ago I reported a similar bug for OpenSIPs. It was a bug in the code generating the Expires value so some NOTIFY's contain a weird value. AFAIK this bug has not been fixed in Kamailio.
Anyhow, when does you client send the first re-SUBSCRIBE? how long after the initial SUBSCRIBE?
To make tests I suggest to decrease the max-expires value of the presence module to something as 60-120 seconds, then capture an *entire* SIP trace for the subscription dialog (SUBSICRIBE/200/NOTIFY/200/re-SUBSCRIBE...) until you get the 481 response, and paste it here.