30 Jul
2020
30 Jul
'20
9:22 a.m.
Hello,
run with debug=3 in kamailio.cfg and send here all the log messages
printed by kamailio when processing the ACK.
Cheers,
Daniel
On 29.07.20 18:48, Ilie Soltanici wrote:
Hello,
I changed the configuration file to call dlg_manage() for all methods:
if (loose_route()) {
dlg_manage();
if (is_method("BYE")) {
setflag(FLAG_ACC);
setflag(FLAG_ACCMISSED);
$dlg_var(billsec) = $DLG_lifetime;
}
route(RELAY);
exit;
};
but, unfortunately this is not helping either. I'm not sure that there
is a buggy UA messing RR because this is happening with 4 Providers
randomly.
What else I noticed is that this is happening mostly with ISP's using
authorization, with other ISPs using IP as whitelisted source I didn't
notice anything like that.
Could this be related somehow?
Thanks.
On Wed, 29 Jul 2020 at 17:19, Sergiu Pojoga <pojogas(a)gmail.com
<mailto:pojogas@gmail.com>> wrote:
Correct me if I'm wrong, but not all within-dialogs are 'calls',
for e.g. NOTIFY with a preset Route after SUBSCRIBE, wondering how
dlg_manage() would treat those, would it count them as 'calls'?
Not to mention that docs mention "dlg_manage() - this makes sense
only for initial requests)
On Wed, Jul 29, 2020 at 10:55 AM M S <shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>> wrote:
Please put dlg_manage immediately after loose_route condition,
e.g.
if (loose_route) {
dlg_manage();
...
}
There is no harm in calling it for every SIP method (not just
BYE or ACK) within dialog. It will help for re-invites (call
hold / unhold events) etc. from same buggy UAs as well.
Thank you.
On Wed, Jul 29, 2020 at 3:21 PM Ilie Soltanici
<iliusha.md(a)gmail.com <mailto:iliusha.md@gmail.com>> wrote:
Hello,
I've tried what you recommended, but without success so far.
This is the configuration block:
if (!has_totag()) return;
if (is_method("ACK")) {
dlg_manage();
}
if (loose_route()) {
if (is_method("BYE")) {
dlg_manage();
setflag(FLAG_ACC);
setflag(FLAG_ACCMISSED);
$dlg_var(billsec) = $DLG_lifetime;
}
route(RELAY);
exit;
};
if (is_method("ACK") ) {
if ( t_check_trans() ) {
route(RELAY);
exit;
} else {
sl_send_reply("606", "Not Acceptable");
exit;
}
}
Here is the sip trace:
https://pastebin.com/Aen2GCjm
And that's the error I'm getting in the Kamailio log file:
WARNING: dialog [dlg_handlers.c:1652]: dlg_ontimeout():
dlg timeout - callid: '
0555141d7d3hsag78sgce830391f9348@10.1.50.240:5060
<http://0555141d7d3hsag78sgce830391f9348@10.1.50.240:5060>'
tags: 'as52c10007' 'Uv7HS0jX65ctF' ostate: 3
Any other ideas?
On Tue, 28 Jul 2020 at 15:44, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
I see the in-dialog ACK in the trace, try with
dlg_manage() explicitly used for it.
The warning messages are not when processing the ack,
but on dialog timeout, if you do not get some other
errors like 90-120 seconds before, when the ack was
routed, then it was no processing error for it.
Cheers,
Daniel
On 28.07.20 12:31, Ilie Soltanici wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
In the Kamailio logs I can see only those errors:
WARNING: dialog [dlg_handlers.c:1652]:
dlg_ontimeout(): dlg timeout - callid:
'45b0130e14a692b95134696d2fc5f2a9' tags: 'as31fb1118'
'12UDcK9S8630r' ostate: 3
WARNING: acc [acc_cdr.c:230]: db_write_cdr():
fallback to dlg_only search because of message
doesn't exist
Here you can see the full sip trace:
https://pastebin.com/Q4eqcGJj
The First Invite it's from the Asterisk server
(192.168.0.140), and the second one - it's from
Kamailio (192.168.1.16), 192.168.2.0/24
<http://192.168.2.0/24> - it's an ISP. What 's
strange for me here is that Kamailio it's still
adding rr_param to the RR Header even if it's
disabled in the module configuration, why would that be?
This is the 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)
I will try to run dlg_manage for ACK within the
dialog and see if it works.
Thank you.
On Tue, 28 Jul 2020 at 09:26, Daniel-Constantin
Mierla <miconda(a)gmail.com <mailto:miconda@gmail.com>>
wrote:
Hello,
that confirms my guessing -- the ack was not
handled in the dialog context, the state 3 is
defined inside dlg_hash.h by:
#define DLG_STATE_CONFIRMED_NA 3 /*!< confirmed
dialog without a ACK yet */
Do you see any error messages in the logs when
handling the ACK in the config? Did you grab the
pcap with sip traffic for such a call?
Try also to explicitly execute dlg_manage() for
ACK within dialog.
Cheers,
Daniel
On 28.07.20 10:05, Ilie Soltanici wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users Hello,
I re-compiled Kamailio from the Master branch
and I'm getting the old state: 3
*dlg_ontimeout(): dlg timeout - callid:
'225ce4fc79d78c0f5477d02d02f3feea' tags:
'as3f0a58cf'
'a9eb002d-c544-47f7-84ec-1c4e690cd0b4' ostate: 3*
[ilie.soltanici@dev ~]$ /usr/local/sbin/kamailio -V
version: kamailio 5.3.5 (x86_64/linux) ff2f8c
Thanks
On Mon, 27 Jul 2020 at 08:56, Daniel-Constantin
Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>> wrote:
Hello,
this sounds like the ACK is not matched for
dialog processing and the early_timeout is
firing. I just pushed a commit to dialog
module to print the old state when the
timeout callback function is executed, maybe
you can test with it -- it is in branch 5.3:
-
https://github.com/kamailio/kamailio/commit/ff2f8c4e63b4fefa7dc5b10835505c3…
Otherwise, maybe call dlg_manage() for ACK,
although the loose_route() callback should
be executed and ACK handled for dialog
processing.
Cheers,
Daniel
On 24.07.20 12:46, Ilie Soltanici wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
<http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
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.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
<http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla