If your SIP registration failed, please check the following:

1. Double confirm that your internet is working well. To check the internet you can:
   • Launch web browsers like Chrome and address to google.com or bing.com.
   • Ping google.com or ping sip1.b3networks.com (or the SIP domain we provide).
2. Login to your account > click the SIP app > check to confirm if you are using the correct SIP credentials. You have to check the following information and make sure your configuration must be matched:
   1. SIP username
   2. SIP Password
   3. SIP Server
      
3. Double-check your NAT and firewall settings and ensure that they follow the settings on the SIP subscription page. If you make any settings changes at this step, remember to restart the device to ensure that the new settings are deployed. 
4. Ensure you remove all expired SIP trunks, In the case you try to register expired SIP trunks, we treat that as a hacking case then block all traffic that comes from your device via public IP.

When you can make outgoing and incoming calls but the voice call quality is bad, then you experience poor voice quality issues.

Below are the causes of VoIP call quality problems and what you can do to correct them.

It is a common problem of connection networks or packet-switched networks. Because the information (voice packets) is divided into packets, each packet can travel by a different path from the sender to the receiver. When packets arrive at their intended destination in a different order than they were originally sent, the result is a call with poor or scrambled audio.

Solution: Use Jitter Buffers for PBX or IP Phone. (You can refer to this topic for Enable Jitter Buffer for Asterisk below)

Notes: 

• A jitter buffer temporarily stores arriving packets in order to minimize delay variations. If packets arrive too late then they are discarded. If a packet was dropped (or simply does not arrive in time) then the receiving device has somehow to “fill in” the gap using a process known as Packet Loss Concealment or PLC. 
• Packet loss needs to be less than 1% if it is not to have too great an impact on call audio quality. Greater than 3% would certainly be noticeable as degradation of quality (The default G.729 codec requires packet loss far less than 1 percent to avoid audible errors. Ideally, there should be no packet loss for VoIP)

II. Latency 

In general, it is the length of time taken for the quantity of interest to reach its destination. Latency sounds like an echo.

ITU-T G.114 recommends a maximum of 150 ms one-way latency. Since this includes the entire voice path, part of which may be on the public Internet, your own network should have transit latencies of considerably less than 150 ms.

There are 3 types of delay commonly found in today’s VoIP networks: Propagation Delay, Handling Delay, Queuing Delay.

Solution: A quality VoIP router can solve many of these issues and will result in business quality Business VoIP Phone Service.

How to determine the Packet loss and network latency?
Please run the MTR, which is a powerful network tool enabling administrators to diagnose and isolate networking errors and providing helpful reports of network status to upstream providers. 

It run the best on Linux/GNU Platform, This below is example follow syntax: mtr [option] [destination_host]

MRT-rw-c50 sip1.b3networks.com (or the SIP domain in your SIP subscription page)

The destination host should be the sip domain that your sip account base on.

If your PBX's running on Windows, can run MTR for Windows, download here. To understand more about MRT please refer to Linode.

Once you get the result, kindly send it to us.

III. Bandwidth Problem

You will have to ensure that you have sufficient bandwidth for good-quality SIP calls. Refer to the bandwidth required per SIP callsfor more details. If your router provides network statistics, you can easily investigate if your internet capacity is utilized at or near the maximum provided by your Internet Service Provider.

The bandwidth required varies with the codec used. You may check your PBX configuration or hardware provider on which codec you are using for connecting to our SIP server. The values below are estimated per concurrent voice call:

• G.729: 24Kbps upstream; 24 Kbps downstream
• GSM: 29 Kbps upstream; 29 Kbps downstream
• G.711: 80 Kbps upstream; 80 Kbps downstream

The values above are for 1 concurrent voice call. Multiply the values above for each concurrent call you are expecting to estimate your bandwidth required. For example, G.711 codec for 10 concurrent calls, bandwidth required = (80 x 10) = 800 Kbps upstream and downstream.

If bandwidth is insufficient, voice quality will degrade. If you are expecting poor voice quality, please check through the following possible reasons:

Are you sharing the internet?

This is the most common reason for poor voice quality with SIP. If the internet used by the PBX or IP phones is shared with other computers or machines, the quality drops significantly when these machines are active. Even though you may have a very high internet connection speed, a single machine downloading or uploading data on the internet could use up all the bandwidth. This is because most routers distribute bandwidth in a free-for-all manner.

To detect whether your network is experiencing this problem, try turning off all other machines while you make test calls to see if there're improvements to the voice quality.

The best way to resolve this problem is to set QoS on your router. Allocate and reserve bandwidth to your PBX or IP-Phones. Please refer to your router manual about setting QoS. Alternatively, you might need to purchase dedicated internet access for your PBX or IP-Phones, separate from your usual computer networks.

Is your internet connection asymmetric?

