We are facing an issue with Comfort Noise (CN / RFC 3389) in Asterisk, and I would like to understand if anyone has experienced something similar or has recommendations.
Scenario:
When the agent side (SIP extension / WebRTC client) starts sending CN packets, the call becomes completely silent.
After that, the agent stops sending normal RTP audio packets.
The call remains connected, but with no audio in either direction.
Asterisk log message:
[Dec 18 06:37:03] NOTICE[3650946][C-000062de] res_rtp_asterisk.c: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client address: 172.31.110.78:12928
Environment details:
Asterisk version: 18.20.0
SIP/WebRTC client on agent side
Issue happens specifically after CN packets are received from the client
Questions:
Is this a known limitation of Asterisk regarding RFC 3389 Comfort Noise?
Is the recommended approach to disable CN/VAD/silence detection on the client side?
Is there any safe configuration on the Asterisk side to handle CN packets without breaking RTP audio flow?
Has anyone successfully used CN with Asterisk in production without audio drop?
Any insights, configuration examples, or best practices would be greatly appreciated.
Comfort noise is not really supported. We don’t generate it, though can pass through the actual packet (but having not tested this in years that could be broken). I would recommend disabling it. It’s something few people use and is not a path well exercised.
Is it in a broad sense for a call to go silent? Sure. The microphone input could be so low that it is silent, packets could stop flowing, the RTP stream could get messed up, networking could mess up. It’s a very broad question without further context, logging, and packet capture.
To clarify, this issue does not happen on all calls.
We are referring only to calls where Comfort Noise (CN) is detected.
At the moment, we have many calls that work normally, but calls that start sending or receiving CN usually become silent.
The typical sequence we see is:
The call is established and initially works.
When CN packets appear on the agent side, audio stops completely.
The call remains connected, but no RTP audio is exchanged anymore.
First log received:
[Dec 18 10:00:07] NOTICE[3423476][C-00002663] res_rtp_asterisk.c: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client address: 172.31.102.63:12368
Shortly after that, we receive the following warning:
[Dec 18 10:04:18] WARNING[3423005][C-00002663] chan_sip.c: Can’t send 10 type frames with SIP write
Based on our understanding, this seems to indicate that:
Asterisk detects RFC 3389 Comfort Noise from the client
Asterisk then tries to handle or forward CN frames (type 10)
chan_sip fails to send those frames, and the RTP audio flow breaks
Important note:
Calls without CN work fine and have normal bidirectional audio
I would not expect that the lack of sending a CN upstream would cause the audio stream to break indefinitely. For receiving the other side doesn’t even know that we didn’t handle it. It’s up to them later to resume audio.
Aside from the log messages, what further investigation have you done? Have you looked at the underlying RTP streams?
Attached is an RTP/audio analysis of a call where the issue occurs.
In this capture:
The agent side becomes silent after CN (RFC 3389) appears.
The customer audio continues to work normally during the call.
The call remains connected, but the agent no longer receives audio.
When the agent hangs up, the post-call survey audio (playback) is reproduced normally, which indicates that:
Audio playback on the agent side still works
The issue is limited to the RTP audio stream during the call, not the audio device or channel itself
The RTP graph shows the moment where CN is introduced and, shortly after, the agent-side RTP audio stops, matching the following logs previously mentioned:
Log asterisk : In this case, we had a CN shipment, but it was a DTMF type C shipment.
Going back to my original statement though, CN is uncharted/barely implemented/not supported territory. Unless someone goes down the path of trying to fix it all up, that’s not going to change.
