Re: [AVT] Frame Interleaving in AMR profile->RFC 3267
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 24 July 2003 07:44 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27606 for <avt-archive@odin.ietf.org>; Thu, 24 Jul 2003 03:44:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19falL-0001qX-IF for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 03:43:43 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O7hhCa007096 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 03:43:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fakf-0001mQ-2o; Thu, 24 Jul 2003 03:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fakb-0001mF-GC for avt@optimus.ietf.org; Thu, 24 Jul 2003 03:42:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27548 for <avt@ietf.org>; Thu, 24 Jul 2003 03:42:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fakZ-00041E-00 for avt@ietf.org; Thu, 24 Jul 2003 03:42:55 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19fakO-00040w-00 for avt@ietf.org; Thu, 24 Jul 2003 03:42:44 -0400
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6O7g3G6020478; Thu, 24 Jul 2003 09:42:03 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366DSMC2; Thu, 24 Jul 2003 09:42:42 +0200
Message-ID: <3F1F8DCA.3030509@ericsson.com>
Date: Thu, 24 Jul 2003 09:42:02 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: B Prashanth <bprashanth@neomagic.com>
CC: avt <avt@ietf.org>
Subject: Re: [AVT] Frame Interleaving in AMR profile->RFC 3267
References: <3F1E9C47.6090304@neomagic.com>
In-Reply-To: <3F1E9C47.6090304@neomagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Hi, When it comes to meeting the limitations the sender side has the freedom to select any combination of ILL and number of frames that satisfies the restrictions. Another restriction then I that may be used is "maxptime" which puts a limit on the number of frames per packet. In your example with I=30 the sender has the choice to go from ILL=0 (No interleaving, with 30 frames in a single RTP packet, up to ILL=14 and only two frames per packet. It is assumed that the sender will use the combination most suitable for the current network performance and congestion state. There is no need for the payload format to put in more limitations. The RTP payload format has great flexibility and for any receiver implementing the interleaving mode can decode these payloads independent of which ratio between ILL and N that are used. The I restriction value is there to put a limit on buffering and interleaving induced delay. However using many AMR frames per packet is generally not a good idea. If one would use the 130 frames per packet that you calculate, I hope you are aware that this represent 2.6 seconds. That can be a whole sentence lost if this single packet is lost. So filling voice packet to the limit is not suitable in environments where losses occur. However if one has retransmission or uses a reliable channel more frames per packets may give satisfactory performance. My opinion is that more than 5-10 frames per packet is to much. And if one is going as high as 10 frames per packet one should definitely consider using interleaving with fairly decent length. [Chairs hat on] RFC 3267 is a payload format NOT a profile. A RTP profile is something else and must not be confused with payload formats. I have seen this mistake being done also by others. The current available profiles are RFC 1890 (AVP) or rather draft-ietf-avt-profile-new-13. Two new profiles are with the IESG, SRTP (SAVP) draft-ietf-avt-srtp-09 and Extended RTCP feedback (AVPF) draft-ietf-avt-rtcp-feedback-07. [chairs hat off] Best Regards Magnus B Prashanth wrote: > Dear All > The frame interleaving in the AMR profile (RFC 3267) states that > > " The sender of the payload MUST only apply interleaving if the > receiver has signalled its use through out-of-band means. Since > interleaving will increase buffering requirements at the receiver, > the receiver uses MIME parameter "interleaving=I" to set the maximum > number of frame-blocks allowed in an interleaving group to I. > > When performing interleaving the sender MUST use a proper number of > frame-blocks per payload (N) and ILL so that the resulting size of an > interleave group is less or equal to I, i.e., N*(L+1)<=I. " > > ILL is the interleaving Length i.e. number of RTP packets across which > interleaving happens. > NOTE: The value of ILL starts from 0. Hence, one needs to do ILL +1 in > the above formula. > > Nmax, the maximum value N (number of frame-blocks per payload) can take, > is calculated by the formula -> > Nmax = (RTP MTU SIZE)/(The frame size of a frame block) > > Assuming, > > RTP MTU SIZE = 1500 bytes, and > The frame size of a AMR frame block = 13 octets for AMR frame type=0 > > The above assumption gives: > Nmax = 1500/13 = 115 packets. > > The information obtained from out-of-band means, say, SDP is > "interleaving=30", which means that an interleaving group can have a > maximum of 30 frames per group such that: > (ILL+1) * N less than or equal to I > where N varies from 0<N<Nmax. > ILL is the interleaving Length i.e. number of RTP > packets across which interleaving happens. > > Now, in the case taken by me above, Nmax > I (i.e. 115>30). So, the > condition (ILL+1)*N less than or equal to I with N=Nmax doesn't hold good. > > So, how does one select the value of N and ILL such that it is less than > I, in the above case? > > Right now, I can think of only one option of handling this: > My option: Assume the minimum value of ILL, say 1. A value of 2 makes > sense because one needs at least 2 RTP packets to do interleaving. Based > on this value calculate N > N = (30/2)-1 > N = 14 > With this value of N we satisfy both the conditions, namely, > (ILL+1) * N less than or equal to I -> (2+1) > and > N varies from 0<N<Nmax. > > I wanted to ask the others on this list whether this solution is the > only solution? Or there are other ways of handling this? > Shouldn't the values of N and ILL be very apparent rather than AMR > profile designer making such assumptions about it? > > -- > Prashanth B.P. > Sr. Design Engr. > NeoMagic Design Center. > Polyplex Building, First Floor > B-37 Sector 1 > Noida > INDIA 201301 > E-Mail: bprashanth@neomagic.com > Tel: +91-120-2536208 > Fax: +91-120-2536207 > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] Frame Interleaving in AMR profile->RFC 3267 B Prashanth
- Re: [AVT] Frame Interleaving in AMR profile->RFC … Magnus Westerlund
- Re: [AVT] Frame Interleaving in AMR profile->RFC … B Prashanth