Revision as of 11:50, 8 June 2011

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 does 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)
Make sure you are using the same RTP range as your provider
Make canreinvite = no in device settings
Remove T.38 Support from device settings

t38pt_udptl = yes
t38pt_rtp=no
t38pt_tcp=no

and change to:

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

Reload Asterisk.

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.

Check if you are not using aLaw codec, as we have experiences previous problems with using Eyebeam and aLaw.

@@ Line 40: / Line 40: @@
 <br><br>
-= Device connected to MOR is Eyebeam ==
+= Device connected to MOR is Eyebeam =
 Check if you are not using aLaw codec, as we have experiences previous problems with using Eyebeam and aLaw.
 <br><br>
 = See also =
 * [[One way audio problems | One-way audio problems]]