No audio on unhold for endpoints behind NAT

Hi,

I am facing this issue with PJSIP webrtc endpoints which are connected to asterisk from behind NAT.

Where they receive incoming call and after answer they are able to connect and talk to each other. Once these users put call on hold remote party was able to listen hold music after some time once these users resumes the call, the endpoint user is not able to hear remote callers voice but remote caller is able to hear endpoint user voice.

Observation:-

  • On 1st answer ICE candidate gathering is getting completed and asterisk is able to get the public IP address of the endpoint user
  • On resuming HOLD I didn’t see any logs of ICE gathering to identify public IP again for the endpoint user who resumed the call.

I have asterisk located on azure cloud with public IP assigned to it and endpoint users are connecting to it from there office network.

Asterisk version - 18.18.0

Any help is appreciated, this is bit urgent for me towards my development of product.

You haven’t provided any logging or configuration, which would be needed to understand things based on the data and not strictly your interpretation/analysis.

Sure @jcolp please let me know what data is needed, by which we can determine the underlying cause?
SIP logs for the call I have what else is required to analyse.

RTP trace, SIP logs, Asterisk console output with debug, configuration, network topology description. The more information you provide the more likely it is someone can have input.

1 Like

Attaching console debug output of the call and network architecture for reference.

I have replaced IP addresses as below and also mentioned same in network diagram

444.444.444.444 - SIP trunk Signaling server IP
111.111.111.111 - SIP trunk media server IP
222.222.222.222 - Agent’s office firewall IP
333.333.333.333 - Asterisk server

Please refer below call-ID’s for the call,

Incoming call from caller- SD5bfha01-f15773cfc45171d82214ac08ccc4fb1f-a0bcp33010
Dialled call to Agent - cc5342b5-6929-40b3-8e83-a6c024d7fe8e

And the configuration such as rtp.conf and pjsip.conf? You should also do a packet capture to examine the ICE negotiation.