FreeSBC Troubleshooting Guide
You may see the SBC tab in the general status as yellow. When you select it:
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”
Status containing “scheduling” problem may point to:
- Non-dedicated (or not ‘pinned’) CPU [Open-stack]
- Not enough CPU reservation [Vmware]
- Memory is not dedicated to the Virtual Machine (VM)
- Too many active virtual machines fighting for resources on the 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. Follow requirements shown here: FreeSBC requirements
Endpoint sends the register request to FreeSBC however the FreeSBC is not forwarding it to the registrar
- Check if SIP domain configured correctly
- Check the SIP domain Status. Be sure domain registrar can be reached by FreeSBC
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 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.
FreeSBC forwards incoming registration messages to the registrar but registrar returns an error
- Check if SIP domain configured with correct registrar setting
- Check if Registrar NAP configured with a correct IP address
- Check if your client configured with correct username and password
- Check the forwarding modes on FreeSBC, and select the correct one
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").
- The "Contact Passthrough" forwarding mode makes contact username portion of the contact URI in SIP register requests to pass through unchanged.
- The "Contact Remapping" forwarding mode modifies contact username portion of the contact URI in SIP register requests and make it unique.
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 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.
This filter is used to forward the domain name (or IP address and port) from the incoming call to outgoing call, for the following SIP headers:
- from (update call attribute :calling by appending :calling_sip_host and calling_sip_port)
- to (update call attribute :called by appending :called_sip_host and called_sip_port)
- P-asserted-identity (update call attribute :private_address by appending :private_address_sip_host and private_address_sip_port)
- To setup a Filter, the main script needs to be modified. The main script can be either simple_routing.rb, or any other script.
First, go to the routing script section of the Web portal
Gateway -> Routing scripts -> Example Scripts -> simple_routing.rb [Edit]
Three things need to be added. At the start of the script:
require 'forward_sip_domain' unless defined?(ForwardSipDomain)
In the main class:
route_remap :method => :forward_sip_domain
The final script will look like this (with possibly other filters also included):
require 'base_routing' require 'forward_sip_domain' unless defined?(ForwardSipDomain) class SimpleRouting < BaseRouting include ForwardSipDomain route_match :call_field_name => :called route_match :call_field_name => :calling route_match :call_field_name => :private_address route_match :call_field_name => :nap route_remap :call_field_name => :called, :route_field_name => :remapped_called route_remap :call_field_name => :calling, :route_field_name => :remapped_calling route_remap :call_field_name => :private_address, :route_field_name => :remapped_private_address route_remap :call_field_name => :nap, :route_field_name => :remapped_nap route_remap :method => :forward_sip_domain end
- This script requires the routes to have a custom column named "forward_sip_domain", type boolean.
Gateway -> Routes -> Create New Route Column
Type attributes: boolean
See FreeSBC uses case: Remote Workers
Note: This script is coming as default after Rls. 3.0.116. You just need to set forward_sip_domain route column as enabled.
One Way Audio/ No Audio Problems
- Can place a call, but one way or no audio
One-way audio is a common VOIP problem. It is one of the most frequent support questions we receive. There are many possible causes;
- Outdated firmware in routers, VOIP phones, Firewalls, etc. can cause one-way audio. Ensure you have the latest updates for all the devices in the call path.
- Firewall mistakenly blocking RTP, be sure firewalls configured correctly.
- Particularly if Network Address Translation (NAT) is involved in the call path, configuration of the various devices may be a problem. Please check the link for NAT
- Another reason for one way audio is having your system set to offering unsupported codecs within your other SIP systems.
- 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 SDP Description
- Configured RTP port ranges can cause a problem too. Check FreeSBC and endpoints (Clients, SIP Trunks) are using correct RTP ports. See 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.
- Misconfigured interface: Half-duplex or duplex mismatch.
- Underperforming network devices.
- Cabling faults.
My call dropped while I was talking, I might hear fast busy or just dead air.
- Calls dropping at specific intervals (10 minutes, 30 minutes).
- Check the SIP session timers. [[SIP_session_timers|SIP Session timers]
- Uncheck “Use Session Timer” from SIP configuration. SIP -> Select the name from SIP Configuration menu -> Session Timers
- Call dropping within the first minute – missing ACK in Invite. Check NAT configuration. NAT
- Maximum Call time exceeded. Many service providers set a limit on the maximum duration for any call passing through their system. Double check with your service provider.