You will need equally high bandwidth upstream and downstream for good SIP connections. Your internet connection with your internet provider could be asymmetric. Meaning, your internet connection could be rated, for example, 2 Mbps, but you could be getting 2 Mbps downstream and only 128 kbps upstream. Asymmetric internet connection is common in ADSL connections. Please check with your internet provider.

Are you located outside Singapore?

Our SIP servers are located in Singapore. Most internet providers offer an overseas connection speed much lower than your rated internet connection speed. For example, a 2 Mbps connection may only connect with 200 Kbps outside your country. Please check with your internet provider. You may also perform a speed test on a Singapore server from www.speedtest.net.

Is your internet speed just enough?

Actual internet connection speed is usually lower than the rated connection speed offered by the internet providers. You should estimate your actual connect speed about 10% lower than the rated speed. 

Solution: Upgrade to Business Class High Speed

IV. Hardware Issue

This is one of the most common causes of call quality issues.

• Router: Many small businesses use their internet connection for both voice and data. This is perfectly fine as long as your router has the ability to prioritize VoIP traffic. Without a router that is configured for packet prioritization, call quality can be impacted by the other users on your network. For example, if during a call, another user on your network downloads a large file, without packet prioritization, your call quality could be degraded. A VoIP router prevents this from happening by giving priority to voice traffic on your network.
• SIP Device (PBX or IP Phone): Sometimes the SIP hardware goes to crash or performance overload. In order to confirm the issue on hardware, just reboot or use the soft-phone to see how voice quality goes.

If you can make both outgoing and incoming calls but experience intermittent one-way audio, it is likely to be a bandwidth problem. To troubleshoot, check on the following:

• The bandwidth required per SIP calls for more details. If your router provides network statistics, you can easily investigate if your internet capacity is utilized at or near the maximum provided by your Internet Service Provider (ISP)
• If you can hear the other party clearly and the other party cannot hear you, it is most likely that your internet upload bandwidth is not sufficient. Double-check with your ISP on your upload bandwidth as it may be much smaller than the download bandwidth speed. 

If you have double-checked the bandwidth but still cannot resolve the issue, proceed to check the following. 

• Connected Devices in the SIP subscription page to double confirm that only ONE device is connected. A SIP account can ONLY be used with one device. If more than one device is connected, you may experience no audio or one-way audio. 

If you experience consistent one-way audio for each and every call, it is most likely to be a firewall issue. To troubleshoot, please check firewall settings and ensure that they follow the settings on the SIP subscription page.

Ensure that your firewall settings are enabled for both incoming and outgoing. If you make any settings changes at this step, please remember to restart the firewall to ensure that the new settings are deployed. Please note RTP may not come from the same IPs as the SIP signaling on our side. We do not recommend blocking RTP traffic in any way. We use UDP ports 10,000 to 30,000 for RTP. (See the Firewall setting in SIP App or the screenshot below for more details).

If your SIP device is behind the NAT: 

• Check NAT setting configured properly on SIP devices and Routers. The settings can be found within the SIP App configuration page. If you make any settings changes at this step, please remember to restart the IP-Phone and IP-PBX to ensure that the new settings are deployed. 
• Confirm that SIP ALG is disabled. Many of today's lower-end commercial routers implement SIP ALG coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers' ALG implementations are wrong and break SIP. We will not support SIP ALG. 
•  Please consider setting for TURN & STUN server
• Confirm that you are using one of the supported codecs: G.711 (alaw, ulaw), G.729, GSM. Consider testing with each other codecs (with ptime = 20ms) 
• Confirm your Network is in good condition (Sufficient Bandwidth, Latency, Packet Loss ...)

If you cannot make calls, check the following:

• If your account is a prepaid account, please confirm that you have a positive balance in your account. 
• Confirm that you have sent the invite to the correct IP address of a SIP server. 
• Confirm that you are specifying the called number in E.164 format including the country code. For example, +6566021000 for calls to Singapore regardless of where you are originating the call.
• The called number is in service
• Did you configure any security settings? 
• IP White-list 
• Country White-list 
• Make sure your Firewall doesn't block traffic from us
• Your Network in is good conditional
• Confirm that you are using one of the supported codecs: G.711 (a-law, u-law), G.729, GSM

If you cannot receive incoming calls, check the following: 

1. Double confirm your device register to the SIP trunk successfully
   1. Successful register message show on your device or
   2. Login to your account, check Connected Devices to double confirm that the correct device is connected.
      
   3. A SIP account can ONLY be used with one device. If more than one device is connected, you will NOT be able to receive incoming calls at the correct device. The call will be shuffling. 
2. Check to confirm that you are using one of the supported codecs: G.711, G.729, GSM
3. Check your Firewall Settings 
   • Almost all cases in which lines are unable to receive incoming calls are due to network latency fluctuations. UDP transport cannot handle very well in this case. If your SIP devices are still using UDP transport. Please switch to TCP transport.
   • If you have completed the above and it still does not work, please collect the MTR Report and Network Capture (or SIP log) of a failed incoming call. Send both of them to our support team for further assistance.

MTR is a powerful network tool that enables administrators to diagnose and isolate networking errors and provide helpful reports of network status to upstream providers. In many cases, when troubleshooting, we usually require the report of MTR and Network Traffic Capture. They're very helpful to find out the root cause of the issue.

All reports must be collected while the troubles are occurring. If not, the result is meaningless.

-----

COLLECT MTR REPORT

1. Using MTR on Unix-based Systems (Linux/GNU) 

Syntax of command:

mtr [-hvrwctglspniu46] hostname [packetsize]

For example, to test the route and connection quality of traffic to the destination sip1.b3networks.com (or the SIP domain in your SIP subscription page), with useful flag -rw -c50, input following command 

root@ip-10-7-1-231 ec2-user]# mtr -rw -c50 sip1.b3networks.com (or the SIP domain in your SIP subscription page)

2. Using MTR on Windows Systems

For Windows, we use the WinMTR. 

3. Using MTR on MAC OS X

To gather the MTR report on MAC OS X, you need to install MTR package at Rudix. Then run the following command in Terminal:

sudo /usr/local/sbin/mtr -rw -c50 sip1.b3networks.com (or the SIP domain in your SIP subscription page)

NOTES:

• The destination host should be the SIP domain your SIP account is based on.
• To understand more about MTR, please refer to Linode.

----

COLLECT NETWORK TRAFFIC CAPTURE

To capture the network traffic, we using Wireshark/TShark tools. This is a free and open-source packet analyzer. It is used for network troubleshooting, analysis.

1. Using TShark on Linux/GNU Systems 

Syntax of command, input tshark -h for Usage instruction

• tshark [options]

For example, capture the network traffic on NIC0 and save the capture file with the name "capture-output.pcap" enter the following command:

• tshark -i eth0 -w capture-output.pcap

Press Ctrl + C to stop capture network traffic.

2. Using Wireshark on Windows (download). Note that select the correct interface to capture network traffic.

The caller ID is a piece of information that will be passed from telco to telco when a call is placed. Each telco can have a different caller ID format and, as calls may go through several networks before reaching us, the information may be altered along the way.

There are three situations that can cause failure to show intended caller ID:

• The originating telco may not send the correct format or the original From number.
• A caller ID may be modified along the way by any intermediary telcos
• The caller ID may be lost or replaced when crossing international borders

When we receive an incoming call, we perform basic normalization to E.164 formatting. Otherwise, we will pass along the information exactly as we receive to your application. It is currently not possible to discover the origin caller ID once it has been altered by telcos.

Example: Singapore Resident using Singtel mobile to call our Hong Kong Number.

• You will not receive Singapore mobile CLI as the CLI will be replaced by other CLI (ie a random local number) according to Hong Kong CLI regulatory. The CLI will be replaced by the 1st HK terminated operator. 
• A Singapore Number dials to a HK number > (1st) HK operator replaces Singapore CLI according to HK CLI regulatory > CLI by regulatory > Customer side.
• NOTE: According to HK CLI regulatory, CLI for HK is mobile only. There is no CLI allowed on the HK Landline.

To solve broken audio issues, you can enable Jitter Buffer for Asterisk. Details below.
Change this in the sip_general_custom.conf 

;Enable a Jitter Buffer for Asterisk:

• jbenable=yes
• jbforce=yes
• jbimpl=adaptive
• jbmaxsize=200
• jbresyncthreshold=1000
• jblog=yes

jbenable = yes|no

SIP channel. Defaults to "no". An enabled jitterbuffer will be used only if the sending side can create and the receiving side can not accept jitter. The SIP channel can accept jitter, thus a jitterbuffer on the receive SIP side will be used only if it is forced and enabled.

jbforce = yes|no

Forces the use of a jitterbuffer on the receive side of a SIP channel. Defaults to "no".

jbmaxsize = #number

Max length of the jitterbuffer in milliseconds.

jbresyncthreshold = #number

Jump in the frame timestamps over which the jitterbuffer isresynchronized. Useful to improve the quality of the voice, with big jumps in/broken timestamps, usually sent from exotic devices and programs. Defaults to 1000.

jbimpl = fixed|adaptive

Jitterbuffer implementation, used on the receiving side of a SIP channel. Two implementations are currently available - "fixed" (with size always equals to jbmaxsize) and "adaptive" (withvariable size, actually the new jb of IAX2). Defaults to fixed.

jblog = no|yes

Enables jitterbuffer frame logging. Defaults to "no".