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 - the local network


Sometimes voice calls made through your Asterisk VoIP server don't connect as they should. This article explains how to start debugging connection problems.

Plain old telephone service (POTS) has built a justifiably solid reputation for reliability. You pick up the phone, enter a number, and with a high probability of success your call goes through. VoIP as a competitive technology is not quite as reliable, but VoIP comes with advantages such as lower cost and greater adaptability, so VoIP subscribers may be willing to put up with a a few failed calls and system glitches. If you manage a VoIP system, however, you need to minimize those occasional difficulties and recover from them quickly. That's why you need a good call failure debugging plan.

Let's walk through a practical call debugging process. Suppose you have a desktop VoIP phone connected via LAN to a local Asterisk server, which in turn is connected over a WAN to a VoIP provider that connects into the POTS network. Now suppose a user picks up the phone and enters a valid number, but the system returns a message such as Service Unavailable or Declined. How do you know where the problem is?

Failures may occur at a number of different pinch points. To track down a problem, start locally and move out in wider circles.

1. Are local extensions working?

Try to keep at least one extension on the local network to use as a diagnostic tool. You can dial that number to see if Asterisk handles local calls correctly. If it does, you can skip the next section and jump directly to dialplan or SIP problems. If not, start looking for a local problem.

2. Is the phone talking to the local Asterisk server?

Many standard IP phones give a visual indication when they are properly connected to an Asterisk box, but this may not be enough information to see that all is well. You can try to connect to the Asterisk console to get more information:

# asterisk -rvvv

This command should indicate something similar to the following, where xxxx is a machine ID:

Connected to Asterisk SVN-branch-11-r396310 currently running on linux-xxxx

SIP (Session Initiation Protocol) is the protocol some VoIP phones use to communicate with their controlling servers, to navigate from the phone out into the wide area to connect to the destination, and to set up the necessary parameters for voice and perhaps video interaction.

This tells you that Asterisk is up and running correctly.

Since a SIP phone is having a problem, you can delve deeper into what Asterisk knows about SIP connections. First, try the command

linux-xxxx*CLI> sip reload

to reload your SIP configuration. If you reload only your SIP setup, any messages Asterisk sends regarding misconfiguration will be easy to see in the log, rather than be lost in a torrent of logging messages from a general restart of the entire Asterisk server. You might for example get

WARNING: key=value is deprecated, use key=newvalue instead

If you see this, it could be telling you that Asterisk has changed the way it specifies some parameters. Your current configuration may still work, but it's worth investigating what changes are happening. New options might benefit your setup. Regular review of the overall SIP configuration for correctness, particularly if you upgrade the Asterisk application but keep the same configuration files, helps keep configuration and application in sync.

Next you can run

linux-xxxx*CLI> sip show peers

The list this command generates should show overview details of the SIP phones connected to the Asterisk server. If your phone is not in the list, or is there but its status is "UNKNOWN," then the problem likely is in your Asterisk server's sip.conf configuration file. Check details such as password and username, and that the correct ports (usually 5060 UDP at least, plus others as required for your network) are accessible via the Asterisk server's firewall.

For further detail on a specific peer, enter:

linux-xxxx*CLI> sip show peer peername

Pressing the tab key after sip show peer gives you a list of the SIP peer names known to the system. The resulting list of "key=value" pairs contains the active values for each key – even for peers not connected at the time, and even if a key is not specified in the sip.conf configuration file. The list gives immediate feedback on what the system knows to be the current values for items such as caller ID, primary transport, session timers, and DTMF mode. (DTMF – dual tone multi frequency – refers to the warble tones a phone generates when you press a number on the keypad.) You can then check that the values are correct for your system and that they are compatible with what the Asterisk server is expecting. For example, the destination number may be set to only recognize a valid and known caller ID. You might find that your primary transport is set as UDP, but you remember you opened the firewall only on TCP. Session timers may be set when they should not be. DTMF signals may be set to the incorrect variety, in which case dialing any number at all would not work. All of these settings can interfere in one way or another with trouble-free calling.

3. Is the Asterisk dialplan handling the number correctly?

If the phone is visible to the Asterisk server and correctly recognized, you need to look further. The next pinch point could be the dialplan. A dialplan is a list of user-defined rules Asterisk uses to find out what it should do when you dial a number. The rules can be simple or complex, and can use wildcard patterns to encompass a wide range of number combinations. The dialplan can be divided into contexts, or sections that operate completely independently of each other if required. If your dialplan is not correctly organized, then when you enter a number it might be handled either not at all or by the wrong part of the dialplan, with unintended consequences.

Fortunately, you can easily check what the dialplan does in response to a number being dialed:

linux-xxxx*CLI> dialplan show 123456@

shows what the dialplan proposes to do when asked to dial the number 123456 from any context. To add a specific context to the query, put it after the "@" symbol. This step can often show that while you thought one part of the dialplan was invoked first, in fact the number is handled by a completely different part.

