[Freeswitch-users] PCAP help and many call failures PLEASE HELP

[mayamatakeshi]

On Wed, Feb 23, 2022 at 2:20 AM Sean Devoy via FreeSWITCH-users <
freeswitch-users at lists.freeswitch.org> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Sean Devoy <sdevoy at bizfocused.com>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> Cc:
> Bcc:
> Date: Tue, 22 Feb 2022 16:56:15 +0000
> Subject: PCAP help and many call failures PLEASE HELP
> Hi,
> This is a very serious problem for my users AT this site. PLEASE help.
>
> I suspect it is a NAT issue reaching the extension. I have tried <variable
> name="sip-force-contact" value="NDLB-connectile-dysfunction"/> with no
> change.
> I have tried TCP instead of UDP.
>
> Details of the problem:
> User extension initiates a call (INVITE after auth required).
> User hears ringing for approximately 20 seconds, then a busy signal. Today
> a user called her own cell phone and said it WAS ringing when the call
> failed.
> I see some RTP packets between 183 session progress from FS to extension
> and CANCEL, but can't tell what extension hey are to/from.
> I see a very single strange RTP from FS to itself: unknown RTP protocol
> version 3.
> The call CANCEL is initiated from FreeSwitch at 22.75 seconds after the
> invite to FS.
>
> PCAP issue:
> I am trying to trace down a problem with tshark.
> The short version of my question is how do I tell which NAT extension RTP
> packets are going to and why did FS cancel the call?
>
> The full explanation is:
> I have identified the failed call based on the INVITE from the NAT
> extension's IP and PORT number.  I am able to follow the SIP packets is
> OK.  I see RTP packets to and from that IP address, but I cannot determine
> what extension it is going to.
>
> I also see an ICMP from the FSserver to the extension's external IP aftern
> the CANCEL. We block ICMP.  Is that a problem?
>
> I have the full pcap file if someone could PLEASE help
> Pcacp file: http://brianbunce.com/capturefile.pcap  (11 MB) It is a
> customer site, be kind.
> The invite from the ext is packet# 2334.  The invite to the GW is packet#
> 2357. That will show you all IPs involved.
>
>
I am not a security expert and I am not sure if it is wise to share capture
files with unredacted information.

Anyway, I took a look and I think what matters is to understand why FS
decided to cancel the call.
If you have the XML CDRs of the channels involved, they might give some
clue about it.
If you don't have them, please show the complete dialplan you are executing
as there might be something there like call_timeout etc.
Then even if with those things the cause of CANCEL cannot be found, one
alternative if you are able to reproduce this problem at will or if the
problem happens frequently enough would be to try to enable debug logging
during low traffic period by doing:

fs_cli -x "fsctl loglevel DEBUG"
+OK log level: DEBUG [7]

Then make a call that recreates the problem and switch back to the original
log level (usually, ERR):

fs_cli -x "fsctl loglevel ERR"
+OK log level: ERR [3]

Then with the logs, you should be able to understand why FS is deciding to
cancel the call.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20220223/68e52c4b/attachment-0001.html>