Audio jitter/choppy echo when returning RTP audio via Channels in echo mode

[tlierdotfr]

Hi,

I'm experimenting with a simple SIP server using SIPSorcery 8.0, and I'm currently testing an echo mode to validate the audio path before implementing further audio processing.

The idea is straightforward:

I receive RTP packets from the SIP session (OnRtpPacketReceived handler).

Each packet’s payload (PCMU, 8 kHz, 160 bytes per frame) is written into a Channel<byte[]> for async handling.

A consumer task reads from that channel and sends the same payload back through _rtpSession.SendAudio().

When I inspect the recorded inbound/outbound audio (saved as raw µ-law files), playback in Audacity sounds perfect — so the chunks themselves are correct.

However, during a live SIP call (tested against a 3CX server), the return audio sounds choppy, with jitter and short dropouts.
There’s no transformation of the chunks (no transcoding, no conversion).
Each frame is sent as 160 bytes every ~20 ms, and timing is managed by the consumer task.

I’ve tried variants with and without Task.Delay(20), but adding a delay causes increasing latency, while removing it keeps the audio immediate but still glitchy.

So it looks like the RTP send timing might not be properly synchronized, or that the internal packet scheduling expects a different approach when streaming from custom queues.

Here’s a simplified overview of my pipeline (without any scheduling):

_rtpSession.OnRtpPacketReceived += OnAudioPacketReceived;

private async void OnAudioPacketReceived(IPEndPoint remoteEndPoint, SDPMediaTypesEnum mediaType, RTPPacket packet)
{
    if (mediaType == SDPMediaTypesEnum.audio && packet.Payload?.Length > 0)
        await _incomingFromSipQueue.Writer.WriteAsync(packet.Payload);
}

private async Task ConsumeIncomingFromSipAudio(CancellationToken token)
{
    while (!token.IsCancellationRequested)
    {
        var buffer = await _incomingFromSipQueue.Reader.ReadAsync(token);
        await _outgoingToSipQueue.Writer.WriteAsync(buffer);
    }
}

private async Task ConsumeOutgoingToSipAudio(CancellationToken token)
{
    while (!token.IsCancellationRequested)
    {
        var buffer = await _outgoingToSipQueue.Reader.ReadAsync(token);
        _rtpSession.SendAudio(160, buffer);
    }
}

Has anyone encountered this issue with SendAudio timing or echo loops using Channels?
Is there a recommended way to ensure smoother RTP scheduling when manually pushing audio frames like this?

Thanks in advance for any insights!

Thomas

[sipsorcery]

There should be no need for a Task.Delay anywhere. If you're triggering your audio send off the RTP packets they should be arriving with the correct spacing (ignoring any jitter, latency).

As a quick test to see if the audio corruption is being introduced by your pipeline can you do the send in the OnAudioPacketReceived method? E.g:

private async void OnAudioPacketReceived(IPEndPoint remoteEndPoint, SDPMediaTypesEnum mediaType, RTPPacket packet)
{
    if (mediaType == SDPMediaTypesEnum.audio && packet.Payload?.Length > 0)
   {
        //await _incomingFromSipQueue.Writer.WriteAsync(packet.Payload);
      _rtpSession.SendAudio(160, buffer);
   }
}

Other than that the main cause of corruption is the RTP timestamps somehow getting messed up. Check the RTP packets being sent to the 3CX server do have a difference of 160 between them.

[tlierdotfr]

Thanks for the quick reply!

I did the test exactly as you suggested — sending the audio directly inside OnAudioPacketReceived instead of using my Channels.
Here’s the updated method I tried:

private async void OnAudioPacketReceived(IPEndPoint remoteEndPoint, SDPMediaTypesEnum mediaType, RTPPacket packet)
{
    try
    {
        if (mediaType != SDPMediaTypesEnum.audio || packet?.Payload == null || packet.Payload.Length == 0)
            return;

        var ulawData = packet.Payload;
        _logger.LogInformation($"SipAudioBridge: Received {ulawData.Length} bytes.");
        _rtpSession.SendAudio(160, ulawData);
    }
    catch (Exception ex)
    {
        _logger.LogError(ex, $"OnAudioPacketReceived error: {ex.Message}");
    }
}

The logs confirmed that each packet received and sent is exactly 160 bytes, so the frame size seems correct for PCMU 8 kHz (20 ms per frame).

However, even in this simplified setup — where I just forward the incoming payloads directly back to _rtpSession.SendAudio() — the returned audio is still choppy, with small regular glitches/dropouts.

Since there’s no queueing, no buffering, and no Task.Delay, I’m struggling to understand where the problem comes from.

Do you have any idea what could cause this kind of short interruptions in the echo stream even when packets are sent back immediately upon reception?
Could it be related to how SendAudio() schedules timestamps or packet intervals internally?

Thanks again for your help