Call not hear before hold

Asterisk Asterisk SIP
1

I have two Asterisk servers: the primary (A) and the secondary (B). When a call is received on server A via the special number 0112xxx515, it is routed to server B. After completing the IVR functions, the call connects to an agent using WebRTC.

However, there is an issue: when a call is received by an agent from server B, the agent cannot hear the customer, but the customer can hear the agent. After placing the call on hold and then resuming it, audio works correctly in both directions.

From the RTP logs, I observed that the secondary server only starts using my public IP (124.xx.xx.53) with ICE after the hold/unhold action. Before that, it does not use the public IP, which causes the one-way audio problem.

How can I fix this issue

124.xx.xx.53 is my publick ip

172.20.8.20 is my laptop ip which has agent application work using webrtc

172.20.11.254 is my secondary server gateway

</


Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058218, ts 2038472848, len 000160)
Sent RTP packet to      172.20.11.254:11382 (type 00, seq 008302, ts 4243218584, len 000160)
Got  RTP packet from    172.20.8.20:57796 (type 00, seq 027250, ts 4243217951, len 000170)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058219, ts 2038473008, len 000160)
Sent RTP packet to      172.20.11.254:11382 (type 00, seq 008303, ts 4243218744, len 000160)
Got  RTP packet from    172.20.8.20:57796 (type 00, seq 027251, ts 4243218111, len 000170)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058220, ts 2038473168, len 000160)
Sent RTP packet to      172.20.11.254:11382 (type 00, seq 008304, ts 4243218904, len 000160)
Got  RTP packet from    172.20.8.20:57796 (type 00, seq 027252, ts 4243218271, len 000170)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058221, ts 2038473328, len 000160)
    -- Stopped music on hold on PJSIP/forward136-00000045
Sent RTP packet to      124.xx.67.xx:57796 (via ICE) (type 107, seq 013470, ts 130656, len 000103)
Got  RTP packet from    172.20.8.20:57796 (type 00, seq 027253, ts 4243218431, len 000170)
Sent RTP packet to      172.20.11.254:11382 (type 00, seq 008305, ts 4243218424, len 000160)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058222, ts 2038473488, len 000160)
Sent RTP packet to      124.xx.xx.53:57796 (via ICE) (type 00, seq 013471, ts 130816, len 000170)
Got  RTP packet from    172.20.8.20:57796 (type 00, seq 027254, ts 4243218591, len 000170)
Sent RTP packet to      172.20.11.254:11382 (type 00, seq 008306, ts 4243218584, len 000160)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058223, ts 2038473648, len 000160)
Sent RTP packet to      124.xx.xx.53:57796 (via ICE) (type 00, seq 013472, ts 130976, len 000170)
Got  RTP packet from    172.20.11.254:11382 (type 00, seq 058224, ts 2038473808, len 000160)




/>
2

So what happens with the ICE negotiation before? What does the SIP trace look like?

If you’re deploying WebRTC you need a solid understanding of ICE as it is fundamental to it.