[SR-Users] Facing issue with call disconnection BYE packets are not accepted by kamailio

[Voip support]

Maybe in request route i should add something like :

is_method("BYE"){
     xlog("Received $rm from $si with call id $ci ");
}

Then take wireshark trace and wait for the hung call and check if kamailio
logs has the line that the BYE was received?
This would confirm the BYE is getting received but it will no give me any
information why ist not relayed.

Best regards!

czw., 14 maj 2020 o 22:40 Alex Balashov <abalashov at evaristesys.com>
napisał(a):

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