MJauja
Junior Member
Posts: 1
Joined: Jun 2023
|
T48S One Way Audio When Calls Are Put On Hold Or Transferred
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.
(This post was last modified: 03-08-2024 05:04 AM by MJauja.)
|
|
03-08-2024 04:55 AM |
|
complex1
3CX Adv. Cert. Engineer
Posts: 1,527
Joined: Jan 2014
|
RE: T48S One Way Audio When Calls Are Put On Hold Or Transferred
(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.
Kind regards,
Frank.
I am not an employee of Yealink.
Dutch is my native language, not English. Apologies for my imperfect grammar.
Please do not send unsolicited PM messages. I will not answer them.
|
|
03-09-2024 08:48 PM |
|