In the first part of this two-part article we looked at debugging the behavior of failed VoIP calls on the local network. After those tests, we can be sure that the Asterisk server is up and responding, the phone is recognized and fully active, and the dialplan is invoked correctly to dial the number in the right context. If a call is still not connecting with its destination, it is time to check the progress of the call once it leaves the local area.
To get a list of the outgoing connections you have specified in the sip.conf configuration, run
linux-xxxx*CLI> sip show registry
The entry should show a working connection is "Registered." While you are at the CLI you should not see notices or warnings about connections disappearing and reappearing, which might indicate problems with the wide area network. These warnings can appear as notices of the provider connection being "Lagged" if you have qualify=yes set in your SIP configuration. If you see these messages, check your Internet connection and if necessary get your ISP involved.
Once your connection is registered, it might be some time before the registration is checked or renewed. If your connection is intermittent, this can lead to problems such as calls that begin correctly but fail unexpectedly during conversations. If you suspect that the registration is not good, the command sip reload will force a re-registration.
When VoIP calls fail even though the registration is solid, check the connection between the LAN and the VoIP provider by watching the SIP conversation between the local setup and the provider's server. When you check the local connection from phone to Asterisk server, you have root access to the whole system, which makes troubleshooting a lot easier. Communications over the WAN are a bit different; you only see the entire story from one side, so you have to use a different approach.
Two VoIP servers communicate using a protocol such as SIP (Session Initiation Protocol). As the name says, SIP initiates (and concludes) a conversation between two servers. It prepares the way for two other protocols, SDP (session description protocol) and RTP (real-time protocol). SDP handles smaller details of the communication – in particular the streaming audio – and RTP handles the actual voice conversation in real time.
The SIP conversation proceeds in logical steps: One side asks a question and waits for a response, the other side provides information or gives a confirmation. Here is a simple example for a complete outgoing call:
caller sends INVITE
provider sends TRYING
provider sends RINGING
provider sends OK
caller sends ACK
... the actual voice conversation takes place here ...
caller (or provider) sends BYE
provider (or caller) sends OK
Servers may send other codes as well to handle various situations.
Most of the time this conversation goes on in the background and users are blissfully unaware of it, but a number of things can interrupt the flow at some point. A bad password, username, server IP address, or failure to agree on a voice codec all are problems that can force a premature end to the call progress, and force you to investigate what happened.
You can bring the SIP conversation into view in a number of ways. The first is through Asterisk itself. For instance, from the command line, enter:
linux-xxxx*CLI> sip set debug on
SIP Debugging enabled
linux-xxxx*CLI> sip set debug off
SIP Debugging Disabled
The advantage of CLI access is that it lets you see things as they happen. A disadvantage is that you can generate a lot of output to the screen, which can be difficult to follow unless you are looking for a specific detail within a short time. If you are looking for an OK or an ACK, you might see a lot of REGISTER or OPTIONS or NOTIFY events flash by that merely serve to confuse things. SIP debugging mode can be very verbose.
An alternative is the set history functionality with the command sip set history on. This mode captures SIP information in the background for active SIP channels. You can switch history capture on, make an attempted call, then view the output with the command sip show history channel.
sip set history on
sip show history channel
Since a number of SIP conversations (channels) can be going on at any one time, you must specify the channel you're interested in. One way to get this channel ID is to press the tab key after sip show history, at which point the system presents a list of channels for which it has information. Start typing the first few characters that fit, then use tab again to autocomplete the rest of the ID string. The output is a compact, easy-to-read list of events that may give you a hint as to why the communication fails.
sip show history
Once you have finished with this mode, switch it off with the command sip set history off.
sip set history off
The history output is quite condensed, but it might give you an idea of where the problem is. You may still need the detail from sip debug. If reading that output at speed does not appeal to you, you can capture the output to a file by running the following commands from the bash CLI:
# asterisk -x 'sip set debug on'
# asterisk -rvvv > asterisksip.txt
... try the call ...
... Control-c stops the asterisk console ...
# asterisk -x 'sip set debug off'
The first line asks Asterisk to switch on SIP debug output without opening the console, and the second connects to the Asterisk server but redirects output to a file. After the failed call you stop the output from Asterisk, then switch the debug mode off. The file asterisksip.txt then contains the SIP debug output as experienced by the server, which you can examine at leisure.
Yet another approach is to capture the SIP traffic, either directly using Wireshark if you have direct access to the network interface involved, or, if you don't, by using tcpdump, saving the output to a pcap file, and examining it using Wireshark or Cloudshark.
The advantage of using the Wireshark approach compared to SIP analysis via Asterisk is that you have access to a much wider list of protocols that may cast light on your issue if it falls outside the SIP/SDP/RTP domain. By employing the filtering capacity of Wireshark you can reduce the screen output to just those network transactions that are relevant to debugging the problem.
Chances are that you do not have direct access to the network interface and will have to access its traffic indirectly using tcpdump. Start it at the bash CLI, not the Asterisk prompt:
# tcpdump -w udp.pcap -s 0 udp
With this command, tcpdump will record UDP traffic, including SIP, to a file called udp.pcap. In this example I specified no restriction on the amount of detail captured, and only UDP protocol events. Again, switch it on, attempt the call, and switch it off to minimize the amount of data to be reviewed. The file udp.pcap can be read directly by Wireshark or another dedicated pcap reader.
Wireshark is a powerful tool with many capabilities. To examine your traffic, open the pcap file from within Wireshark. At this point you can filter or sort on the protocols, or you can try an alternate procedure. From the main menu, select Telephony -> VoIP Calls; this produces a list of phone calls attempted. Highlight the call you need to analyze and click the Flow button. The result is a list of items similar to the following image:
Clicking on one of the items in the Graph Analysis window acts like a filter on the main Wireshark window, highlighting entries relevant to the call. It helps you focus on the detail required to debug the problem.
When you have verified everything is working on your side and the call still fails, it is time to include the provider in the troubleshooting. Having worked through the preceding list, you have a huge body of information to share with your provider to show that the failure is likely on the provider's side.
However, you may not have to take that final step. One of the advantages of being one subscriber of many to a given service is that since many users share the same system, many are simultaneously "testing" the connections, so any failures are usually quickly reported to the provider.
Finally, remember that there are some issues that no provider can be responsible for. Take completing toll-free number connections that are not accepted outside a particular geographic area. If that's the kind of call that's failing, you need a VoIP provider whose server identifies itself in the defined region. Since many VoIP providers have multiple servers in different areas, usually the solution is just to place your call through a server that gives you access to the number you are trying to dial. Writing this rule into your Asterisk dialplan ensures that each time the number is attempted, it goes through the right server.
Allowed tags: <a> link, <b> bold, <i> italics