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.