I have an interesting issue, where when a call is initiated using ARI on Asterisk 16.8, the call connects fine and there is two way audio.
The originator of the call is a sip client, and the called party is a mobile/cell phone.
I wondered if there are any settings I am missing in relation to how ‘silent rtp’ is handled as the call uses codec G711A, and when the called party hits the mute button, not all the ‘silent rtp’ packets are passed across channels so after a number of seconds the sip client hears echo (their own breathing and typing on keyboard) and looking at the RTP streams not all the silent rtp packets are passed end to end, it appears some are dropped by Asterisk, and this only happens when we record the call using /bridges/{bridgeId}/record, if we dont record the silent rtp packets are honoured end to end and we dont have any echo.
Has anyone had this issue or know some parameters we can test? I have tried maxSilenceSeconds and so on but the same behaviour persists.
Any tips/comments would be amazing! Or if I should raise as a bug or anyone has seen before please let me know.
Thanks for the reply, they are not comfort noise just to be clear this is not applicable in this case with G711A alaw, where payload is entirely populate with 0xD5 as per the itu spec for G711.
I appreciate this is an unusual scenario but if a sip client device has no consistent rtp stream being sent back to it then local echo can occur as I can reproduce on demand so would appreciate some guidance on how I can progress this with the asterisk devs as can prove its that case.
Who can I provide technical detail to, do I need to potentially raise a bug? As I say the silent rtp packets are not consistently streamed when recording is applied, however with it disabled the payload of 0xD5 which I require is passed end to end without issue.
Is there an SSRC change when transmission of zero samples starts, and which is not being propagated across Asterisk?
It is possible that there is poor echo cancellation at the end sending silence and the other other end is learning the end to end echo characteristics, and your echo is actually an inverted echo when the receiver continues to cancel the echo that would have been produced if the sent audio hadn’t been forced to be all zero samples. The lack of an SSRC change may mean that the echo canceller doesn’t retrain.
If this is a problem related to Asterisk not maintaining SSRCs end to end, my guess is that it is unlikely that Asterisk will be changed, as this is likely to be rather fundamental to the core of Asterisk.
Thanks again for the response, I really appreciate your input and your comments make sense.
This issue I am seeing (and the SSRC remains consistent and there is no packet loss) is that the ‘silent rtp’ (payload all d5) being sent into Asterisk
from the carrier channel, is for example 16 seconds, and initially the channel to the sip client device has this ‘silent rtp’ sent to it, however it is
not for the full duration of time its sent into Asterisk in the carrier channel, it is in some examples 4 seconds but this time can vary (not consistent)
and only happens when we instruct ARI to record the channel for example;
Channel Recorder/ARI-0000001d;2 joined ‘simple_bridge’ stasis-bridge <6122d8f1-9706-4522-8371-539ad1036193>
Bridge 6122d8f1-9706-4522-8371-539ad1036193: switching from simple_bridge technology to softmix
If we dont record the channels this scenario doesnt happen and we get the same duration of ‘silent rtp’ on both the Carrier channel and the sip client channel, so
in the example above it would be 16 seconds of silent rtp on both channels as opposed to a shorter duration on the sip client channel.
There are no changes to SSRC, ports etc, the only change is the payload changes from all d5 to what could be considered a normal payload without any obvious changes
I can see.
And yes point taken about the end sip device and echo, but this happens across multiple devices and we cant really look to resolve on client side and as it only
happens when recording I assumed it might be configuration related or potentially a bug but wanted to reach out first to the community to see if anyone had seen
this before.
We are running 16.8, I wondered if there is value in me updating to 16.10 to see if the same issue occurs?
By the way the behaviour is the same on 16.10 (I updated) and the silent rtp is end to end when I hangup the recording channels, however with recording in place the silent rtp packets are not consistently sent so I would assume its something around the recording channels/mechanism, so any suggestions are very welcome.
When recording is done it’s not forwarding packets. Instead the bridge becomes a conference bridge with an added recorder channel, and the conference bridge becomes the source of audio. I’ve never tested with such packets with the mixer, so I don’t know what impact or result would occur.