<div dir="ltr">Maybe in request route i should add something like :<br><br>is_method("BYE"){<div>     xlog("Received $rm from $si with call id $ci ");<br><div>}<br><br>Then take wireshark trace and wait for the hung call and check if kamailio logs has the line that the BYE was received?<br>This would confirm the BYE is getting received but it will no give me any information why ist not relayed.<br><br>Best regards!</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 14 maj 2020 o 22:40 Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Comparing the e2e ACK (relayed successfully) and the BYEs (not relayed<br>
successfully) side by side, there don't seem to be any structural<br>
differences which would prevent the latter from being relayed.<br>
<br>
I can't say for sure without looking at Kamailio logs at higher<br>
verbosity (debug=3 or higher) to ascertain whether the BYE message is<br>
being received, but at first glance, absent nonobvious explanations such<br>
as routing complications, it would seem likely that Kamailio is actually<br>
not receiving the BYE. <br>
<br>
Could this be due to firewall rules, or something like fail2ban,<br>
perhaps? Keep in mind that if a packet is filtered by<br>
netfilter/iptables, it does not prevent it from showing up on the wire,<br>
but that doesn't mean it reaches the listening application.<br>
<br>
Assuming you've ruled that scenario out, can you turn up logging<br>
verbosity in Kamailio and see if it's getting the BYEs, and if so, what<br>
it's doing with them? Or there might be explanations in the logs even<br>
without the added verbosity, such as failure to forward out of the<br>
correct interface--some kind of condition which was not present at the<br>
time the e2e ACK was processed.<br>
<br>
-- Alex<br>
<br>
On Thu, May 14, 2020 at 10:21:35PM +0200, Voip support wrote:<br>
<br>
> Dear Community,<br>
> <br>
> I wrote before about my random issues with calls disconnection.<br>
> We found some issue in our VMWare environment that much packets was lost.<br>
> We resolved the issue by moving to other VMWare host however the issue is<br>
> still present.<br>
> <br>
> Currently it is random and some calls do not disconnect due to no BYE<br>
> forwarded by kamailio to other side.<br>
> <br>
> Here is the pcap of such call :<br>
> <a href="https://www.dropbox.com/s/7bktz3p4im6ztld/bad-dialog-call.zip?dl=1" rel="noreferrer" target="_blank">https://www.dropbox.com/s/7bktz3p4im6ztld/bad-dialog-call.zip?dl=1</a><br>
> <br>
> We use dialog module and dispatcher.<br>
> <br>
> dlg_manage(); is only executed in this block :<br>
> <br>
> # - flags<br>
> #   FLT_ - per transaction (message) flags<br>
> #    FLB_ - per branch flags<br>
> #!define FLT_ACC 1<br>
> #!define FLT_ACCMISSED 2<br>
> #!define FLT_ACCFAILED 3<br>
> #!define FLT_DLG 4<br>
> .<br>
> .<br>
> .<br>
>     # account only INVITEs<br>
>     if (is_method("INVITE")) {<br>
>         setflag(FLT_DLG); # create dialog << i added it<br>
>         setflag(FLT_ACCMISSED); # do accounting even if failed << i added it<br>
>         setflag(FLT_ACC); # do accounting<br>
>         #route(LIMIT_CALLS);<br>
>         dlg_manage();<br>
>         sip_trace();<br>
>     }<br>
> <br>
> I really have no idea i am unable to find differences between the bad and<br>
> good call.<br>
> The SIP packets looking good but the BYE is not processed.<br>
> <br>
> Please help me out how to debug it?<br>
> I was thinking of adding a log for checking if request is BYE and if it is<br>
> check if it match a dialog using is_known_dlg() method.<br>
> <br>
> Please let me know if you see what is wrong.<br>
> Just to mention kamailio is listening on private IP with advertise to<br>
> public IP.<br>
> <br>
> Best regards!<br>
<br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>