Open Source Software Technical Articles

Want the Best of the Wazi Blogs Delivered Directly to your Inbox?

Subscribe to Wazi by Email

Your email:

Connect with Us!

Current Articles | RSS Feed RSS Feed

Debugging failed Asterisk calls outside the local network

  
  
  

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.

4. Is Asterisk talking to the remote VoIP provider?

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.

5. Capturing the SIP conversation

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> 
...
linux-xxxx*CLI> sip set debug off
SIP Debugging Disabled
linux-xxxx*CLI> 

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.

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.

Once you have finished with this mode, switch it off with the command 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.

Examining the debug output with Wireshark

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:

udp

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.

6. Is the remote VoIP provider connecting into the POTS system?

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.




This work is licensed under a Creative Commons Attribution 3.0 Unported License
Creative Commons License.

Comments

You have the Louis Vuitton Handbags, Replica Gucci Handbags and Replica Purses and similar many other items that are almost as good as the originals in terms of quality while their prices are among the most affordable. There’s not much to say about these Fendi Replica Handbags. The shape is unique as it’s slightly bucket shaped but still maintains the stiff versatility of a tote. The key that will purchasing Replica Watches are likely to be buying something that is like the real for the cheapest price. It is most beneficial if pay money for the Replica Rolex watches from our store caused by numerous reasons.
Posted @ Tuesday, December 31, 2013 2:38 AM by over
These situations safeguard the telephone against dirt, scratches, sudden impacts and abrasions. The scenarios not simply secure the phones but give them an attractive physical appearance. You may obtain apple iphone 4 situations built from leather-based, rubber, plastic or silicone and you'll be able to select the one particular that fits your price range. These cases are designed so very well that iphone 4 end users can use the telephone with utmost ease. Their excellent craftsmanship ensures that end users want not just take the telephone out from the include for attending calls or accessing any other cell phone features.Matters to remember when buying apple iphone four cases:* It's essential to ensure that the circumstance you buy fits the telephone completely. This could ensure that your cellphone has a for a longer time lifespan. 
 
iPhone 5 Cases 
burberry iPhone 5s Cases 
prada iPhone 5s Cases
Posted @ Tuesday, May 06, 2014 11:29 PM by iphone case
They may be offered by actually cost-effective rates. In reality the values are only any portion with the hublot replica in which must be covered these kinds of hand bags on the different bags retailers. If you believe in which buying the traditional bags by means of one of many rolex replica internet site remains stretching out the pants pocket a lot of, you then should go for your knockoff bags or perhaps look-alike bags. These kinds of look-alike bags and also knockoff omega replica watches are usually much while they sports activity the identical designs and styles because the substantial bags. The most effective portion will be in which their particular value is significantly below the particular traditional artist bags, even though you get the particular artist hand bags by means of one of many from suppliers artist cheap replica watches bargains. You should buy cina look-alike bags with several sites. They've got end up being the newest phenomenon while they expense merely a cartier watches sale with the authentic value and they're as effective as genuine.
Posted @ Friday, August 22, 2014 1:29 AM by sdfdsfdguanwei
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics