VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
freeswitch-users at li... Guest
|
Posted: Tue Feb 22, 2022 12:09 pm Post subject: [Freeswitch-users] PCAP help and many call failures PLEASE H |
|
|
------ Start of attached email. 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.
Thanks for any help,
Sean
------ End of attached email ------
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
Back to top |
|
|
mayamatakeshi at gmail... Guest
|
Posted: Tue Feb 22, 2022 5:58 pm Post subject: [Freeswitch-users] PCAP help and many call failures PLEASE H |
|
|
On Wed, Feb 23, 2022 at 2:20 AM Sean Devoy via FreeSWITCH-users <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> wrote:
Quote: |
---------- Forwarded message ----------
From: Sean Devoy <sdevoy@bizfocused.com (sdevoy@bizfocused.com)>
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@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. |
|
Back to top |
|
|
freeswitch-users at li... Guest
|
|
Back to top |
|
|
mayamatakeshi at gmail... Guest
|
Posted: Wed Feb 23, 2022 5:50 pm Post subject: [Freeswitch-users] PCAP help and many call failures PLEASE H |
|
|
On Thu, Feb 24, 2022 at 12:27 AM Sean Devoy <sdevoy@bizfocused.com (sdevoy@bizfocused.com)> wrote:
Quote: |
I have debug level FS logs. There are so many lines it is difficult to follow a single call.
|
Do you have the logs related to the capture file?
If yes, then search for the Call-IDs of the troubled call:
Leg1:
Call-ID: f0544e98-378154a6@192.168.2.111 (f0544e98-378154a6@192.168.2.111)
Leg2:
Call-ID: 26e3398f-0e97-123b-3b83-16f3d912a996
For example, I did a test call with
Call-ID: 090abe39-188c-4f06-b371-e8ffe3d862f8
So I grepped the freeswitch.log file with:
[root@lab002 ~]$ grep 090abe39-188c-4f06-b371-e8ffe3d862f8 /usr/local/freeswitch/log/freeswitch.log
4b860aaf-b481-4e26-8886-37321c2fc3f3 2022-02-24 06:49:17.131915 [INFO] sofia.c:10414 sofia/external_in/123412341234@test.com (123412341234@test.com) receiving invite from 127.0.0.1:5060 version: 1.10.7-dev git dd24113 2021-08-25 17:37:19Z 64bit call-id: 090abe39-188c-4f06-b371-e8ffe3d862f8
The 4b860aaf-b481-4e26-8886-37321c2fc3f3 above is the channel uuid (the unique identifier of the channel in freeswitch).
The freeswitch log file will include that channel uuid in all log lines related to that channel.
So you can grep your freeswitch.log file for it.
If no clue about the problem is found, do the same for the other leg.
Quote: |
This happens are about 50% of ALL calls.
Here is the dial plan:
<extension name="ten_or eleven_digiti_dial" >
<condition field="destination_number" expression="^(?:1|\+1)?([2-9]\d\d[2-9]\d{6})$">
<action application="set" data="ringback=${us-ring}"/>
<action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
<action application="set" data="ani=${outbound_caller_id_number}"/>
<action application="set" data="origination_caller_id_number=${outbound_caller_id_number}"/>
<action application="set" data="effective_caller_id_name=REDACTED"/>
<action application="set" data=sip_from_uri=${outbound_caller_id_number}@ ([email]sip_from_uri=$%7boutbound_caller_id_number%7d@64.136.173.30[/email])REDACTED/>
<action application="set" data="sip_from_user=${outbound_caller_id_number}"/>
<action application="set" data="sip_from_host=REDACTED"/>
<action application="set" data="sip_h_X-CID=${sip_call_id}"/>
<action application="set" data="continue_on_fail=true"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="sip_h_X-CID=${sip_call_id}"/>
<action application="bridge_export" data="hold_music=/etc/freeswitch/recordings/REDACTED-moh.wav"/>
<action application="bridge" data={sip_from_uri=${outbound_caller_id_number}@REDACTED,sip_from_user=${outbound_caller_id_number},sip_from_host=REDACTED}sofia/gateway/voip-innovations-outbound/1$1 ([email]%7bsip_from_uri=$%7boutbound_caller_id_number%7d@64.136.173.30,sip_from_user=$%7boutbound_caller_id_number%7d,sip_from_host=64.136.173.30%7dsofia/gateway/voip-innovations-outbound/1$1[/email])/>
</condition>
</extension>
|
OK. So there is nothing setting an answer timeout (so it would default to 60 seconds).
The variable controlling it would be this one:
https://freeswitch.org/confluence/display/FREESWITCH/call_timeout
|
|
Back to top |
|
|
david.villasmil.work a... Guest
|
Posted: Wed Feb 23, 2022 7:51 pm Post subject: [Freeswitch-users] PCAP help and many call failures PLEASE H |
|
|
try adding
<action application="set" data="ignore_early_media=true"/>
right before the bridge.
Regards,
David Villasmilemail: david.villasmil.work@gmail.com (david.villasmil.work@gmail.com)
phone: +34669448337
On Wed, Feb 23, 2022 at 10:46 PM mayamatakeshi <mayamatakeshi@gmail.com (mayamatakeshi@gmail.com)> wrote:
Quote: |
On Thu, Feb 24, 2022 at 12:27 AM Sean Devoy <sdevoy@bizfocused.com (sdevoy@bizfocused.com)> wrote:
Quote: |
I have debug level FS logs. There are so many lines it is difficult to follow a single call.
|
Do you have the logs related to the capture file?
If yes, then search for the Call-IDs of the troubled call:
Leg1:
Call-ID: f0544e98-378154a6@192.168.2.111 (f0544e98-378154a6@192.168.2.111)
Leg2:
Call-ID: 26e3398f-0e97-123b-3b83-16f3d912a996
For example, I did a test call with
Call-ID: 090abe39-188c-4f06-b371-e8ffe3d862f8
So I grepped the freeswitch.log file with:
[root@lab002 ~]$ grep 090abe39-188c-4f06-b371-e8ffe3d862f8 /usr/local/freeswitch/log/freeswitch.log
4b860aaf-b481-4e26-8886-37321c2fc3f3 2022-02-24 06:49:17.131915 [INFO] sofia.c:10414 sofia/external_in/123412341234@test.com (123412341234@test.com) receiving invite from 127.0.0.1:5060 version: 1.10.7-dev git dd24113 2021-08-25 17:37:19Z 64bit call-id: 090abe39-188c-4f06-b371-e8ffe3d862f8
The 4b860aaf-b481-4e26-8886-37321c2fc3f3 above is the channel uuid (the unique identifier of the channel in freeswitch).
The freeswitch log file will include that channel uuid in all log lines related to that channel.
So you can grep your freeswitch.log file for it.
If no clue about the problem is found, do the same for the other leg.
Quote: |
This happens are about 50% of ALL calls.
Here is the dial plan:
<extension name="ten_or eleven_digiti_dial" >
<condition field="destination_number" expression="^(?:1|\+1)?([2-9]\d\d[2-9]\d{6})$">
<action application="set" data="ringback=${us-ring}"/>
<action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
<action application="set" data="ani=${outbound_caller_id_number}"/>
<action application="set" data="origination_caller_id_number=${outbound_caller_id_number}"/>
<action application="set" data="effective_caller_id_name=REDACTED"/>
<action application="set" data=sip_from_uri=${outbound_caller_id_number}@ ([email]sip_from_uri=$%7boutbound_caller_id_number%7d@64.136.173.30[/email])REDACTED/>
<action application="set" data="sip_from_user=${outbound_caller_id_number}"/>
<action application="set" data="sip_from_host=REDACTED"/>
<action application="set" data="sip_h_X-CID=${sip_call_id}"/>
<action application="set" data="continue_on_fail=true"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="sip_h_X-CID=${sip_call_id}"/>
<action application="bridge_export" data="hold_music=/etc/freeswitch/recordings/REDACTED-moh.wav"/>
<action application="bridge" data={sip_from_uri=${outbound_caller_id_number}@REDACTED,sip_from_user=${outbound_caller_id_number},sip_from_host=REDACTED}sofia/gateway/voip-innovations-outbound/1$1 ([email]%7bsip_from_uri=$%7boutbound_caller_id_number%7d@64.136.173.30,sip_from_user=$%7boutbound_caller_id_number%7d,sip_from_host=64.136.173.30%7dsofia/gateway/voip-innovations-outbound/1$1[/email])/>
</condition>
</extension>
|
OK. So there is nothing setting an answer timeout (so it would default to 60 seconds).
The variable controlling it would be this one:
https://freeswitch.org/confluence/display/FREESWITCH/call_timeout
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com (sales@freeswitch.com)
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|