Difference between revisions of "One-way audio or not audio at all"
From Kolmisoft Wiki
Jump to navigationJump to search
| (16 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
<mkmeta>How to solve one-way audio or no audio problem</mkmeta> | |||
* /etc/init.d/iptables stop | * /etc/init.d/iptables stop | ||
| Line 4: | Line 6: | ||
= Device is SIP = | = 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 | * 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. | ||
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 | * rtp debug, watch to see whether or not audio is coming/leaving | ||
* Make sure sip.conf is correctly configured if [[Asterisk under NAT | Asterisk is behind NAT]] | * Make sure sip.conf is correctly configured if [[Asterisk under NAT | Asterisk is behind NAT]] | ||
* Make sure you are using correct codecs (same codecs in all the path of the call). Some devices | * 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''') | * 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 | * Make '''canreinvite = no''' in device settings | ||
| Line 40: | Line 27: | ||
<br><br> | <br><br> | ||
= 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'''. | |||
<br><br> | |||
= RTP debug = | |||
* To enable RTP debug, login into your server via SSH and open [[Asterisk_CLI | 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) | |||
<br> | |||
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 = | = See also = | ||
* [[One way audio problems | One-way audio problems]] | * [[One way audio problems | One-way audio problems]] | ||
* https://blog.kolmisoft.com/the-causes-of-no-audio-and-one-way-audio-voip-calls/ | |||
Latest revision as of 06:22, 3 March 2021
- /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
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.
