Applies to VoipNow 3 and higher! |
This knowledge base article presents several debug methods useful when confronting with problems regarding the incoming calls.
The IP/network address the channel accepts calls from should be set to the IP or network address of the provider. This applies only to incoming calls made through that channel.
To do so, take the following next steps:
STEP 1: Click the Channels link available in the left navigation panel.
STEP 2: Select the desired channel from the list and click the Edit channel icon.
STEP 3: Verify the value specified for the Accept calls from IPs/network option.
If a domain name is added, then you will have to change it to the provider's IP/network address.
If you do not know this IP/network address, please ask the provider or use a ping command with the provider's domain name.
You can add multiple IP/network addresses if the provider uses multiple addresses to route calls through.
If the provider requires a registered channel, then the provider should give you the necessary credentials (username and password), as well as the channel mandatory settings (codecs, in-band signaling, etc.).
If you have set up a channel and it does not show up in the interface as Registered, then you need to make sure that:
If the channel options appear to be set up correctly, yet the channel still fails to register, the best tool to find out the cause is the Asterisk Console:
root
using a SSH client (e.g. Putty
).Enter the following command to start the Asterisk Console:
asterisk -rvvvvvvvvvvvvvvvvvvvvvvvvv |
Check if Asterisk is able to connect to the provider's remote host by running the command below. This will print a list with all the hosts currently connected to Asterisk. If your channel is on the list and its status is OK, then Asterisk is able to communicate with it.
sip show peers |
REGISTER
SIP packet the server is sending when trying to register the channel.In order to gain access to the SIP traffic, you need to enable SIP debugging from the Asterisk Console using the command below:
sip set debug on |
To disable debugging, use:
sip set debug off |
REGISTER
packets in the console window and the responses you get from the provider's IP address. This information can be very useful to the support team if you post a ticket regarding a channel issue. If the provider requires special channel settings, the response will most likely contain 4xx packets. In such a case, you need to check with the provider to see the settings needed for the channel to be able to register on their server.Let us assume the channel registers correctly to the provider or makes use of an IP-based authentication and you have already configured the DIDs assigned to you by the provider. If the extension still does not ring when you place a call, it is recommended that you use the Asterisk console to find out the problem. The call may not reach your server on account of three possible reasons:
To solve the issue, you need to connect to the console as described above, enable SIP debugging and then try calling the number again.
If the call reaches the server, then you should be able to see a lot of SIP packets and messages in the Asterisk Console. If you can't see anything at all, it means the call cannot reach Asterisk. In this case, the problem might be caused by the Kamailio service. For helpful hints, you have to take a look at the Kamailio log:
Log on to the server console and increase the level of the debugging output:
kamctl fifo debug 3 |
At this point, you need to run the following command:
tail -f /var/log/kamailio/kamailio.log |
Make a call and look at the output. If the DID or provider IP is not correctly set up on the channel, you should be able to see a message similar to the one below:
NOTICE: IP address 1.2.3.4 is not allowed to call DID number 12345678. Unauthorized request. |
In this case, you must set up the IP to 1.2.3.4 on the same channel for which you have defined the DID as 12345678.
If you get SIP traffic from the provider during the call, this means the call reaches the server and the problem has a different cause (please see the next section).
If the channel is fully functional, the calls reach the server, yet the extension you have assigned to the DID still fails to ring, then you should take the following steps:
STEP 1: Diagnose this issue. To do this, connect to the server and open an Asterisk Console. Then enable SIP debugging and call the DID. Upon calling the DID, the provider will send an INVITE
packet to your server to establish a connection. Here is an INVITE
SIP packet example:
INVITE sip:1234567@192.168.1.2:5050 SIP/2.0 Record-Route: <sip:192.168.1.2;lr=on;ftag=be3c3d58;did=bfb.0832fc56> Via: SIP/2.0/UDP 192.168.1.4:49648;branch=z9hG4bK-d8754z-70194869696f7f21-1---d8754z-;rport=49648 Max-Forwards: 69 Contact: <sip:0003*001@192.168.1.4:49648> To: "1234567"<sip:1234567@192.168.1.2> From: "some_user"<sip:0003*001@192.168.1.4>;tag=be3c3d58 Call-ID: OTVmYTJmMDQ1ZWU1YTExNmQ3ZjE2N2U0ZDJkYTY2MDM. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp
STEP 2: Note the INVITE
header (the first line). This is a proper header for a DID sent by the provider.
The provider needs to specify the DID getting the call in the INVITE
header. This is usually done except when:
INVITE
header at all. They either send it in the TO
header or in a custom header. If it gets sent in the TO
header, VoipNow can use it. If the provider sends the DID in a custom header, you need to configure the channel to get the DID using the Get DID from custom header option available in the Channel Settings page.