FreeSBC Troubleshooting - Revision history

Serdar Civici at 09:00, 25 January 2021

2021-01-25T09:00:04Z

Serdar Civici: /* Log procedure for Voice/RTP problems */

2021-01-04T06:16:29Z

Log procedure for Voice/RTP problems

Serdar Civici: /* Log procedure for Signaling/Routing problems */

2021-01-04T06:16:10Z

Log procedure for Signaling/Routing problems

William Wong: /* One Way Audio/ No Audio Problems */

2021-01-04T03:34:52Z

One Way Audio/ No Audio Problems

William Wong: /* One Way Audio/ No Audio Problems */

2021-01-04T03:33:30Z

One Way Audio/ No Audio Problems

Serdar Civici: /* Log procedure for signaling/routing problems */

2020-12-28T08:12:08Z

Log procedure for signaling/routing problems

Serdar Civici: /* Log procedure for signaling/routing problems */

2020-12-28T08:11:51Z

Log procedure for signaling/routing problems

Serdar Civici at 08:11, 28 December 2020

2020-12-28T08:11:20Z

Serdar Civici: /* Log procedure for signaling problems */

2020-12-28T08:08:53Z

Log procedure for signaling problems

Serdar Civici at 08:05, 28 December 2020

2020-12-28T08:05:52Z

@@ Line 1: / Line 1: @@
-{{DISPLAYTITLE:FreeSBC Troubleshooting Guide}}
+{{DISPLAYTITLE:ProSBC Troubleshooting Guide}}
 = Scheduling Problems =
 You may see the SBC tab in the general status as yellow. When you select it:<br>
   Status -> SBC
-You may see “Scheduling problem sbc list” with the hostname of the FreeSBC. If you select it, you may see “Scheduling problem alarm” set to “true”<br>
+You may see “Scheduling problem sbc list” with the hostname of the ProSBC. If you select it, you may see “Scheduling problem alarm” set to “true”<br>
 Status containing “scheduling” problem may point to:
 *Non-dedicated (or not ‘pinned’) CPU [Open-stack]
@@ Line 12: / Line 12: @@
 *On KVM based installations (proxmox,virtmanager) CPU type must set to “host”
