+- Yealink Forums (http://forum.yealink.com/forum)
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: Configuration (/forumdisplay.php?fid=24)
+--- Thread: T48S One Way Audio When Calls Are Put On Hold Or Transferred (/showthread.php?tid=47483)
T48S One Way Audio When Calls Are Put On Hold Or Transferred - MJauja - 03-08-2024 04:55 AM
Hi all, I am fairly new to the softswitch world, have previously been using 3CX and Netsapiens.
We are now using PortaSwitch and am experiencing oneway audio with T48S when a call is put on hold, or put on hold during an attended transfer (blind transfer works without issue)
Below is some of the detail i have received from PortaOne support. Does anyone have any thoughts on what could be causing this?
According to our analysis, the issues with no audio on the "holder" side are related to the behavior of the UA:
after the unhold the UA declares a new port to be used for the media stream, the RTPproxy registers this new port as a destination for media, but the UA keeps sending packets from the old port instead of a new one and we believe it expects the media to be delivered to this port, but RTPproxy sends RTP to a newly registered port and due to a mismatch in the destination port there is no audio on the "holder" side.
The same happened during the hold removal request (00:05:53) when Callee requested 16324 port for media.
In both cases, RTPProxy updated the media port for callee.
But despite requesting new media ports, Callee continued sending media from the old port, 16288, when the hold was removed.
RE: T48S One Way Audio When Calls Are Put On Hold Or Transferred - complex1 - 03-09-2024 08:48 PM
(03-08-2024 04:55 AM)MJauja Wrote: Hi all, I am fairly new to the softswitch world, have previously been using 3CX and Netsapiens.
We are now using PortaSwitch and am experiencing oneway audio with T48S when a call is put on hold, or put on hold during an attended transfer (blind transfer works without issue)
Below is some of the detail i have received from PortaOne support. Does anyone have any thoughts on what could be causing this?
According to our analysis, the issues with no audio on the "holder" side are related to the behavior of the UA:
after the unhold the UA declares a new port to be used for the media stream, the RTPproxy registers this new port as a destination for media, but the UA keeps sending packets from the old port instead of a new one and we believe it expects the media to be delivered to this port, but RTPproxy sends RTP to a newly registered port and due to a mismatch in the destination port there is no audio on the "holder" side.
The same happened during the hold removal request (00:05:53) when Callee requested 16324 port for media.
In both cases, RTPProxy updated the media port for callee.
But despite requesting new media ports, Callee continued sending media from the old port, 16288, when the hold was removed.
Hi,
All I can say is that one-way audio is usually caused by the router.