26 Jul
2020
26 Jul
'20
3:31 p.m.
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(a)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(a)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.