Asterisk debugging: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
Created page with "This page has tips on what to do when debugging Asterisk problems == One way audio == Typically happens when remote phone and server are NATTED (one end or both) Make sure..."
 
Brian Wilson (talk | contribs)
 
(2 intermediate revisions by the same user not shown)
Line 7: Line 7:
Make sure remote phone is set to nat=? (where ? != no)
Make sure remote phone is set to nat=? (where ? != no)
so that Asterisk ignores the non-routable address in the SIP header and uses the packet source instead.
so that Asterisk ignores the non-routable address in the SIP header and uses the packet source instead.
There has to be a clear path both directions for the RTP stream, which is where the media (audio) is transported.
That means the SIP session can run just fine but if the RTP stream is blocked in one direction, the recipient of that stream will get no audio channel.
Since RTP flows over a UDP port there is no built in error correction, the sender just blindly spits out UDP packets without knowing if they are getting through or not. This makes it a little more mysterious.


== Asterisk Variable ==
== Asterisk Variable ==
Line 22: Line 27:
sip set debug on
sip set debug on


From asterisk list --
The analysis of a SIP Debug depends on what the problem to be solved.
If you experience problems with inbound calls from a SIP trunk or
provider, you can type in Asterisk cli 'core set debug 3' and then
'sip set debug ip xxx.xxx.xxx.xxx' where xxx is the IP of your SIP
provider or from where it is supposed to come call.
Then you make a test call, and look in full log an INVITE message
(note that you analize an OPTION message in your mail, but I think
that this not help in this case).
After the incoming INVITE message from your SIP provider, you can
follow the rest of the Asterisk logic and look for the reason why
Asterisk is denying that call.
Also --
Another path to enlightenment is to use tcpdump to capture the packets to a file and then use wireshark.
Wireshark has a 'Telephony' menu and a 'SIP Flows' menu item where it will list all of the SIP packets. You can sort by column to help locate the packet of interest.
Once found, you can click on 'Flow Sequence' and it will pop up a window showing the 'dialog ladder' that includes that packet. As you click on each packet in the flow, the main wireshark window will re-position to that packet so you can examine it in detail.
Also on the 'SIP Flows' window is a 'Play Streams' button. Kind of scary how easy this is...


== CDS Mikrotik router ==
== CDS Mikrotik router ==

Latest revision as of 16:39, 7 July 2016

This page has tips on what to do when debugging Asterisk problems

One way audio

Typically happens when remote phone and server are NATTED (one end or both)

Make sure remote phone is set to nat=? (where ? != no) so that Asterisk ignores the non-routable address in the SIP header and uses the packet source instead.

There has to be a clear path both directions for the RTP stream, which is where the media (audio) is transported. That means the SIP session can run just fine but if the RTP stream is blocked in one direction, the recipient of that stream will get no audio channel.

Since RTP flows over a UDP port there is no built in error correction, the sender just blindly spits out UDP packets without knowing if they are getting through or not. This makes it a little more mysterious.

Asterisk Variable

http://www.voip-info.org/wiki/view/Asterisk+Detailed+Variable+List

MySQL

When using MySQL you can turn on MySQL logging and watch the queries

SIP

When debugging calls you can turn on SIP debugging like this

sip set debug on

From asterisk list --

The analysis of a SIP Debug depends on what the problem to be solved.

If you experience problems with inbound calls from a SIP trunk or provider, you can type in Asterisk cli 'core set debug 3' and then 'sip set debug ip xxx.xxx.xxx.xxx' where xxx is the IP of your SIP provider or from where it is supposed to come call.

Then you make a test call, and look in full log an INVITE message (note that you analize an OPTION message in your mail, but I think that this not help in this case).

After the incoming INVITE message from your SIP provider, you can follow the rest of the Asterisk logic and look for the reason why Asterisk is denying that call.

Also --

Another path to enlightenment is to use tcpdump to capture the packets to a file and then use wireshark.

Wireshark has a 'Telephony' menu and a 'SIP Flows' menu item where it will list all of the SIP packets. You can sort by column to help locate the packet of interest.

Once found, you can click on 'Flow Sequence' and it will pop up a window showing the 'dialog ladder' that includes that packet. As you click on each packet in the flow, the main wireshark window will re-position to that packet so you can examine it in detail.

Also on the 'SIP Flows' window is a 'Play Streams' button. Kind of scary how easy this is...

CDS Mikrotik router

Rules to enable Vastra (NUC)

add action=dst-nat chain=dstnat comment="Vastra" dst-address=107.135.132.129 dst-port=5060 protocol=udp to-addresses=192.168.2.234 to-ports=5060 add action=dst-nat chain=dstnat comment="Vastra RTP audio stream" dst-address=107.135.132.129 dst-port=10000-19999 protocol=udp to-addresses=192.168.2.234 to-ports=10000-19999


Rules to enable Vastra2

add action=dst-nat chain=dstnat comment="Vastra2 PBX" dst-address=107.135.132.129 dst-port=5060 protocol=udp to-addresses=192.168.2.235 to-ports=5060

add action=dst-nat chain=dstnat comment="Vastra2 RTP audio stream" dst-address=107.135.132.129 dst-port=10000-19999protocol=udp to-addresses=192.168.2.235 to-ports=10000-19999


Rules to MODIFY

set 0 to-addresses=192.168.2.235