the RTP packge with audio media, which have random sending time interval

142 views
Skip to first unread message

hy tian

unread,
Mar 19, 2020, 6:39:07 AM3/19/20
to kurento

Please! My client browser has a constant time interval as 20ms, when it sending local media with RTP. I need a . So why the deference about KMS?
What should I do so that KMS can send RTP every 20ms?

hy tian

unread,
Mar 25, 2020, 1:41:08 AM3/25/20
to kurento
UP，help

在 2020年3月19日星期四 UTC+8下午6:39:07，hy tian写道：

Juan Navarro

unread,
Mar 26, 2020, 7:04:40 AM3/26/20
to kur...@googlegroups.com
On 19/3/20 11:39, hy tian wrote:
> I need a . So why the deference about KMS?

That phrase is missing some words. What do you need?

hy tian

unread,
Mar 30, 2020, 5:55:15 AM3/30/20
to kurento
Sorry. the KMS sending RTP package by inconstant time internal. But I need the time interval equals to 20ms constantly. the audio format is PCMA.

在 2020年3月26日星期四 UTC+8下午7:04:40，Juan Navarro写道：

FB K

unread,
Mar 24, 2021, 7:16:30 AM3/24/21
to kurento
Has the problem been solved?

Alexander Novikov

unread,
Mar 24, 2021, 7:49:32 AM3/24/21
to kur...@googlegroups.com
Why do you think it is a problem or a bug? No, Kurento does not need
to send them at equal time intervals. This is not possible anyway, and
because these are UDP datagrams, they will arrive at uneven intervals
anyway, if at all. A receiving client must manage this.
> --
> You received this message because you are subscribed to the Google Groups "kurento" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/93db5d43-2736-4e48-8e03-804a4b4de4e6n%40googlegroups.com.

498921507

unread,
Mar 24, 2021, 9:16:58 PM3/24/21
to kur...@googlegroups.com, kur...@googlegroups.com
Example1: client1->rtp1->rtp2->client2, when client1 send  the time interval equals to 20ms constantly,I set rtp2 payloader "max-ptime"and "min-ptime" to 20ms,client2 can receive  the time interval equals to 20ms constantly.

Example2: client1->rtp1->hubport1->compositor->hubport2->rtp2->client2,when client1 send  the time interval equals to 20ms constantly,compositor encode pcma stream,I set rtp2 payloader "max-ptime"and "min-ptime" to 20ms,client2  receive  inconstant time internal.

So I think it is a bug.
You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/gd9nzYTmy1A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kurento+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/CAH92vQK1a1SH21nTbGR%2B%3D38OHdyE6hgLJ%3DL1bRmkAV1zN2mUOQ%40mail.gmail.com.
c

Alexander Novikov

unread,
Mar 25, 2021, 2:31:36 AM3/25/21
to kur...@googlegroups.com
No it's not a bug, packets may arrive at uneven time intervals. It's ok. It's the goal of the client to reorder them and play out evenly, this is what jitter buffer is for.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/tencent_761E38B2930B1CDD351B2105DB55C3AD7D07%40qq.com.

Juan Navarro

unread,
Mar 25, 2021, 4:28:38 PM3/25/21
to kur...@googlegroups.com
On 25/03/2021 02.16, 498921507 wrote:
Example1: client1->rtp1->rtp2->client2, when client1 send  the time interval equals to 20ms constantly,I set rtp2 payloader "max-ptime"and "min-ptime" to 20ms,client2 can receive  the time interval equals to 20ms constantly.
This happens only because of sheer luck, very good network, or both. The RTP packets are sent with UDP, a protocol that doesn't guarantee ordering on reception. If you sent RTP packets 1, 2, 3 through internet from a large distance, they will probably arrive as 3, 1, 2, or some might even get lost, so maybe only 3, 2 arrive. Depends on the intermediate networks and how busy they are.



Example2: client1->rtp1->hubport1->compositor->hubport2->rtp2->client2,when client1 send  the time interval equals to 20ms constantly,compositor encode pcma stream,I set rtp2 payloader "max-ptime"and "min-ptime" to 20ms,client2  receive  inconstant time internal.

So I think it is a bug.

Unless the differences are huge, it is not a bug because there is a lot of processing going on there (audio decoding -> audio mixing -> audio encoding). However I cannot state 100% that the compositor doesn't have bugs... but small variations in timing are normal and expected.


Alexander Novikov

unread,
Mar 25, 2021, 5:15:48 PM3/25/21
to kur...@googlegroups.com
exactly. also, i wonder why OP is even concerned about it. ok they don’t arrive at constant intervals, why is this a problem? any valid webrtc client will handle it.

Sent from my iPhone

On Mar 25, 2021, at 10:28 PM, Juan Navarro <juan.n...@gmx.es> wrote:

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

498921507

unread,
Mar 25, 2021, 9:19:29 PM3/25/21
to kur...@googlegroups.com, kur...@googlegroups.com
In our environment,we mainly use RtpEndpoint device(telephone、camera and so on) in Local Area Network.   Packets don’t arrive at constant intervals(120ms send 6 rtp packets simultaneously)，Some of the RtpEndpoint device  think meida stream interrupt lead to drop call.I want to be compatible with these RtpEndpoint devices which is concerned about it.
You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/gd9nzYTmy1A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kurento+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/51C6BFBA-7631-40A5-B8B9-793CD5B04112%40gmail.com.

Juan Navarro

unread,
Mar 29, 2021, 8:48:17 AM3/29/21
to kur...@googlegroups.com
RTP allows irregular transmission times, out of order packets, and even losing some packets on their way. No RTP implementation should assume a disconnection because of just some milliseconds of variance...

RTP even allows that one participant stops sending data, but the "RTP Session" will still be alive, as long as there are RTCP messages flowing from time to time. Only when both RTP and RTCP are not sent for several seconds, the session can be considered disconnected.

But how much time is allowed?

Well, in https://tools.ietf.org/html/rfc3550#section-6.2 we see:

    The RECOMMENDED value for a fixed minimum
    interval is 5 seconds.

(it refers to the interval of RTCP packets)

And https://tools.ietf.org/html/rfc3550#section-6.2.1 says this:

    A participant MAY mark another site inactive, or delete it if not yet
    valid, if no RTP or RTCP packet has been received for a small number
    of RTCP report intervals (5 is RECOMMENDED).

So you see, in average, an RTP participant should not consider disconnection from other participants until after 5*5 = 25 seconds. This could be shorter, but always in the range of several seconds... never milliseconds. So those devices have some kind of problem, or maybe they just have a bad implementation of RTP.
Reply all
Reply to author
Forward
0 new messages