Difference between revisions of "One-way audio or not audio at all"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(2 intermediate revisions by 2 users not shown)
Line 11: Line 11:
* 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 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''')
* Make sure you are using the same RTP range as your provider
* If under NAT, forward UDP 10.000-20.000 ports to your local server IP (together with UDP/TCP 5060)
* 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
* 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.




Line 68: Line 53:
= 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.
    • H323 binaddr.png
    • 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

Retrieved from "https://wiki.kolmisoft.com/index.php?title=One-way_audio_or_not_audio_at_all&oldid=26289"