[Kamailio-Users] Help me on 'No matching subscription dialog found'

[Iñaki Baz Castillo]

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 at ABC.com>;tag=802bf23e23f4741
To: DEF <sip:307 at ABC.com>
Call-ID: 9f465e4b-2207f239 at 172.18.100.89
CSeq: 30004 SUBSCRIBE
Max-Forwards: 70
Contact: DEF <sip:307 at 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 at ABC.com>;tag=802bf23e23f4741
To: DEF <sip:307 at ABC.com>;tag=0cca86077d334bd53b00d2c8eab3d5fb.dfeb
Call-ID: 9f465e4b-2207f239 at 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 at 172.18.100.89:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.94.30;branch=z9hG4bK4e33.2f3848c3.0
To: sip:307 at XYZ.com;tag=6341960e5fa2e56f
From: sip:307 at XYZ.com;tag=0cca86077d334bd53b00d2c8eab3d5fb.118f
CSeq: 1 NOTIFY
Call-ID: fd0e6dba-442e11b3 at 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 at aliax.net>