search

InnovateAsterisk / Browser-Phone

A fully featured browser based WebRTC SIP phone for Asterisk
https://www.innovateasterisk.com
GNU Affero General Public License v3.0
516 stars 256 forks source link

Incoming call one way audio #181

Open terenz198 opened 2 years ago

terenz198 commented 2 years ago

Hi, I was faced with this today. From PC to Android phone, audio is only received by the caller. No sound is received by the callee. Can you please, help me to know the reason. Thanks

InnovateAsterisk commented 2 years ago

The primary reason one-way (or no audio) is caused from ICE negotiation failures. This leaves the two peers sending audio packets to the wrong ip addresses (or wrong ports). The best way to debug this is to enable RTP debug - but just remember RTP generates a massive amount of output to the screen, so be sure to only enable it while you only have the peers in question making the calls. Same goes for SIP debugging.

CLI> pjsip set logger on CLI> rtp set debug on

These two command give you everything you need to know about both the signalling and RTP media of call.

terenz198 commented 2 years ago

Hi, I've effectively seen massive output data. Some things I didn't fully understand. But, I notice that the RTP packets are sent via ICE. Also the SIPJS library uses by default one of the STUN servers "stun:stun.l.google.com:19302" provided by Google. I thought STUN settings are not needed since Browser phone is used in LAN and clients are anyway reachable. In the case, where peers aren't in differents networks, would ICE negotiation failure cause reception of RTP frame without data ?

Sorry, for the inconsistency in my writings, I have just started with WebRTC if you can bring me some clarifications, I will be delighted. Thanks

InnovateAsterisk commented 2 years ago

The same STUN settings should be applied to the rtp.conf file: https://github.com/InnovateAsterisk/Browser-Phone/blob/master/config/rtp.conf

Even if the calls are over a local LAN, the ICE(Interactive Connectivity Establishment) negotiation is part of the WebRTC call setup process, so should be enabled and allowed to complete.

I wouldn't try to exclude ICE from your deployment plan - rather try to get it to operate efficiently.

InnovateAsterisk commented 2 years ago

Fix being released shortly