Re: [AVTCORE] RFC4566 - understanding maxptime

Magnus Westerlund <> Mon, 26 January 2015 12:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 158961A8A59 for <>; Mon, 26 Jan 2015 04:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vn_YTqWna9_y for <>; Mon, 26 Jan 2015 04:35:52 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DC161A8A06 for <>; Mon, 26 Jan 2015 04:35:51 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-cb-54c634a58d00
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A3.96.24955.5A436C45; Mon, 26 Jan 2015 13:35:49 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 26 Jan 2015 13:35:49 +0100
Message-ID: <>
Date: Mon, 26 Jan 2015 13:35:44 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Harald Radke <>,
References: <trinity-db1651cc-9514-495d-b11b-281dc69b056c-1420467617692@3capp-gmx-bs11>
In-Reply-To: <trinity-db1651cc-9514-495d-b11b-281dc69b056c-1420467617692@3capp-gmx-bs11>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+Jvje5Sk2MhBnO2mFu87FnJbvHup7gD k8eHj3EeS5b8ZApgiuKySUnNySxLLdK3S+DKePr7HVPBS+mKv19XMDcwbhLrYuTgkBAwkWjZ GtjFyAlkiklcuLeeDcQWEjjCKDFvvkAXIxeQvZxR4s/vaWwg9bwC2hLd7QogNSwCqhIb5n5l BLHZBCwkbv5oBOsVFQiWWPz8KSuIzSsgKHFy5hMWEFtEwEhicsMsZhBbWMBcYtbeJrCRQgLh Evd/SoKEOQUiJA5dXQBWzixgIHFk0RxWCFteonnrbGaI07QlGpo6WCcwCsxCsmEWkpZZSFoW MDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgMxoNbfqvuYLz8xvEQowAHoxIP78a1R0OE WBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY/z13aUB+fZbL lda3E5ZEZXlM5EyKfpX2bcevTgXTcNc3MTq6D6Mq8qV/6hvuXP73J+eKVm2+uUclme9VGbGl 95a+uLzyZdgTy1k3Ti3I3LW25IfrzW9Cz1d3ijrWHnuiestdTEMnYG3A0d5VGdONXeyiXxq+ T/5aPmWvaPWMhVvX5UydM/G5EktxRqKhFnNRcSIA3ZfzwycCAAA=
Archived-At: <>
Subject: Re: [AVTCORE] RFC4566 - understanding maxptime
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jan 2015 12:35:54 -0000


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

On 2015-01-05 15:20, Harald Radke wrote:
> 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.

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.

> 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?)

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.

> 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?

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.


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: