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

Ilie Soltanici iliusha.md at gmail.com
Sun Jul 26 14:31:10 CEST 2020


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 at 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 at 10.10.10.142>;tag=as7dee9847
To: <sip:+123456789 at 192.168.1.1>
Contact: <sip:+987654321 at 10.10.10.142:5060>
Call-ID:  44bb5a3969sglksg987e548091ca4 at 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 at 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 at 10.10.10.142>;tag=as7dee9847
To: <sip:+123456789 at 192.168.1.156>
Contact: <sip:+987654321 at 10.10.10.142:5060>
Call-ID: 44bb5a3969sglksg987e548091ca4 at 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 at 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 at 10.10.10.142>;tag=as16522a1c
To: <sip:+123456789 at 192.168.1.1>
Contact: <sip:+987654321 at 10.10.10.142:5060>
Call-ID:  5a3670c622h45g54ju64j8fee66a at 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 at 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 at 10.10.10.142>;tag=as16522a1c
To: <sip:+123456789 at 192.168.1.156>
Contact: <sip:+987654321 at 10.10.10.142:5060>
Call-ID: 5a3670c622h45g54ju64j8fee66a at 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 at 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 at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200726/2c0ebdf3/attachment.htm>


More information about the sr-users mailing list