Hello,
I do use dlg_manage after loose_route, but only for the BYE Method, should i use it for all methods? see below the current configuration:
if (loose_route()) { if (is_method("BYE")) { dlg_manage(); setflag(FLAG_ACC); setflag(FLAG_ACCMISSED); $dlg_var(billsec) = $DLG_lifetime; } route(RELAY); exit; };
Regarding dialog match mode, by setting it to 0 or 1 I'm getting a weird issues by duplicating rr_param for SOME calls only!, see below the sip trace:
Working Call: ------------------------------------------------------------------------------------------------------------------ Invite coming from Asterisk PBX:
INVITE sip:+123456789@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.142:5060;branch=z9hG4bK48707bad Max-Forwards: 70 From: sip:+987654321@10.10.10.142;tag=as7dee9847 To: sip:+123456789@192.168.1.1 Contact: sip:+987654321@10.10.10.142:5060 Call-ID: 44bb5a3969sglksg987e548091ca4@10.10.10.142:5060 CSeq: 102 INVITE User-Agent: Asterisk Date: Sun, 26 Jul 2020 10:53:47 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 251
Invite Proxied by Kamailio Server:
INVITE sip:+123456789@192.168.1.156 SIP/2.0 Record-Route: sip:172.16.0.16;ftag=as7dee9847;lr=on;did=4cd.b83 Via: SIP/2.0/UDP 172.16.0.16;branch=z9hG4bK39c2.03cce3e8c8f6fa5800adc2ae8a8d51d4.0 Via: SIP/2.0/UDP 10.10.10.142:5060;branch=z9hG4bK48707bad Max-Forwards: 70 From: sip:+987654321@10.10.10.142;tag=as7dee9847 To: sip:+123456789@192.168.1.156 Contact: sip:+987654321@10.10.10.142:5060 Call-ID: 44bb5a3969sglksg987e548091ca4@10.10.10.142:5060 CSeq: 102 INVITE User-Agent: Company Date: Sun, 26 Jul 2020 10:53:47 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 251 Server: SIP Server
Non Working Call: ------------------------------------------------------------------------------------------------------------------
Invite coming from Asterisk box:
INVITE sip:+123456789@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.142:5060;branch=z9hG4bK6bafe911 Max-Forwards: 70 From: sip:+987654321@10.10.10.142;tag=as16522a1c To: sip:+123456789@192.168.1.1 Contact: sip:+987654321@10.10.10.142:5060 Call-ID: 5a3670c622h45g54ju64j8fee66a@10.10.10.142:5060 CSeq: 102 INVITE User-Agent: Asterisk Date: Sun, 26 Jul 2020 10:53:50 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 251
Invite proxied by Kamailio with dlg_match_mode set to 1:
INVITE sip:+123456789@192.168.1.156 SIP/2.0 Record-Route: sip:172.16.0.16;ftag=as16522a1c;lr=on; *did=427.7a51;did=d8b.1b71* Via: SIP/2.0/UDP 172.16.0.16;branch=z9hG4bKd5a1.964d7662519a933a42759ebc8ef99f9c.0 Via: SIP/2.0/UDP 10.10.10.142:5060;branch=z9hG4bK6bafe911 Max-Forwards: 70 From: sip:+987654321@10.10.10.142;tag=as16522a1c To: sip:+123456789@192.168.1.156 Contact: sip:+987654321@10.10.10.142:5060 Call-ID: 5a3670c622h45g54ju64j8fee66a@10.10.10.142:5060 CSeq: 102 INVITE User-Agent: Company Date: Sun, 26 Jul 2020 10:53:50 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 251 Server: SIP Server
As you can see, in the second case for some reason I'm getting the rr_param doubled with 2 different values (*did=427.7a51;did=d8b.1b71*), I'm not sure, if that's normal, but the upstream provider is complaining about that. And, that's happening only with a few calls, i checked all routes which both calls (working and non-working) are going through - and there is no difference, both of them are using the same configuration routes.
Even more, if I'm setting the dlg_match_mode to 2, then I'm still getting the parameter rr_param enabled in the Record Route header for some calls, I can't find any difference (at the SIP level, either at the configuration level) between those 2 calls, so I have no idea why Kamailio is adding this parameter to the RR header, if it's disabled at the module level.
That's the current module configuration:
modparam("dialog", "enable_stats", 1) modparam("dialog", "rr_param", "did") modparam("dialog", "dlg_match_mode", 2) modparam("dialog", "default_timeout", 10800) modparam("dialog", "early_timeout", 180) modparam("dialog", "noack_timeout", 90) modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "dlg_extra_hdrs", "Hint: Inactivity Timeout\r\n") modparam("dialog", "detect_spirals", 1) modparam("dialog", "db_mode", 1) modparam("dialog", "profiles_with_value", "inboundExtCalls; outboundExtCalls")
Using the latest stable version:
version: kamailio 5.3.5 (x86_64/linux) 9e70e8
Phone Numbers and IP Address has been obfuscated.
Thanks.
În vin., 24 iul. 2020 la 15:30, Ilie Soltanici iliusha.md@gmail.com a scris:
Yes, I do use the Record-Route header and in the SIP Trace on Kamailio Server I can see the ACK/BYE Messages messages going through.
https://static.md/g/33oz9T#&gid=1&pid=1
În vin., 24 iul. 2020 la 11:46, Ilie Soltanici iliusha.md@gmail.com a scris:
Hello,
I'm trying to get CDR working in Kamailio by using the acc and dialog modules. Everything seemed to be working fine - until i noticed that for some of the calls the call duration is 0, even if that call has been successfully established and duration was for about a few minutes. In the Kamailio logs I'm getting such errors:
WARNING: dialog [dlg_handlers.c:1649]: dlg_ontimeout(): timeout for dlg with CallID '304bad142b50bb3a7a117816439ea3d5' and tags 'as3adde5c7' '7d28152f-e0e3-4bcf-9d5c-21c3723b95c5' WARNING: acc [acc_cdr.c:230]: db_write_cdr(): fallback to dlg_only search because of message doesn't exist.
This error I'm getting at about 2 min after the ACK message for 200 OK. I'm not sure that this is related to the dialog timeout, but below you can see the related configuration for the dialog module:
modparam("dialog", "default_timeout", 10800) # 3 hours modparam("dialog", "early_timeout", 180) modparam("dialog", "noack_timeout", 90)
Unfortunately, I'm not able to reproduce this issue, as that's happening randomly and just a few times per day. On the SIP Level i didn't notice any strange issues.
Any ideas why is that happening? Thank you.