Cracking/Silence in streams

[Benjamin T.]

Hi,

I hope I'm on the right way...

I've been reported some crackling/silence in the beginning of a call through rtpengine.

As far as I can tell it might happen, when a second RTP-stream is reaching rtpengine, when a first stream is already running.

What I see is, that the timestamp filed in the rtp packets are ok at  first (always +160 on every packet with g722 codec)

But when a second stream comes in (inbound from caller), the timestamp of the first stream (outgoing music playing) doesn't get 160 added, but 1136 which is certainly not in common with the 160... so what happens here, when the second stream comes in? I suppose the high timestamp is the reason for noise/crackling/silence (depends on the end device) of the music, but I can't confirm that right now.

I know that there is the new "NAT-wait" parameter. Maybe I can use this to workaround that timing issue?

Thanks,

Benjamin

[Richard Fuchs]

The difference in timestamp should not matter because the packet has the marker bit set, which is usually used to resynchronise the RTP timer. (Even without the marker bit set this should not matter much.)

A bigger problem is probably two RTP streams arriving at the device at the same time.

Either way, I'm not sure what the expected behaviour of rtpengine here is though? It's primarily an RTP proxy and so it forwards whatever is sent to it. If there's two streams arriving at rtpengine then it will forward those two streams. Figuring out what to do in terms of playback of the RTP streams is left up to the device doing the actual playback. (Small caveat here in case transcoding is active of course, but you didn't mention that.)

The `NAT wait` flag almost certainly won't make a difference here.

Cheers

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/7f9a0f2b-228e-48dd-b498-e6fbb595c681n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin T.]

Hi Richard,

rtpengine is used as proxy or transcoding part (sometimes) here. But transcoding is not done in this example. 

So all in all, there is no chance of changing the rtpengine behaviour, because the endpoint might be the problem here. I can communicate that and check what can be done on client side.

Thanks!

[Richard Fuchs]

On 28/12/2021 08.45, [EXT] 'Benjamin T.' via rtpengine wrote:
> Hi Richard,
>
> rtpengine is used as proxy or transcoding part (sometimes) here. But
> transcoding is not done in this example.
> So all in all, there is no chance of changing the rtpengine behaviour,
> because the endpoint might be the problem here. I can communicate that
> and check what can be done on client side.
>

Well, I didn't say that there's no chance of changing anything :) but
merely that this is the default behaviour and it depends on what you
want to achieve and how, and also on the exact circumstances. If there's
just two streams being sent to rtpengine and there's no way to
distinguish them (other than the SSRC), then it will be difficult. If
this is a branched call or there's a re-invite or something, then it
might be possible to tell rtpengine to block one of the two streams. It
may also be possible to do this on a signalling (SIP) level by tearing
down a secondary call leg when needed, independent of what rtpengine is
doing.

Cheers