Thanks Iñaki,
I 'll give it a try and come back to the group.
--SM
On Wed, Feb 17, 2010 at 5:17 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
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(a)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(a)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(a)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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users