-You need to be sure other VMs are not taking resources from FreeSBC VM instance.
+You need to be sure other VMs are not taking resources from ProSBC VM instance.
-Follow requirements shown here: [[FreeSBC:Cloud:VmWare_Installation_A#Requirements|FreeSBC requirements]]
+Follow requirements shown here: [[FreeSBC:Cloud:VmWare_Installation_A#Requirements|ProSBC requirements]]
 [[Image:SBC_Status.png|400px| ]]
@@ Line 19: / Line 19: @@
 = Registration Errors =
-== Endpoint sends the register request to FreeSBC however the FreeSBC is not forwarding it to the registrar ==
+== Endpoint sends the register request to ProSBC however the ProSBC is not forwarding it to the registrar ==
 *Check if SIP domain configured correctly <br>
 [[Toolpack:Creating_a_SIP_Domain_SBC_A|Creating a SIP domain]]
-*Check the SIP domain Status. Be sure domain registrar can be reached by FreeSBC
+*Check the SIP domain Status. Be sure domain registrar can be reached by ProSBC
    Go to Status -> SIP -> SIP Domain -> Status -> SIP Registration Domains
-*Check if SIP client sends correct Domain name to FreeSBC. You can capture a SIP trace (see [[Toolpack_Debug_Application:Tbsigtrace|Signaling trace capture tool]] ) and use Wireshark to analyze the trace. Look at the “To:” SIP header: it must match what is in the Sıp Domain configuration of the FreeSBC.
+*Check if the SIP client sends the correct Domain name to ProSBC. You can capture a SIP trace (see [[Toolpack_Debug_Application:Tbsigtrace|Signaling trace capture tool]] ) and use Wireshark to analyze the trace. Look at the “To:” SIP header: it must match what is in the Sıp Domain configuration of the ProSBC.
-== FreeSBC forwards incoming registration messages to the registrar but registrar returns an error ==
+== ProSBC forwards incoming registration messages to the registrar but registrar returns an error ==
 *Check if SIP domain configured with correct registrar setting
@@ Line 33: / Line 33: @@
 [[Toolpack:Allocating_a_SIP_Network_Access_Point_(NAP)_SBC_A|Allocating a SIP NAP]]
 *Check if your client configured with the correct username and password
-*Check the forwarding modes on FreeSBC, and select the correct one
+*Check the forwarding modes on ProSBC, and select the correct one
 ===Forwarding Modes===
-FreeSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars. FreeSBC supports two different SIP registration forwarding modes (i.e. "Contact Remapping" or "Contact Passthrough").
+ProSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars. ProSBC supports two different SIP registration forwarding modes (i.e. "Contact Remapping" or "Contact Passthrough").
 *The "Contact Passthrough" forwarding mode makes the contact username portion of the Contact URI in SIP register requests to pass through unchanged.
@@ Line 42: / Line 42: @@
 ===Forward original headers from incoming request ===
-If your registrar wants to receive original headers from incoming requests, Forward the domain without any modification in From/To/Contact/P-Asserted-Identity SIP headers.  If you want to forward incoming SIP from/to header domain to the outgoing leg you need to upgrade your FreeSBC to the minimum Release 3.0.114.  With Release 3.0.114 we added forward_sip_domain script to our routing scripts.
+If your registrar wants to receive original headers from incoming requests, Forward the domain without any modification in From/To/Contact/P-Asserted-Identity SIP headers.  If you want to forward incoming SIP from/to header domain to the outgoing leg you need to upgrade your ProSBC to the minimum Release 3.0.114.  With Release 3.0.114 we added the forward_sip_domain script to our routing scripts.
 This filter is used to forward the domain name (or IP address and port) from the incoming call to the outgoing call, for the following SIP headers:<br>
@@ Line 91: / Line 91: @@
 '''Name''': forward_sip_domain<br>'''Type attributes''': boolean<br>
-See FreeSBC uses case: [[FreeSBC:Remote_Workers|Remote Workers]]
+See ProSBC uses case: [[FreeSBC:Remote_Workers|Remote Workers]]
 '''Note:''' This script is coming as default after Rls. 3.0.116. You just need to set the forward_sip_domain route column as enabled.
@@ Line 107: / Line 107: @@
 ** Please check the following link for TB supported codecs [[Voice_codecs|Voice codecs]]
 ** Check if the codecs are configured correctly in the SDP [[Toolpack:Profile_SDP_Description|SDP Description]]
-** Capture SIP and RTP traffic to see which codecs are used: [[VoIP_Ethernet_Capture_FreeSBC_A|FreeSBC VoIP Capture]]
+** Capture SIP and RTP traffic to see which codecs are used: [[VoIP_Ethernet_Capture_FreeSBC_A|ProSBC VoIP Capture]]
 * Just as each side of a call must send RTP within the same codec, each side must also have the same phase timing (or ptime value). See [[Toolpack:Profile_SDP_Description|SDP Description]]
-* Configured RTP port ranges can cause a problem too. Check FreeSBC and endpoints (Clients, SIP Trunks) are using correct RTP ports. See [[Toolpack:Creating_an_IP_Port_Range_E|Creating an IP Port Range]]
+* Configured RTP port ranges can cause a problem too. Check ProSBC and endpoints (Clients, SIP Trunks) are using correct RTP ports. See [[Toolpack:Creating_an_IP_Port_Range_E|Creating an IP Port Range]]
 * High one-way packet loss. If sufficient packet loss occurs in one direction on a call, that half of the conversion may break down, but not cause the entire call to drop. Packet loss can occur due to a number of reasons:
 ** High utilization on a link with no QoS.
@@ Line 115: / Line 115: @@
 ** Underperforming network devices.
 ** Cabling faults.
-* Wrong threshold configuration under SBC Advanced parameter can cause FreeSBC to block RTP-Audio by the firewall due to thresholds. You can see the following error in your call trace;
+* Wrong threshold configuration under SBC Advanced parameter can cause ProSBC to block RTP-Audio by the firewall due to thresholds. You can see the following error in your call trace;
 [[Image:data_path_errors.png|600px| ]]<br>
 Please double check your thresholds configuration from;

@@ Line 170: / Line 170: @@
 * Set trace levels to 1 using by tbx_cli_tools_remote command
 ** Connect to ssh and use tbx_cli_tools_remote command
-** Select the application
+** Select the application (application names will be given by Telcobridges Support. Mostly gateway, toolpack_engine, and tbsyslog application logs are needed)
-** Set the trace level to 1 by typing "T"
+** Type "T" and "1" to set the log level
 ** When you finished the test call please disconnect from the application, press Escape twice.
-** Do this for the gateway, tbsyslog, toolpaack_engine, and tbrouter applications.
+** Do this for all the applications given by Telcobridges support.
 ** You can get more detail about how to use tbx_cli_tools_remote from the following link [[How_to_use_tbx_cli_tools_remote_program]]
 * Run tbrouter capture. For more details please check the following link [[VoIP_Ethernet_Capture_FreeSBC_A]]

@@ Line 155: / Line 155: @@
 * Set trace levels to 1 using by tbx_cli_tools_remote command
 ** Connect to ssh and use tbx_cli_tools_remote command
-** Select the application
+** Select the application (application names will be given by Telcobridges Support. Mostly gateway, toolpack_engine, and tbsyslog application logs are needed)
-** Set the trace level to 1 by typing "T"
+** Type "T" and "1" to set the log level
 ** When you finished the test call please disconnect from the application, press Escape twice.
-** Do this for the gateway, tbsyslog, toolpack_engine applications.
+** Do this for all the applications given by Telcobridges support.
 ** You can get more detail about how to use tbx_cli_tools_remote from the following link [[How_to_use_tbx_cli_tools_remote_program]]
 * Run tbsigtrace capture. For more details please check the following link [[Toolpack_Debug_Application:Tbsigtrace]]

@@ Line 120: / Line 120: @@
 <pre>SBC -&gt; Advanced parameters
 </pre>
-* For Two-way no audio, sometimes phone/phone system is behind the firewall, user may find that if they just establish the call, two-way audio is fine, but if the call is placed on hold for certain time, and when resuming the call, there is no more two-way audio. This could be due to the the external firewall is set to shutdown the RTP path after certain time of being idle (silence) as in the case of call on hold. The solution is to optimize this setting at external firewall to prevent it from shutting down the RTP over a reasonable or defined time.
+* For Two-way no audio, sometimes phone/phone system is behind the external firewall, user may find that if they just establish the call, two-way audio is fine, but if the call is placed on hold for certain time, and when resuming the call, there is no more two-way audio. This could be due to the external firewall is set to shutdown the RTP path after certain time of being idle (silence) as in the case of call on hold. The solution is to optimize this setting at external firewall to prevent it from shutting down the RTP over a reasonable or defined time.
 = Call Drops Problems =

@@ Line 120: / Line 120: @@
 <pre>SBC -&gt; Advanced parameters
 </pre>
 = Call Drops Problems =

@@ Line 150: / Line 150: @@
 Please check the following link for how to solve this issue [[Toolpack: How to Get Rid of Sub Optimal]]
-= Log procedure for signaling/routing problems =
+= Log procedure for Signaling/Routing problems =
 * Set trace levels to 1 using by tbx_cli_tools_remote command

@@ Line 150: / Line 150: @@
 Please check the following link for how to solve this issue [[Toolpack: How to Get Rid of Sub Optimal]]
-= Log procedure for signaling problems =
+= Log procedure for signaling/routing problems =
 * Set trace levels to 1 using by tbx_cli_tools_remote command
@@ Line 162: / Line 162: @@
 * Make a test call or simulate the problem
 * Stop the tbsigtrace capture
 * Export the call trace. For more details please check the following link [[Toolpack:Retrieving_Call_Trace_C]]
 * Generate a tbreport for the date/time you made the test call For more details please check the following link [[TBReport]]

← Older revision		Revision as of 08:08, 28 December 2020
Line 159:		Line 159:
	** Do this for the gateway, tbsyslog, toolpaack_engine applications.		** Do this for the gateway, tbsyslog, toolpaack_engine applications.
	** You can get more detail about how to use tbx_cli_tools_remote from the following link [[How_to_use_tbx_cli_tools_remote_program]]		** You can get more detail about how to use tbx_cli_tools_remote from the following link [[How_to_use_tbx_cli_tools_remote_program]]
		+	* Run tbsigtrace capture. For more details please check the following link [[Toolpack_Debug_Application:Tbsigtrace]]
		+	* Make a test call or simulate the problem
		+	* Stop the tbsigtrace capture
		+	* Export the call trace. For more details please check the following link [[Toolpack:Retrieving_Call_Trace_C]]
		+	* Generate a tbreport for the date/time you made the test call For more details please check the following link [[TBReport]]