One-way audio or not audio at all

• /etc/init.d/iptables stop

Device is SIP

• Check if your SIP/H.323 supports the codecs you use in MOR, for example eyeBeam does not support aLaw codec, so you will not have audio if you use aLaw as default codec for that device in MOR.
• rtp debug, watch to see whether or not audio is coming/leaving
• Make sure sip.conf is correctly configured if Asterisk is behind NAT
• Make sure you are using correct codecs (same codecs in all the path of the call). Some devices do not support some codecs. Make tests using 1 same codec across the call path. Disable all others.
• Make sure NAT settings are correct (nat=yes) (in provider/device settings)
• If under NAT, forward UDP 10.000-20.000 ports to your local server IP (together with UDP/TCP 5060)
• Make canreinvite = no in device settings
• Remove T.38 Support from device settings

• In /etc/asterisk/sip.conf find lines:

t38pt_udptl = yes
t38pt_rtp=no
t38pt_tcp=no

and change to:

;t38pt_udptl = yes
;t38pt_rtp=no
;t38pt_tcp=no

Reload Asterisk.

Device is H323

• If while connecting with an H.323 client, you get no audio or garbled audio and messages like this on the Asterisk console: rtp.c:489 ast_rtp_read: Unknown RTP codec 107 received, try to disable Speex or some other codec on Asterisk and/or the client side.
• If there is no audio in H323 calls, make sure in /etc/asterisk/h323.conf that you have binaddr set to your server's real IP address.
  • 
  • After this, restart Asterisk.

Device connected to MOR is Eyebeam

Check if you are not using aLaw codec, as we have previously experienced problems when using Eyebeam and aLaw.

RTP debug

• To enable RTP debug, login into your server via SSH and open Asterisk CLI
• Next, enable RTP debug by using this command

rtp debug

• If you see a similar continuous output when call is connected:

Got  RTP packet from    192.168.0.1:12820 (type 18, seq 000193, ts 030880, len 000020)                                                                                                 
Sent RTP packet to      192.168.0.2:60000 (type 18, seq 018183, ts 030880, len 000020) 
Got  RTP packet from    192.168.0.1:7388 (type 00, seq 054468, ts 3545991335, len 000160)                                                                                              
Sent RTP packet to      192.168.0.2:30060 (type 00, seq 015789, ts 3545991328, len 000160)                                                                                            
Got  RTP packet from    192.168.0.1:65354 (type 18, seq 030581, ts 1271165256, len 000020)                                                                                            
Sent RTP packet to      192.168.0.1:9604 (type 18, seq 013256, ts 1271165256, len 000020)                                                                                              
Sent RTP packet to      192.168.0.1:30072 (type 00, seq 055490, ts 493120, len 000160) 

This means RTP packets are entering and leaving the server, thus AUDIO is passing.

If you do not see any of the above, this means AUDIO is neither entering nor leaving the server.

See also

• One-way audio problems