<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 23, 2022 at 2:20 AM Sean Devoy via FreeSWITCH-users <<a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><br>---------- Forwarded message ----------<br>From: Sean Devoy <<a href="mailto:sdevoy@bizfocused.com" target="_blank">sdevoy@bizfocused.com</a>><br>To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>Cc: <br>Bcc: <br>Date: Tue, 22 Feb 2022 16:56:15 +0000<br>Subject: PCAP help and many call failures PLEASE HELP<br>Hi,<br>
This is a very serious problem for my users AT this site. PLEASE help. <br>
<br>
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.<br>
I have tried TCP instead of UDP.<br>
<br>
Details of the problem:<br>
User extension initiates a call (INVITE after auth required). <br>
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.<br>
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.<br>
I see a very single strange RTP from FS to itself: unknown RTP protocol version 3.<br>
The call CANCEL is initiated from FreeSwitch at 22.75 seconds after the invite to FS.<br>
<br>
PCAP issue:<br>
I am trying to trace down a problem with tshark.  <br>
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?<br>
<br>
The full explanation is: <br>
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.<br>
<br>
I also see an ICMP from the FSserver to the extension's external IP aftern the CANCEL. We block ICMP.  Is that a problem?<br>
<br>
I have the full pcap file if someone could PLEASE help<br>
Pcacp file: <a href="http://brianbunce.com/capturefile.pcap" rel="noreferrer" target="_blank">http://brianbunce.com/capturefile.pcap</a>  (11 MB) It is a customer site, be kind.<br>
The invite from the ext is packet# 2334.  The invite to the GW is packet# 2357. That will show you all IPs involved.<br><br></blockquote><div><br></div><div>I am not a security expert and I am not sure if it is wise to share capture files with unredacted information.</div><div><br></div><div>Anyway, I took a look and I think what matters is to understand why FS decided to cancel the call. </div><div>If you have the XML CDRs of the channels involved, they might give some clue about it.<br></div><div>If you don't have them, please show the complete dialplan you are executing as there might be something there like call_timeout etc.</div><div>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:</div><div><br></div><div>fs_cli -x "fsctl loglevel DEBUG"<br>+OK log level: DEBUG [7]<br><br>Then make a call that recreates the problem and switch back to the original log level (usually, ERR):</div><div><br>fs_cli -x "fsctl loglevel ERR"<br>+OK log level: ERR [3]<br></div><div><br></div><div>Then with the logs, you should be able to understand why FS is deciding to cancel the call.</div><div><br></div></div></div>