Subject: [AVTCORE] RFC4566 - understanding maxptime

From: "Harald Radke" <[email-masked]>
Date: Mon, 5 Jan 2015 15:20:17 +0100

Hi all,

I have slight troubles to understand the RFC4566 definition of the maxptime attribute

(if this mailing list is not the right place to ask questions to understand RFCs, just to discuss them, I  am sorry, just tell me and I wont bother you any further).

RFC4566 states:

a=maxptime:<maximum packet time>

This gives the maximum amount of media that can be encapsulated

in each packet, expressed as time in milliseconds. The time

SHALL be calculated as the sum of the time the media present in

the packet represents. [...]

1) I kinda get the first sentence, but what does that second sentence actually mean? I kinda have problems understanding the SUM

statement. Does that "only" mean that in case of multiple frames in one packet that all frame durations are summed up? I wonder because the ptime definition does not contain a similar statement.

2) Actually somebody already asked a similar question some time (actually years) ago, actually the difference between ptime and maxptime, the answer was:

>The "a=ptime:" attribute is a hint to the encoder on the preferred packetisation interval for the media. The encoder may follow the hint, or it may vary the packetisation >interval up to the value indicated by "a=maxptime:". The receiver is expected to be able to decode any reasonable packetisation.

a)is the receiver expected to decode ANY packetisation? (e.g. ptime=20, maxptime=40 -> incoming RTP packets of the stream might contain payloads worth of any length between 20 and 40ms, in case of sample based codecs with sample duration granularity?)

b) must the receiver be able to handle varying packetisation during a session? that is receiving RTP packets with different payload lengths and different interarrival times or does "vary" just mean  that the sender "selects" one packetisation interval between ptime and maxptime at the beginningbut keeps it constant during the session?

Thank you very much and regards,

Harry

---

From: Alan Clark <[email-masked]>
Date: Mon, 05 Jan 2015 09:40:50 -0500

Hi Harry

We have definitely seen implementations in the field that dynamically 
varied the media time encoded within an RTP packet during a single 
session and the associate inter-arrival times; we've also built systems 
that do this for network test purposes.

One example we saw in a mobile network varied the number of 10ms encoded 
voice frames that were contained within a single RTP packet to between 1 
and 4.  I don't recall the SDP that was used to negotiate this however 
the receiver had to process variable duration frames.

Regards

Alan

On 1/5/15 9:20 AM, Harald Radke wrote:
> (if this mailing list is not the right place to ask questions to 
> understand RFCs, just to discuss them, I  am sorry, just tell me and I 
> wont bother you any further).
> RFC4566 states:
> 1) I kinda get the first sentence, but what does that second sentence 
> actually mean? I kinda have problems understanding the SUM
> statement. Does that "only" mean that in case of multiple frames in 
> one packet that all frame durations are summed up? I wonder because 
> the ptime definition does not contain a similar statement.
> 2) Actually somebody already asked a similar question some time 
> (actually years) ago, actually the difference between ptime and 
> maxptime, the answer was:
> >The "a=ptime:" attribute is a hint to the encoder on the preferred 
> packetisation interval for the media. The encoder may follow the hint, 
> or it may vary the packetisation >interval up to the value indicated 
> by "a=maxptime:". The receiver is expected to be able to decode any 
> reasonable packetisation.
> a)is the receiver expected to decode ANY packetisation? (e.g. 
> ptime=20, maxptime=40 -> incoming RTP packets of the stream might 
> contain payloads worth of any length between 20 and 40ms, in case of 
> sample based codecs with sample duration granularity?)
> b) must the receiver be able to handle varying packetisation during a 
> session? that is receiving RTP packets with different payload lengths 
> and different interarrival times or does "vary" just mean  that the 
> sender "selects" one packetisation interval between ptime and maxptime 
> at the beginningbut keeps it constant during the session?
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Simon Perreault <[email-masked]>
Date: Mon, 5 Jan 2015 10:05:52 -0500

On Mon, Jan 5, 2015 at 9:20 AM, Harald Radke <[email-masked]> wrote:

> 2) Actually somebody already asked a similar question some time (actually
> years) ago, actually the difference between ptime and maxptime, the answer
> was:
>
> packetisation interval for the media. The encoder may follow the hint, or
> it may vary the packetisation >interval up to the value indicated by
> "a=maxptime:". The receiver is expected to be able to decode any reasonable
> packetisation.
>
> a)is the receiver expected to decode ANY packetisation? (e.g. ptime=20,
> maxptime=40 -> incoming RTP packets of the stream might contain payloads
> worth of any length between 20 and 40ms, in case of sample based codecs
> with sample duration granularity?)
>
> session? that is receiving RTP packets with different payload lengths and
> different interarrival times or does "vary" just mean  that the sender
> "selects" one packetisation interval between ptime and maxptime at the
> beginningbut keeps it constant during the session?
>

My own policy regarding this is:

- I will not spend any effort dealing with crazy ptime bullshit (e.g., 21).
If the codec implementation I use works on byte boundaries, you're lucky,
but if it works on e.g. 10ms blocks then just too bad.
- Other than that, I don't really care about ptime. It all just goes into
one big queue. So you can vary ptimes as much as you like, you can ignore
my SDP, etc. Just don't go crazy.

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2015 13:35:44 +0100

Hi,

I think I can provide some explanation as the one that actually wrote
this originally

On 2015-01-05 15:20, Harald Radke wrote:
> statement. Does that "only" mean that in case of multiple frames in one
> packet that all frame durations are summed up? I wonder because the
> ptime definition does not contain a similar statement.

The second part is there to deal with the cases when an RTP payload
contains multiple frames, for example AMR frames that has a duration of
20 ms. But, as the AMR RTP payload format supports Interleaving also,
the maxptime is the amount of audio frames actually contained in payload
rather than the duration between the oldest and newest media present. So
maxptime=100 allows for 5 AMR audio frames, independent of how far
between they are interleaved.

> or it may vary the packetisation >interval up to the value indicated by
> "a=maxptime:". The receiver is expected to be able to decode any

With the most liberal interpretation the answer is yes. But, in practice
I think reasonable number of samples is expected. Unfortunately there
are no defined list of these lengths to my knowledge.

> at the beginningbut keeps it constant during the session?

Yes, the amount of media in the different RTP payloads are expected to
be changed during the RTP session. This to deal with changing latency,
available bandwidth and other changes during the duration of the session.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------