[SR-Users] Dialog - timeout for dlg with CallID
Daniel-Constantin Mierla
miconda at gmail.com
Thu Jul 30 08:22:50 CEST 2020
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 at gmail.com
> <mailto:pojogas at 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 at gmail.com
> <mailto:shaheryarkh at 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 at gmail.com <mailto:iliusha.md at 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 at 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 at gmail.com <mailto:miconda at 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:
>> 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 at gmail.com <mailto:miconda at 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:
>>> 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 at 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 at gmail.com
>>> <mailto:miconda at 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/ff2f8c4e63b4fefa7dc5b10835505c3c4ae84388
>>>
>>> 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:
>>>> 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 at lists.kamailio.org <mailto:sr-users at 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
>>>
>> --
>> 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
>>
> --
> 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 at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200730/e1c8d568/attachment.htm>
More information about the sr-users
mailing list