[SR-Users] Dialog - timeout for dlg with CallID

Ilie Soltanici iliusha.md at gmail.com
Wed Jul 29 18:48:27 CEST 2020


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> 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> 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>
>> 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' tags:
>>> 'as52c10007' 'Uv7HS0jX65ctF' ostate: 3
>>>
>>> Any other ideas?
>>>
>>> On Tue, 28 Jul 2020 at 15:44, Daniel-Constantin Mierla <
>>> 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 - 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> 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> 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 Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>> --
>>>>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>>> Funding: https://www.paypal.me/dcmierla
>>>>>>
>>>>>> --
>>>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>> Funding: https://www.paypal.me/dcmierla
>>>>>
>>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>> Funding: https://www.paypal.me/dcmierla
>>>>
>>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> 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
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200729/9ae65c3a/attachment.htm>


More information about the sr-users mailing list