FreeSBC Troubleshooting - Revision history

Luc Morissette: Added "SBC accept entries and fragmentation"

2021-05-17T19:43:42Z

Added "SBC accept entries and fragmentation"

← Older revision		Revision as of 15:43, 17 May 2021
Line 180:		Line 180:
	* Export the call trace. For more details please check the following link [[Toolpack:Retrieving_Call_Trace_C]]		* 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]]		* Generate a tbreport for the date/time you made the test call For more details please check the following link [[TBReport]]
			<br>

			= SBC accept entries and fragmentation =
			When a network has a lot of fragmented packets (data too large to fit in one packet), it may lead to issues with the ProSBC mechanism to prevent DDOS attacks.<br>
			The effect is that some valid packets are dropped because the list of valid entries is full.<br>
			tbrouter log files can show how many '''Accept Entries''' are currently in use. You can search for the following terms in the logs: <br>
			"Accept entries"
			Or if a lot of fragmented packets are received. You can search for the following terms in the logs: <br>
			"nbFragPkt"
			"Frag entries"
			<br>
			You can change this value here in the configuration:
			SBC -> Advanced Parameters -> List sizes -> Maximum accept entries: 8000
			[[Image:SBC_list_size_accept.png\|700px\| ]]

			This setting will only affect memory used, so it can be increased as necessary. It will use approximately 1MB per 1000 entries.<br>
			(reference trk#24706)<br>

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

← Older revision		Revision as of 02:16, 4 January 2021
Line 170:		Line 170:
	* Set trace levels to 1 using by tbx_cli_tools_remote command		* Set trace levels to 1 using by tbx_cli_tools_remote command
	** Connect to ssh and use 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.		** 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]]		** 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]]		* Run tbrouter capture. For more details please check the following link [[VoIP_Ethernet_Capture_FreeSBC_A]]

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

2021-01-04T06:16:10Z

Log procedure for Signaling/Routing problems

← Older revision		Revision as of 02:16, 4 January 2021
Line 155:		Line 155:
	* Set trace levels to 1 using by tbx_cli_tools_remote command		* Set trace levels to 1 using by tbx_cli_tools_remote command
	** Connect to ssh and use 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.		** 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]]		** 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]]		* Run tbsigtrace capture. For more details please check the following link [[Toolpack_Debug_Application:Tbsigtrace]]

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

2021-01-04T03:34:52Z

One Way Audio/ No Audio Problems

← Older revision		Revision as of 23:34, 3 January 2021
Line 120:		Line 120:
	<pre>SBC -> Advanced parameters		<pre>SBC -> Advanced parameters
	</pre>		</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 =		= Call Drops Problems =

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

2021-01-04T03:33:30Z

One Way Audio/ No Audio Problems

← Older revision		Revision as of 23:33, 3 January 2021
Line 120:		Line 120:
	<pre>SBC -> Advanced parameters		<pre>SBC -> Advanced parameters
	</pre>		</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.

	= Call Drops Problems =		= Call Drops Problems =

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

2020-12-28T08:12:08Z

Log procedure for signaling/routing problems

← Older revision		Revision as of 04:12, 28 December 2020
Line 150:		Line 150:
	Please check the following link for how to solve this issue [[Toolpack: How to Get Rid of Sub Optimal]]		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		* Set trace levels to 1 using by tbx_cli_tools_remote command

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

2020-12-28T08:11:51Z

Log procedure for signaling/routing problems

← Older revision		Revision as of 04:11, 28 December 2020
Line 157:		Line 157:
	** Set the trace level to 1 by typing "T"		** Set the trace level to 1 by typing "T"
	** When you finished the test call please disconnect from the application, press Escape twice.		** When you finished the test call please disconnect from the application, press Escape twice.
	** Do this for the gateway, tbsyslog, ~~toolpaack_engine~~ applications.		** Do this for the gateway, tbsyslog, toolpack_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]]		* Run tbsigtrace capture. For more details please check the following link [[Toolpack_Debug_Application:Tbsigtrace]]

Serdar Civici at 08:11, 28 December 2020

2020-12-28T08:11:20Z

← Older revision		Revision as of 04:11, 28 December 2020
Line 150:		Line 150:
	Please check the following link for how to solve this issue [[Toolpack: How to Get Rid of Sub Optimal]]		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		* Set trace levels to 1 using by tbx_cli_tools_remote command
Line 162:		Line 162:
	* Make a test call or simulate the problem		* Make a test call or simulate the problem
	* Stop the tbsigtrace capture		* 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]]

			= Log procedure for Voice/RTP problems =

			* 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
			** Set the trace level to 1 by typing "T"
			** 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.
			** 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]]
			* Make a test call or simulate the problem
			* Stop the tbrouter capture
	* Export the call trace. For more details please check the following link [[Toolpack:Retrieving_Call_Trace_C]]		* 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]]		* Generate a tbreport for the date/time you made the test call For more details please check the following link [[TBReport]]

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

2020-12-28T08:08:53Z

Log procedure for signaling problems

← Older revision		Revision as of 04: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]]

← Older revision		Revision as of 05:00, 25 January 2021
Line 1:		Line 1:
	{{DISPLAYTITLE:~~FreeSBC~~ Troubleshooting Guide}}		{{DISPLAYTITLE:ProSBC Troubleshooting Guide}}

	= Scheduling Problems =		= Scheduling Problems =
	You may see the SBC tab in the general status as yellow. When you select it:<br>		You may see the SBC tab in the general status as yellow. When you select it:<br>
	Status -> SBC		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:		Status containing “scheduling” problem may point to:
	*Non-dedicated (or not ‘pinned’) CPU [Open-stack]		*Non-dedicated (or not ‘pinned’) CPU [Open-stack]
Line 12:		Line 12:
	*On KVM based installations (proxmox,virtmanager) CPU type must set to “host”		*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\| ]]		[[Image:SBC_Status.png\|400px\| ]]
Line 19:		Line 19:
	= Registration Errors =		= 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>		*Check if SIP domain configured correctly <br>
	[[Toolpack:Creating_a_SIP_Domain_SBC_A\|Creating a SIP domain]]		[[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		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		*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]]		[[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 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===		===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.		*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 ===		===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>		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>		'''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.		'''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]]		** 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]]		** 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]]		* 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 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.		** High utilization on a link with no QoS.
Line 115:		Line 115:
	** Underperforming network devices.		** Underperforming network devices.
	** Cabling faults.		** 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>		[[Image:data_path_errors.png\|600px\| ]]<br>
	Please double check your thresholds configuration from;		Please double check your thresholds configuration from;