Re: [AVTCORE] RFC4566 - understanding maxptime

Alan Clark <> Mon, 05 January 2015 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AEEBD1A889A for <>; Mon, 5 Jan 2015 06:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uKLvwYUiOl2w for <>; Mon, 5 Jan 2015 06:40:52 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D7431A8897 for <>; Mon, 5 Jan 2015 06:40:52 -0800 (PST)
X-SBRS: -4.0
X-HAT: Sender Group POORREP_BLACKLIST, Policy $SBRSPOOR applied.
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,700,1413259200"; d="scan'208,217";a="151399961"
Received: from (HELO Alans-MacBook-Pro.local) ([]) by with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Jan 2015 09:40:51 -0500
Message-ID: <>
Date: Mon, 05 Jan 2015 09:40:50 -0500
From: Alan Clark <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.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: multipart/alternative; boundary="------------010407060203090601010701"
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, 05 Jan 2015 14:40:54 -0000

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.



On 1/5/15 9:20 AM, 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.
> 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
> _______________________________________________
> Audio/Video Transport Core Maintenance