You might have a problem in the dialplan if frequently used numbers go through correctly, but infrequently used numbers such as international destinations fail. The non-standard strings of numeric characters for those numbers might not fall easily into one of your defined patterns.

Here's an example of how this can happen. Consider the following dialplan segment:

exten => 12,1,Dial(SIP/123456@provider,20)
exten => _XXXXXX,1,Dial(SIP/${EXTEN}@provider,20)
exten => _XX,1,Dial(SIP/234567@provider,20)
exten => 13,1,Dial(SIP/654321@provider,20)

Note that each context contains a pattern that begins with an underscore. The first context can handle all six-digit numbers and the two-digit number 12, and the second context handles all two-digit numbers but does something special with 13. When a user dials 13, it can be handled only in context 2. Context 1 has no way of dealing with it, so if another part of the dialplan tries to use 13 in context 1 the call will fail.

When a user dials 12 however, it could be handled by either context. It could fit the special case in context 1 or be trapped by pattern-matching in context 2, and each context would send the call to a different destination. Numbers that are neither two nor six digits long are not handled at all, and therefore will report the message "Declined" at the phone, and "channel 'SIP/xxxxxx' status is 'UNKNOWN'" at the Asterisk console. Note that the order of the lines in each context does not indicate a priority – instead, Asterisk calculates which entry is more specific and applies that first. In this case, if Asterisk is given the number 12 without any context reference, it will place the explicitly programmed 12@context1 first and the 12 as a result of _XX@context2 second.

Another subtle error is to use the priority variable "n," which is used to indicate to Asterisk the order in which lines should be processed, without first specifying a priority 1 explicitly. Here is an example of the use of this variable, in particular in a way which will break the dialplan:

exten => 12,n,Dial(SIP/123456@provider,20)
exten => 12,n,Hangup()

Here in context 3, the extension 12 will not be seen by Asterisk at all since there is no priority 1 to start the priority series. To fix this, you either change the first "n" variable to a "1" or place a new line before the Dial command that states explicitly the priority "1."

A dot in a pattern handles anything, so a pattern like "_X." is often used to trap any sequence of numbers or letters that begins with a number. While this may make sense in your situation, use very general patterns with care and try to avoid it where possible. You can use generic wildcard patterns such as this for catching unusual numbers and returning diagnostic messages via the Noop() function.

Another section that can make your dialplan misbehave is URI dialing – that is, a section that provides rules for dialing not a number but an email address or other destination that contains alphabetic characters. URI dialing must handle both numbers and alphabetic characters; email addresses, for example, often contain both. Ensure that all all-number dial strings are handled correctly before the dropthrough to URI handling takes place.

After all this debugging you have verified that the local setup appears to be working. In the second and final part of this article we will examine in greater detail the connection outside the LAN.

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


Thanks for sharing the idea there would be some apprehensions from segment but i am up for it.
Posted @ Tuesday, September 10, 2013 2:01 AM by Wireless Network Installation
Its real awesome post It was really helpful to me.
Posted @ Monday, October 07, 2013 2:57 AM by Wireless Network Installation
Its real awesome post It was really helpful to me.
Posted @ Wednesday, October 16, 2013 6:02 AM by TBG Digital
Thanks for sharing the idea there would be some apprehensions from segment but i am up for it.
Posted @ Wednesday, October 16, 2013 6:16 AM by TBG Digital
Any deposits for acids during the kidneys results in any structure for kidney shingle together with in fact results in gucci replica debris that will stop functioning. In case you body system is minus acidic, you can expect to difficultie to focus on tumbling or simply wiping out usage of acid-causing certain foods together with things. Any minus stomach acid leisure your entire body provides and also rolex replica watches point in time an individual's kidneys will present. An individual's kidney debris happen to be irreplaceable the fact that not having good involvement, which means that you ought to twitch without delay aggravating that will control your own body's pH point. Don't just could that you choose to reduce the use of an individual's kidneys, you can expect to chanel outlet a good principally growth in your own pattern and likewise reduce your susceptability that will kidney medical conditions. Herbal treatments meant for Kidney Gallstones: Kidney Legumes: Oneself certain kidney legumes during standard water together with always keep it all in a single day. Next day slash those kidney legumes together with add more him or her towards related to five liter for standard water together with always keep him or her meant for boiling. Steam him or her relating to six to eight a lot of time. Consequently difficulties the rolex replica watches together with allow it to amazing hublot replica watches. As just stated difficulties it all through the help of muslin wash cloth together with enjoy an individual wineglass for this choice. Once every last several a lot of time enjoy an individual wineglass for this aqueous. Take into account, the maximum amount you can expect to enjoy the choice a lot conveniently an individual's kidney gallstones will receive defeated. 
Posted @ Sunday, May 04, 2014 2:55 AM by maymay
thanx! also visit <a>
Posted @ Thursday, August 21, 2014 1:16 PM by make money with webcams
Post Comment
Website (optional)

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