From mailnull@www1.ietf.org Sat Feb 1 02:36:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10518 for ; Sat, 1 Feb 2003 02:36:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h117edT25833 for avt-archive@odin.ietf.org; Sat, 1 Feb 2003 02:40:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h117dHJ25776; Sat, 1 Feb 2003 02:39:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h117bRJ25540 for ; Sat, 1 Feb 2003 02:37:27 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10436 for ; Sat, 1 Feb 2003 02:33:03 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h117aWXj021408; Fri, 31 Jan 2003 23:36:33 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 31 Jan 2003 23:54:47 -0800 (PST) From: Stephen Casner To: Pekka Pessi cc: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: Message-ID: <20030131110619.H4145-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Wed, 15 Jan 2003, Pekka Pessi wrote: > What is the difference between an RTP cloud (a la section 7) and > an RTP session? An RTP cloud is a portion of an RTP session. As section 7 says, typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port or a pair of unicast addresses and ports. In other words, the clouds are separated from each other by being on different networks or using different transport protocols or addresses. The translator or mixer joins together the clouds into one RTP session by being connected to each cloud. > > RTP session: An association among a set of participants > > communicating with RTP. A participant may be involved in > > multiple RTP sessions at the same time. In a multimedia > > session, each medium is carried in a separate RTP session > > with its own RTCP packets. A participant distinguishes > > multiple RTP sessions by reception of different sessions > > using different pairs of destination transport addresses, > > where a pair of transport addresses comprises one network > > address plus a pair of ports for RTP and RTCP. > > Don't we have multiple mediums in a single RTP session, for > example, with some MPEG4 packetization? So, s/medium/RTP media > type/, or is it then a circular definition? Well, yes. How about: In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the encoding itself multiplexes multiple media into a single data stream. > > All participants in an RTP session may share a common > > destination transport address pair, as in the case of > > IP multicast, or the pairs may be different for each > > participant, as in the case of individual unicast > > network addresses and port pairs. In the unicast > > case, a participant may receive from all other > > participants using the same pair of ports, or may use > > a distinct pair of ports for each. > > I'd drop this text away, as a RTP session can consist of two > multicast group connected via a translator or a mixer. I don't think it is sufficient to just drop this text. I could add a sentence to say that the addressing situation may be more complicated with translators and mixers in section 7. > I also think translators and mixers that forward CSRCs and SDESs > should be mentioned in the definition. A simple mention is appropriate, but I think any discussion is better deferred to section 7. I think the handling of CSRCs and SDESs is specified clearly there. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Feb 1 20:53:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18880 for ; Sat, 1 Feb 2003 20:53:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h121vLP18513 for avt-archive@odin.ietf.org; Sat, 1 Feb 2003 20:57:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h121uQJ18483; Sat, 1 Feb 2003 20:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h118oDJ28553 for ; Sat, 1 Feb 2003 03:50:13 -0500 Received: from prologixsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01414 for ; Sat, 1 Feb 2003 03:45:46 -0500 (EST) Received: from sudhir [61.0.114.206] by prologixsoft.com with ESMTP (SMTPD32-7.05) id ABA66D40134; Sat, 01 Feb 2003 14:26:06 +0530 Message-ID: <000d01c2c9ce$b0c4f920$280aa8c0@sudhir> Reply-To: "Sudhir Sharma" From: "Sudhir Sharma" To: Date: Sat, 1 Feb 2003 14:18:22 +0530 Organization: Prologix MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [AVT] RTP Payload Format 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I want to create test programs for dtmf generation and also a program to read dtmf from rtp according to this rfc rfc2833 . Can anyone please tell me some link where i can get sample program or help regarding this. I will really appreciate your quick reply. Thanx and Regards sudhir _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 05:08:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01874 for ; Mon, 3 Feb 2003 05:08:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13ADBl08136 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 05:13:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ABoJ08080; Mon, 3 Feb 2003 05:11:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13A8pJ07952 for ; Mon, 3 Feb 2003 05:08:51 -0500 Received: from exchange.Ic4ic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01827; Mon, 3 Feb 2003 05:03:23 -0500 (EST) Received: through eSafe SMTP Relay 1040832187; Mon Feb 03 13:05:02 2003 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CB6C.059DEC9C" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 3 Feb 2003 12:07:13 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D47E929@exchange.Ic4ic.com> Thread-Topic: TCRTP, L2TPHC and L2TPoAAL5 Thread-Index: AcLLbAWHnYONHmggTjCwQPeJiIUPyw== From: "Daniel Feldman" To: "Tmima Koren (E-mail)" , , , Cc: , Subject: [AVT] TCRTP, L2TPHC and L2TPoAAL5 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CB6C.059DEC9C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson, Section 3.3.2 of the current TCRTP draft has a bandwidth comparison table, including TCRTP over PPP and TCRTP over AAL5. From the text I understand that: a) TCRTP over PPP includes Header Compression only once, so the IP header (20 bytes) is not compressed. This could be reduced by using the COMPRESSED_NON_TCP format described in RFC2507 below the L2TPHC tunnel. b) TCRTP over AAL5 includes a 20-bytes IP header which could be reduced to zero, if L2TPHC worked straight over AAL5. =20 My questions are: 1) Can we add the scenario described in (a) to the TCRTP draft? 2) Is it possible to extend L2TPHC so it is compatible with L2TPoAAL5 (RFC3355)? 3) Can we add this scenario to the TCRTP draft? =20 Thanks in advance and regards, =20 Daniel Feldman. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Architecture Group Manager, IC4IC Ltd. office: +972 (4) 959-4644 ext. 121 mobile: +972 (55) 99-0299 fax: +972 (4) 959-4944 web: http://www.ic4ic.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20 =20 ------_=_NextPart_001_01C2CB6C.059DEC9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 &= nbsp; =20 Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson,
    Section 3.3.2 of the current TCRTP draft has a bandwidth compari= son=20 table, including TCRTP over PPP and TCRTP over AAL5.
    From the text I understand that:
a) TCRT= P over PPP=20 includes Header Compression only once, so the IP header (20 bytes) is not= =20 compressed. This could be reduced by using the COMPRESSED_NON_TCP format=20 described in RFC2507 below the L2TPHC tunnel.
b) TCRT= P over AAL5=20 includes a 20-bytes IP header which could be reduced to zero, if L2TPHC w= orked=20 straight over AAL5.
 
    My questions are:
1) Can = we add the=20 scenario described in (a) to the TCRTP draft?
2) Is i= t possible to=20 extend L2TPHC so it is compatible with L2TPoAAL5 (RFC3355)?=
3) Can = we add this=20 scenario to the TCRTP draft?
 
    Thanks in advance and regards,
 
      = ; =20 Daniel Feldman.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman<= BR>System=20 Architecture Group Manager, IC4IC Ltd.
office: +972 (4) 959-4644 ext.=20 121
mobile: +972 (55) 99-0299
fax:    +972 (4)=20 959-4944
web:     http://www.ic4ic.com
~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~=20
 
------_=_NextPart_001_01C2CB6C.059DEC9C-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 05:27:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02147 for ; Mon, 3 Feb 2003 05:27:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13AW4x09121 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 05:32:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AQCJ08902; Mon, 3 Feb 2003 05:26:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13APVJ08827 for ; Mon, 3 Feb 2003 05:25:31 -0500 Received: from mail.fastweb.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02093 for ; Mon, 3 Feb 2003 05:20:04 -0500 (EST) Received: by MARGOT with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 11:23:39 +0100 Message-ID: <90F3FE1EF972EE4495D6E360A6CD0115170A1C@FWMIMX3.fastwebit.ofc> From: Fiandra Riccardo To: AVT WG Date: Mon, 3 Feb 2003 11:23:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RTCP unicast feedback for measurement applications? 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Gents, I was interested in the "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" draft. Actually, I was wondering if it is also targeted to have a very large and distribuited network measurement framework. Where multicast receivers (thousands) use RTCP to send report to a measurement collector about packet loss, jitter, or other. I see really many advantages on that for e2e measurements, especially in a scenario where thousands of receivers are always connected to the network and cannot send multicast (common scenario for an operator, even without SSM...). My questions are: -Was this a scenario of application when writing the draft? -In this case, could I use the RTCP channel multicasted to the receivers to control them? -Do you see any extension possible also for ptp rtp connections (forward rtcp reports to another device?) Tanx in advance for any feedback Riccardo _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 06:46:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03701 for ; Mon, 3 Feb 2003 06:46:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13BovY14310 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 06:50:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BoTJ14270; Mon, 3 Feb 2003 06:50:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Bn6J14182 for ; Mon, 3 Feb 2003 06:49:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03283; Mon, 3 Feb 2003 06:43:39 -0500 (EST) Message-Id: <200302031143.GAA03283@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 03 Feb 2003 06:43:38 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-crtp-enhance-06.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Compressing IP/UDP/RTP headers on links with high delay,packet loss and reordering Author(s) : T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy Filename : draft-ietf-avt-crtp-enhance-06.txt Pages : 0 Date : 2003-1-31 This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-crtp-enhance-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-enhance-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-31142740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-enhance-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-enhance-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31142740.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 09:19:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08248 for ; Mon, 3 Feb 2003 09:19:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13EOlh24890 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 09:24:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13EO0J24830; Mon, 3 Feb 2003 09:24:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ELaJ24680 for ; Mon, 3 Feb 2003 09:21:36 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08175 for ; Mon, 3 Feb 2003 09:16:05 -0500 (EST) Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1590760; Mon, 03 Feb 2003 09:18:30 -0500 Date: Mon, 3 Feb 2003 09:18:15 -0500 Subject: Re: [AVT] RTCP unicast feedback for measurement applications? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: AVT WG To: Fiandra Riccardo From: Marshall Eubanks In-Reply-To: <90F3FE1EF972EE4495D6E360A6CD0115170A1C@FWMIMX3.fastwebit.ofc> Message-Id: <5606DAC2-3782-11D7-B932-003065BA697E@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello; I see no reason why you could not use unicast RTCP for measurement applications - we do this already with our prototype unicast RTCP - the NLANR multicast beacon uses unicast reports (although not rtcp, alas) to respond back to the beacon server, which is how http://beaconserver.accessgrid.org:9999/ gets generated. On Monday, February 3, 2003, at 05:23 AM, Fiandra Riccardo wrote: > Gents, > I was interested in the "RTCP Extensions for Single-Source Multicast > Sessions with Unicast Feedback" draft. > Actually, I was wondering if it is also targeted to have a very large > and > distribuited network measurement framework. > Where multicast receivers (thousands) use RTCP to send report to a > measurement collector about packet loss, jitter, or other. > I see really many advantages on that for e2e measurements, especially > in a > scenario where thousands of receivers are always connected to the > network > and cannot send multicast (common scenario for an operator, even without > SSM...). > > My questions are: > -Was this a scenario of application when writing the draft? It was in my mind when reviewing it. In any case, Internet protocols are not restricted to uses thought of in advance ! > -In this case, could I use the RTCP channel multicasted to the > receivers to > control them? Why not ? > -Do you see any extension possible also for ptp rtp connections (forward > rtcp reports to another device?) > The danger here is denial of service attacks (if you are sending 50 mbps of reports to somewhere, and I can re-direct this to point somewhere else, we have a big DOS problem). > Tanx in advance for any feedback > > Riccardo > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 09:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08382 for ; Mon, 3 Feb 2003 09:24:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13ETiQ25162 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 09:29:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ES9J25069; Mon, 3 Feb 2003 09:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ERJJ25035 for ; Mon, 3 Feb 2003 09:27:19 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08288 for ; Mon, 3 Feb 2003 09:21:47 -0500 (EST) Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1590767; Mon, 03 Feb 2003 09:25:11 -0500 Date: Mon, 3 Feb 2003 09:18:15 -0500 Subject: Re: [AVT] RTCP unicast feedback for measurement applications? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: AVT WG To: Fiandra Riccardo From: Marshall Eubanks In-Reply-To: <90F3FE1EF972EE4495D6E360A6CD0115170A1C@FWMIMX3.fastwebit.ofc> Message-Id: <5606DAC2-3782-11D7-B932-003065BA697E@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello; I see no reason why you could not use unicast RTCP for measurement applications - we do this already with our prototype unicast RTCP - the NLANR multicast beacon uses unicast reports (although not rtcp, alas) to respond back to the beacon server, which is how http://beaconserver.accessgrid.org:9999/ gets generated. On Monday, February 3, 2003, at 05:23 AM, Fiandra Riccardo wrote: > Gents, > I was interested in the "RTCP Extensions for Single-Source Multicast > Sessions with Unicast Feedback" draft. > Actually, I was wondering if it is also targeted to have a very large > and > distribuited network measurement framework. > Where multicast receivers (thousands) use RTCP to send report to a > measurement collector about packet loss, jitter, or other. > I see really many advantages on that for e2e measurements, especially > in a > scenario where thousands of receivers are always connected to the > network > and cannot send multicast (common scenario for an operator, even without > SSM...). > > My questions are: > -Was this a scenario of application when writing the draft? It was in my mind when reviewing it. In any case, Internet protocols are not restricted to uses thought of in advance ! > -In this case, could I use the RTCP channel multicasted to the > receivers to > control them? Why not ? > -Do you see any extension possible also for ptp rtp connections (forward > rtcp reports to another device?) > The danger here is denial of service attacks (if you are sending 50 mbps of reports to somewhere, and I can re-direct this to point somewhere else, we have a big DOS problem). > Tanx in advance for any feedback > > Riccardo > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 3 20:01:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26379 for ; Mon, 3 Feb 2003 20:01:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1416w306444 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 20:06:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14163J06423; Mon, 3 Feb 2003 20:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1414VJ06377 for ; Mon, 3 Feb 2003 20:04:31 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26326 for ; Mon, 3 Feb 2003 19:58:47 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B32601E056; Mon, 3 Feb 2003 20:02:23 -0500 (EST) Received: from research.att.com (chopin.attlabs.att.com [135.197.15.62]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA16218; Mon, 3 Feb 2003 20:02:21 -0500 (EST) Message-ID: <3E3F111D.F28DE55B@research.att.com> Date: Mon, 03 Feb 2003 17:02:21 -0800 From: Eve Schooler X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: riccardo.fiandra@fastweb.it Cc: Eve Schooler , Julian Chesterfield , Joerg Ott , avt@ietf.org Subject: Re: [AVT] RTCP unicast feedback for measurement applications? Content-Type: text/plain; charset=us-ascii 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Fiandra Riccardo wrote: >I was interested in the "RTCP Extensions for Single-Source Multicast >Sessions with Unicast Feedback" draft. >Actually, I was wondering if it is also targeted to have a very large and >distribuited network measurement framework. >Where multicast receivers (thousands) use RTCP to send report to a >measurement collector about packet loss, jitter, or other. >I see really many advantages on that for e2e measurements, especially in a >scenario where thousands of receivers are always connected to the network >and cannot send multicast (common scenario for an operator, even without >SSM...). > >My questions are: >-Was this a scenario of application when writing the draft? Absolutely, though the primary focus of the draft was to solve the problem posed by the removal/restriction of the backchannel caused by SSM and other uni-directional or asymmetric topologies. Solving the feedback problem for SSM gives us the blueprint for other unicast-based feedback architectures, including ones for network measurement in general. >-In this case, could I use the RTCP channel multicasted to the receivers to >control them? Yes you could. This is certainly what we envision in the RTCP context; use the multicast channel in the source-to-receiver direction, and use the unicast backchannels in the receiver-to-source direction. We also propose to use the multicast channel either: - to reflect receiver feedback (received on the unicast backchannels) back out on the multicast channel to reach all receivers, or - to redistribute to the receivers feedback summaries (receiver feedback collected at the source and aggregated into a single mathematical distribution) back out on the multicast channel. >-Do you see any extension possible also for ptp rtp connections (forward >rtcp reports to another device?) In section 10 of draft-ietf-avt-rtcpssm-02.txt, we use an extension to SDP to indicate the device to which the feedback gets reported. This is done following the proposal for SDP source filters documented in draft-ietf-mmusic-sdp-srcfilter-00.txt. We also just completed a paper that expands upon the ideas in the I-D and that should provide further application scenarios. I'll post it here shortly. Eve -=-=-=-=- Eve M. Schooler Voice: 1-650-330-7913 AT&T Labs - Research FAX: 1-650-463-7037 75 Willow Road E-mail: schooler@research.att.com Menlo Park, CA, USA 94025 http://www.research.att.com/~schooler _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 4 10:18:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24764 for ; Tue, 4 Feb 2003 10:18:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14FNaK01004 for avt-archive@odin.ietf.org; Tue, 4 Feb 2003 10:23:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FMcJ00904; Tue, 4 Feb 2003 10:22:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149lJJ12537 for ; Tue, 4 Feb 2003 04:47:19 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14623 for ; Tue, 4 Feb 2003 04:41:17 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0H9S00M5X318JU@panasonic.de> for avt@ietf.org; Tue, 4 Feb 2003 10:44:03 +0100 (MET) Date: Tue, 04 Feb 2003 10:43:57 +0100 From: Jose Rey To: "Avt@Ietf. Org" Cc: "Akihiro@Isl. Mei. Co. Jp" , Rolf Hakenberg , David Leon , Magnus Westerlund , Go Hori Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_/uxOfmE+gFrceUnEsPws3w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [AVT] draft-ietf-avt-rtp-retransmission-05.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , [ Mail was delivered through VPN PEL->MEI/AVCDC! ] This is a multi-part message in MIME format. --Boundary_(ID_/uxOfmE+gFrceUnEsPws3w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Hi all, attached the latest revision of the retransmission draft. We feel it is ready for WGLC and would like to ask for your comments. This is the list of changes since version -04: a) s.3: 1st paragragh. Applicability of the retransmission payload format (Colin's comment) b) s.3.1: last paragraph (no SSRC-mux if multicast rtx, Colin's comment, solved on the list) c) s.4: 5th paragraph starting from the end. In section 4, two main changes/additions: possibility to retransmit at a lower rate and clarification of headers ordering (Colin's comment, the latter); plus one minor thing: clarification of SSRC collision handling by the sender. d) s.5.3: last paragraph but one e) s.6.1: new, to separate sender and receiver RTCP. f) s.10.2: implementation examples. Clarified. g) s.11 MIME registration reorganised. h) s.12: the retransmission payload format cannot be used under SAVP. Reference to SAVP removed, as concluded on the list. I think that's it. cheers, José --Boundary_(ID_/uxOfmE+gFrceUnEsPws3w) Content-type: text/plain; CHARSET=ISO-8859-1; name=draft-ietf-avt-rtp-retransmission-05.txt Content-disposition: attachment; filename=draft-ietf-avt-rtp-retransmission-05.txt Content-Transfer-Encoding: 7BIT Internet Draft draft-ietf-avt-rtp-retransmission-05.txt J. Rey/Matsushita D. Leon/Nokia A. Miyazaki/Matsushita V. Varsa/Nokia R. Hakenberg/Matsushita Expires: August 2003 February 2003 RTP Retransmission Payload Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. [Note to RFC Editor: This paragraph is to be deleted when this draft is published as an RFC. References in this draft to RFC XXXX should be replaced with the RFC number assigned to this document.] Abstract RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP IETF draft - Expires August 2003 [Page 1] Internet Draft RTP Retransmission Payload Format February 2003 feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF), is available in this memo. Table of Contents 1. Introduction....................................................3 2. Terminology.....................................................3 3. Requirements and design rationale for a retransmission scheme...4 4. Retransmission payload format...................................6 5. Association of a retransmission stream with its original stream.8 6. Use with the extended RTP profile for RTCP-based feedback......10 7. Congestion control.............................................12 8. Retransmission Payload Format MIME type registration...........13 9. RTSP considerations............................................19 10. Implementation examples.......................................20 11. IANA considerations...........................................23 12. Security considerations.......................................23 13. Acknowledgements..............................................24 14. References....................................................24 Author's Addresses................................................25 Rey, et al. [Page 2] Internet Draft RTP Retransmission Payload Format February 2003 1. Introduction Packet losses between an RTP sender and receiver may significantly degrade the quality of the received media. Several techniques, such as forward error correction (FEC), retransmissions or interleaving may be considered to increase packet loss resiliency. RFC 2354 [8] discusses the different options. When choosing a repair technique for a particular application, the tolerable latency of the application has to be taken into account. In the case of multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds in order to guarantee interactivity, which usually excludes the use of retransmission. However, in the case of multimedia streaming, the user can tolerate an initial latency as part of the session set-up and thus an end-to- end delay of several seconds may be acceptable. Retransmission may thus be considered for such applications. This document specifies a retransmission method for RTP applicable to unicast and (small) multicast groups: it defines a payload format for retransmitted RTP packets and provides protocol rules for the sender and the receiver involved in retransmissions. Furthermore, this retransmission payload format was designed for use with the extended RTP profile for RTCP-based feedback, AVPF [1]. It may also be used with other RTP profiles defined in the future. The AVPF profile allows for more frequent feedback and for early feedback. It defines a small number of general-purpose feedback messages, e.g. ACKs and NACKs, as well as codec and application- specific feedback messages. See [1] for details. 2. Terminology The following terms are used in this document: Original packet: refers to an RTP packet which carries user data sent for the first time by an RTP sender. Original stream: refers to the RTP stream of original packets. Retransmission packet: refers to an RTP packet which is to be used by the receiver instead of a lost original packet. Such a retransmission packet is said to be associated with the original RTP packet. Retransmission request: a means by which an RTP receiver is able to request that the RTP sender should send a retransmission packet for a given original packet. Usually, an RTCP NACK packet as specified in [1] is used as retransmission request for lost packets. Rey, et al. [Page 3] Internet Draft RTP Retransmission Payload Format February 2003 Retransmission stream: the stream of retransmission packets associated with an original stream. Session-multiplexing: scheme by which the original stream and the associated retransmission stream are sent into two different RTP sessions. SSRC-multiplexing: scheme by which the original stream and the retransmission stream are sent in the same RTP session with different SSRC values. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 3. Requirements and design rationale for a retransmission scheme The use of retransmissions in RTP as a repair method for streaming media is appropriate in those scenarios with relaxed delay bounds and where full reliability is not a requirement. More specifically, RTP retransmission allows to trade-off reliability vs. delay, i.e. the endpoints may give up retransmitting a lost packet after a given buffering time has elapsed. Unlike TCP there is thus no head-of- line blocking caused by RTP retransmissions. The implementer should be aware that in cases where full reliability is required or higher delay and jitter can be tolerated, TCP or other transport options should be considered. The RTP retransmission scheme defined in this document is designed to fulfil the following set of requirements: 1. It must not break general RTP and RTCP mechanisms. 2. It must be suitable for unicast and small multicast groups. 3. It must work with mixers and translators. 4. It must work with all known payload types. 5. It must not prevent the use of multiple payload types in a session. 6. In order to support the largest variety of payload formats, the RTP receiver must be able to derive how many and which RTP packets were lost as a result of a gap in received RTP sequence numbers. This requirement is referred to as sequence number preservation. Without such a requirement, it would be impossible to use retransmission with payload formats, such as conversational text [9] or most audio/video streaming applications, that use the RTP sequence number to detect lost packets. When designing a solution for RTP retransmission, several approaches may be considered for the multiplexing of the original RTP packets and the retransmitted RTP packets. Rey, et al. [Page 4] Internet Draft RTP Retransmission Payload Format February 2003 One approach may be to retransmit the RTP packet with its original sequence number and send original and retransmission packets in the same RTP stream. The retransmission packet would then be identical to the original RTP packet, i.e. the same header (and thus same sequence number) and the same payload. However, such an approach is not acceptable because it would corrupt the RTCP statistics. As a consequence, requirement 1 would not be met. Correct RTCP statistics require that for every RTP packet within the RTP stream, the sequence number be increased by one. Another approach may be to multiplex original RTP packets and retransmission packets in the same RTP stream using different payload type values. With such an approach, the original packets and the retransmission packets would share the same sequence number space. As a result, the RTP receiver would not be able to infer how many and which original packets (which sequence numbers) were lost. In other words, this approach does not satisfy the sequence number preservation requirement (requirement 6). This in turn implies that requirement 4 would not be met. Interoperability with mixers and translators would also be more difficult if they did not understand this new retransmission payload type in a sender RTP stream. For these reasons, a solution based on payload type multiplexing of original packets and retransmission packets in the same RTP stream is excluded. Finally, the original and retransmission packets may be sent in two separate streams. These two streams may be multiplexed either by sending them in two different sessions , i.e. session-multiplexing, or in the same session using different SSRC values, i.e. SSRC- multiplexing. Since original and retransmission packets carry media of the same type, the objections in Section 5.2 of RTP [3] to RTP multiplexing do not apply in this case. Mixers and translators may process the original stream and simply discard the retransmission stream if they are unable to utilise it. Using two separate streams thus satisfies all the requirements listed in this section. 3.1 Multiplexing scheme choice Session-multiplexing and SSRC-multiplexing have different pros and cons: Session-multiplexing is based on sending the retransmission stream in a different RTP session (as defined in RTP [3]) from that of the original stream, i.e. the original and retransmission streams are sent to different network addresses and/or port numbers. Having a separate session allows more flexibility. In multicast, using two separate sessions for the original and the retransmission streams allows a receiver to choose whether or not to subscribe to the RTP session carrying the retransmission stream. The original session may also be single-source multicast while separate unicast sessions Rey, et al. [Page 5] Internet Draft RTP Retransmission Payload Format February 2003 are used to convey retransmissions to each of the receivers, which as a result will receive only the retransmission packets they request. The use of separate sessions also facilitates differential treatment by the network and may simplify processing in mixers, translators and packet caches. With SSRC-multiplexing, a single session is needed for the original and the retransmission stream. This allows streaming servers and middleware which are involved in a high number of concurrent sessions to minimise their port usage. This retransmission payload format allows both session-multiplexing and SSRC-multiplexing for unicast sessions. From an implementation point of view, there is little difference between the two approaches. Hence, in order to maximise interoperability, both multiplexing approaches SHOULD be supported by senders and receivers. For multicast sessions, session-multiplexing MUST be used because the association of the original stream and the retransmission stream is problematic if SSRC-multiplexing is used with multicast sessions(see Section 5.3 for motivation). 4. Retransmission payload format The format of a retransmission packet is shown below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Original RTP Packet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP header usage is as follows: In the case of session-multiplexing, the same SSRC value MUST be used for the original stream and the retransmission stream. In the case of an SSRC collision in either the original session or the retransmission session, the RTP specification requires that an RTCP BYE packet MUST be sent in the session where the collision happened. In addition, an RTCP BYE packet MUST also be sent for the associated stream in its own session. After a new SSRC identifier is obtained, the SSRC of both streams MUST be set to this value. In the case of SSRC-multiplexing, two different SSRC values MUST be used for the original stream and the retransmission stream as required by RTP. If an SSRC collision is detected for either the Rey, et al. [Page 6] Internet Draft RTP Retransmission Payload Format February 2003 original stream or the retransmission stream, the RTP specification requires that an RTCP BYE packet MUST be sent for this stream. No RTCP BYE packet MUST be sent for the associated stream. Therefore, only the stream that experienced SSRC collision will choose a new SSRC value. Refer to Section 5.3 for the implications on the original and retransmission stream SSRC association at the receiver. For either multiplexing scheme, the sequence number has the standard definition, i.e. it MUST be one higher than the sequence number of the preceding packet sent in the retransmission stream. The retransmission packet timestamp is set to the original timestamp, i.e. to the timestamp of the original packet. As a consequence, the initial RTP timestamp for the first packet of the retransmission stream is not random but equal to the original timestamp of the first packet that is retransmitted. See the security considerations section in this document for security implications. Implementers have to be aware that the RTCP jitter value for the retransmission stream does not reflect the actual network jitter since there could be little correlation between the time a packet is retransmitted and its original timestamp. The payload type is dynamic. Each payload type of the original stream MUST map to a different payload type value in the retransmission stream. Therefore, when multiple payload types are used in the original stream, multiple dynamic payload types will be mapped to the retransmission payload format. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done with SDP. As the retransmission packet timestamp carries the original media timestamp, the timestamp clockrate used by the retransmission payload type is the same as the one used by the associated original payload type. It is thus possible to send retransmission packets whose original payload types have different timestamp clockrates in the same retransmission stream. Note that an RTP stream does not usually carry payload types of different clockrates. The payload of the RTP retransmission packet comprises the retransmission payload header followed by the payload of the original RTP packet. The length of the retransmission payload header is 2 octets. This payload header contains only one field, OSN, which MUST be set to the sequence number of the associated original RTP packet. The original RTP packet payload, including any possible payload headers specific to the original payload type, is placed right after the retransmission payload header. For payload types that support encoding at multiple rates, instead of retransmitting the same payload as the original RTP packet the sender MAY retransmit the same data encoded at a lower rate. This aims at limiting the bandwidth usage of the retransmission stream. Rey, et al. [Page 7] Internet Draft RTP Retransmission Payload Format February 2003 When doing so, the sender MUST ensure that the receiver will still be able to decode the payload of the already sent original packets that might have been encoded based on the payload of the lost original packet. In addition, if the sender chooses to retransmit at a lower rate, the values in the payload header of the original RTP packet may not longer apply to the retransmission packet and may need to be modified in the retransmission packet to reflect the change in rate. The sender should trade-off the decrease in bandwidth usage with the decrease in quality caused by resending at a lower rate. If the original RTP header carried any profile-specific extensions, the retransmission packet SHOULD include the same extensions immediately following the fixed RTP header as expected by applications running under this profile. In this case, the retransmission payload header is thus placed after the profile- specific extensions. If the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension. This header extension MUST be placed right after the fixed RTP header, as specified in RTP [3]. In this case, the retransmission payload header is thus placed after the header extension. If the original RTP packet contained RTP padding, that padding MUST be removed before constructing the retransmission packet. If padding of the retransmission packet is needed, padding is performed as with any RTP packets and the padding bit is set. The M, CC and CSRC bit of the original RTP header MUST remain unchanged in the retransmission packet. 5. Association of a retransmission stream with its original stream 5.1 Retransmission session sharing In the case of session-multiplexing, a retransmission session MUST map to exactly one original session, i.e. the same retransmission session cannot be used for different original sessions. If retransmission session sharing were allowed, it would be a problem for receivers, since they would receive retransmissions for original sessions they might not have joined. For example, a receiver wishing to receive only audio would receive also retransmitted video packets if an audio and video session shared the same retransmission session. 5.2 CNAME use In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same CNAME for an original stream and its associated retransmission stream. Rey, et al. [Page 8] Internet Draft RTP Retransmission Payload Format February 2003 5.3 Association at the receiver A receiver receiving multiple original and retransmission streams needs to associate each retransmission stream with its original stream. The association is done differently depending on whether session-multiplexing or SSRC-multiplexing is used. If session-multiplexing is used, the receiver associates the two streams having the same SSRC in the two sessions. Note that the payload type field cannot be used to perform the association as several media streams may have the same payload type value. The two sessions are themselves associated out-of-band. See Section 8 for how the grouping of the two sessions is done with SDP. If SSRC-multiplexing is used, the receiver should first of all look for two streams that have the same CNAME in the session. In some cases, the CNAME may not be enough to determine the association as multiple original streams in the same session may share the same CNAME. For example, there can be in the same video session multiple video streams mapping to different SSRCs and still using the same CNAME and possibly the same PT values. Each (or some) of these streams may have an associated retransmission stream. In this case, in order to find out the association between original and retransmission streams having the same CNAME, the receiver SHOULD behave as follows. The association can generally be resolved when the receiver receives a retransmission packet matching a retransmission request which had been sent earlier. Upon reception of a retransmission packet whose original sequence number has been previously requested, the receiver can derive that the SSRC of the retransmission packet is associated to the sender SSRC from which the packet was requested. However, this mechanism might fail if there are two outstanding requests for the same packet sequence number in two different original streams of the session. Note that since the initial packet sequence numbers are random, the probability of having two outstanding requests for the same packet sequence number would be very small. Nevertheless, in order to avoid ambiguity in the unicast case, the receiver MUST NOT have two outstanding requests for the same packet sequence number in two different original streams before the association is resolved. In multicast, this ambiguity cannot be completely avoided, because another receiver may have requested the same sequence number from another stream. Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. If the receiver discovers that two senders are using the same SSRC or if it receives an RTCP BYE packet, it MUST stop requesting retransmissions for that SSRC. Upon reception of original RTP packets with a new SSRC, the receiver MUST perform the SSRC association again as described in this section. Rey, et al. [Page 9] Internet Draft RTP Retransmission Payload Format February 2003 6. Use with the extended RTP profile for RTCP-based feedback This section gives general hints for the usage of this payload format with the extended RTP profile for RTCP-based feedback, denoted AVPF [1]. Note that the general RTCP send and receive rules and the RTCP packet format as specified in RTP apply, except for the changes that the AVPF profile introduces. In short, the AVPF profile relaxes the RTCP timing rules and specifies additional general-purpose RTCP feedback messages. See [1] for details. 6.1 RTCP at the sender In the case of session-multiplexing, Sender Report (SR) packets for the original stream are sent in the original session and SR packets for the retransmission stream are sent in the retransmission session according to the rules of RTP. In the case of SSRC-multiplexing, SR packets for both original and retransmission streams are sent in the same session according to the rules of RTP. The original and retransmission streams are seen, as far the RTCP bandwidth calculation is concerned, as independent senders belonging to the same RTP session and are thus equally sharing the RTCP bandwidth assigned to senders. Note that in both cases, session- and SSRC-multiplexing, BYE packets MUST still be sent for both streams as specified in RTP. In other words, it is not enough to send BYE packets for the original stream only. 6.2 RTCP Receiver Reports In the case of session-multiplexing, the receiver will send report blocks for the original stream and the retransmission stream in separate Receiver Report (RR) packets belonging to separate RTP sessions. RR packets reporting on the original stream are sent in the original RTP session while RR packets reporting on the retransmission stream are sent in the retransmission session. The RTCP bandwidth for these two sessions may be chosen independently (for example through RTCP bandwidth modifiers [4]). In the case of SSRC-multiplexing, the receiver sends report blocks for the original and the retransmission streams in the same RR packet since there is a single session. 6.3 Retransmission requests The NACK feedback message format defined in the AVPF profile SHOULD be used by receivers to send retransmission requests. Whether a receiver chooses to request a packet or not is an implementation issue. An actual receiver implementation should take into account Rey, et al. [Page 10] Internet Draft RTP Retransmission Payload Format February 2003 such factors as the tolerable application delay, the network environment and the media type. The receiver should generally assess whether the retransmitted packet would still be useful at the time it is received. The timestamp of the missing packet can be estimated from the timestamps of packets preceding and/or following the sequence number gap caused by the missing packet in the original stream. In most cases, some form of linear estimate of the timestamp is good enough. Furthermore, a receiver should compute an estimate of the round-trip time (RTT) to the sender. This can be done, for example, by measuring the retransmission delay to receive a retransmission packet after a NACK has been sent for that packet. This estimate may also be obtained from past observations, RTCP report round-trip time if available or any other means. A standard mechanism for the receiver to estimate the RTT is specified in RTP Extended Reports [11]. The receiver should not send a retransmission request as soon as it detects a missing sequence number but should add some extra delay to compensate for packet reordering. This extra delay may, for example, be based on past observations of the experienced packet reordering. To increase the robustness to the loss of a NACK or of a retransmission packet, a receiver may send a new NACK for the same packet. This is referred to as multiple retransmissions. Before sending a new NACK for a missing packet, the receiver should rely on a timer to be reasonably sure that the previous retransmission attempt has failed in order to avoid unnecessary retransmissions. NACKs MUST be sent only for the original RTP stream. Otherwise, if a receiver wanted to perform multiple retransmissions by sending a NACK in the retransmission stream, it would not be able to know the original sequence number and a timestamp estimation of the packet it requests. 6.4 Timing rules The NACK feedback message may be sent in a regular full compound RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK in an early packet allows to react more quickly to a given packet loss. However, in that case if a new packet loss occurs right after the early RTCP packet was sent, the receiver will then have to wait for the next regular RTCP compound packet after the early packet. Sending NACKs only in regular RTCP compound decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. Implementers should consider the possible implications of this fact for the application being used. Rey, et al. [Page 11] Internet Draft RTP Retransmission Payload Format February 2003 Furthermore, receivers may make use of the minimum interval between regular RTCP compound packets. This interval can be used to keep regular receiver reporting down to a minimum, while still allowing receivers to send early RTCP packets during periods requiring more frequent feedback, e.g. times of higher packet loss rate.. Note that although RTCP packets may be suppressed because they do not contain NACKs, the same RTCP bandwidth as if they were sent needs to be available. See AVPF [1] for details on the use of the minimum interval. 7. Congestion control RTP retransmission poses a risk of increasing network congestion. In a best-effort environment, packet loss is caused by congestion. Reacting to loss by retransmission of older data without decreasing the rate of the original stream would thus further increase congestion. Implementations SHOULD follow the recommendations below in order to use retransmission. The RTP profile under which the retransmission scheme is used defines an appropriate congestion control mechanism in different environments. Following the rules under the profile, an RTP application can determine its acceptable bitrate and packet rate in order to be fair to other TCP or RTP flows. If an RTP application uses retransmission, the acceptable packet rate and bitrate includes both the original and retransmitted data. This guarantees that an application using retransmission achieves the same fairness as one that does not. Such a rule would translate in practice into the following actions: If enhanced service is used, it should be made sure that the total bitrate and packet rate do not exceed that of the requested service. It should be further monitored that the requested services are actually delivered. In a best-effort environment, the sender SHOULD NOT send retransmission packets without reducing the packet rate and bitrate of the original stream (for example by encoding the data at a lower rate). In addition, the sender MAY selectively retransmit only the packets that it deems important and ignore NACK messages for other packets in order to limit the bitrate. These congestion control mechanisms should keep the packet loss rate within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve, on a reasonable timescale, an average throughput, that is not less than the one the RTP flow achieves. If the packet loss rate exceeds an acceptable level, it should be concluded that congestion is not kept under control and retransmission should then not be used. It may further be necessary to adapt the transmission rate (or the number of layers subscribed Rey, et al. [Page 12] Internet Draft RTP Retransmission Payload Format February 2003 for a layered multicast session), or to arrange for the receiver to leave the session. 8. Retransmission Payload Format MIME type registration 8.1 Introduction The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time" and "apt". The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple payload types are used for the original streams, then multiple "apt" parameters MUST be included to map each original stream payload type to a different retransmission payload type. An OPTIONAL payload-format-specific parameter, "rtx-time," indicates the maximum time a server will try to retransmit a packet. The syntax is as follows: a=fmtp: apt=;rtx-time= where, : indicates the dynamic payload type number assigned to the retransmission payload format in an rtpmap attribute. : the value of the original stream payload type to which this retransmission stream payload type is associated. : indicates the time in milliseconds, measured from the time a packet was first sent until the time the server will stop trying to retransmit the packet. The absence of the rtx-time parameter for a retransmission stream means that the maximum retransmission time is not defined, but MAY be negotiated by other means. 8.2 Registration of audio/rtx MIME type: audio MIME subtype: rtx Required parameters: Rey, et al. [Page 13] Internet Draft RTP Retransmission Payload Format February 2003 rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted. apt: associated payload type. The value of this parameter is the payload type of the associated original stream. Optional parameters: rtx-time: indicates the time in milliseconds, measured from the time a packet was first sent until the time the server will stop trying to retransmit the packet. Encoding considerations: this type is only defined for transfer via RTP. Security considerations: see Section 12 of RFC XXXX Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: multimedia streaming applications Additional information: none Person & email address to contact for further information: rey@panasonic.de david.leon@nokia.com avt@ietf.org Intended usage: COMMON Author/Change controller: Jose Rey David Leon IETF AVT WG 8.3 Registration of video/rtx MIME type: video MIME subtype: rtx Required parameters: rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted. apt: associated payload type. The value of this parameter is the payload type of the associated original stream. Rey, et al. [Page 14] Internet Draft RTP Retransmission Payload Format February 2003 Optional parameters: rtx-time: indicates the time in milliseconds, measured from the time a packet was first sent until the time the server will stop trying to retransmit the packet. Encoding considerations: this type is only defined for transfer via RTP. Security considerations: see Section 12 of RFC XXXX Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: multimedia streaming applications Additional information: none Person & email address to contact for further information: rey@panasonic.de david.leon@nokia.com avt@ietf.org Intended usage: COMMON Author/Change controller: Jose Rey David Leon IETF AVT WG 8.4 Registration of text/rtx MIME type: text MIME subtype: rtx Required parameters: rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted. apt: associated payload type. The value of this parameter is the payload type of the associated original stream. Optional parameters: rtx-time: indicates the time in milliseconds, measured from the time a packet was first sent until the time the server will stop trying to retransmit the packet. Rey, et al. [Page 15] Internet Draft RTP Retransmission Payload Format February 2003 Encoding considerations: this type is only defined for transfer via RTP. Security considerations: see Section 12 of RFC XXXX Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: multimedia streaming applications Additional information: none Person & email address to contact for further information: rey@panasonic.de david.leon@nokia.com avt@ietf.org Intended usage: COMMON Author/Change controller: Jose Rey David Leon IETF AVT WG 8.5 Registration of application/rtx MIME type: application MIME subtype: rtx Required parameters: rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted. apt: associated payload type. The value of this parameter is the payload type of the associated original stream. Optional parameters: rtx-time: indicates the time in milliseconds, measured from the time a packet was first sent until the time the server will stop trying to retransmit the packet. Encoding considerations: this type is only defined for transfer via RTP. Security considerations: see Section 12 of RFC XXXX Interoperability considerations: none Rey, et al. [Page 16] Internet Draft RTP Retransmission Payload Format February 2003 Published specification: RFC XXXX Applications which use this media type: multimedia streaming applications Additional information: none Person & email address to contact for further information: rey@panasonic.de david.leon@nokia.com avt@ietf.org Intended usage: COMMON Author/Change controller: Jose Rey David Leon IETF AVT WG 8.6 Mapping to SDP The information carried in the MIME media type specification has a specific mapping to fields in SDP [5], which is commonly used to describe RTP sessions. When SDP is used to specify retransmissions for an RTP stream, the mapping is done as follows: - The MIME types ("video"), ("audio") and ("text") go in the SDP "m=" as the media name. - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be that of the retransmission payload type. See Section 4 for details on this. - The AVPF profile-specific parameters "ack" and "nack" go in SDP "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of feedback. See the AVPF profile [1] for details. - The retransmission payload-format-specific parameters "apt" and "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of parameter=value pairs. - Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated list of parameter=value pairs. In the following sections some example SDP descriptions are presented. 8.7 SDP description with session-multiplexing In the case of session-multiplexing, the SDP description contains one media specification "m" line per RTP session. The SDP MUST Rey, et al. [Page 17] Internet Draft RTP Retransmission Payload Format February 2003 provide the grouping of the original and associated retransmission sessions' "m" lines, using the Flow Identification (FID) semantics defined in RFC 3388 [6]. The following example specifies two original, AMR and MPEG-4, streams on ports 49170 and 49174 and their corresponding retransmission streams on ports 49172 and 49176, respectively: v=0 o=mascha 2980675221 2980675778 IN IP4 at.home.ru c=IN IP4 125.25.5.1 a=group:FID 1 2 a=group:FID 3 4 m=audio 49170 RTP/AVPF 96 a=rtpmap:96 AMR/8000 a=fmtp:96 octet-align=1 a=rtcp-fb:96 nack a=mid:1 m=audio 49172 RTP/AVPF 97 a=rtpmap:97 rtx/8000 a=fmtp:97 apt=96;rtx-time=3000 a=mid:2 m=video 49174 RTP/AVPF 98 a=rtpmap:98 MP4V-ES/90000 a=rtcp-fb:98 nack a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F a=mid:3 m=video 49176 RTP/AVPF 99 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98;rtx-time=3000 a=mid:4 A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only. This is illustrated in the following example, which is an SDP description for a single original MPEG-4 stream and its corresponding retransmission session: v=0 o=mascha 2980675221 2980675778 IN IP4 at.home.ru c=IN IP4 125.25.5.1 m=video 49170 RTP/AVPF 96 a=rtpmap:96 MP4V-ES/90000 a=rtcp-fb:96 nack a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F m=video 49172 RTP/AVPF 97 a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96;rtx-time=3000 Rey, et al. [Page 18] Internet Draft RTP Retransmission Payload Format February 2003 8.8 SDP description with SSRC-multiplexing The following is an example of an SDP description for an RTP video session using SSRC-multiplexing with similar parameters as in the single-session example above: v=0 o=mascha 2980675221 2980675778 IN IP4 at.home.ru c=IN IP4 125.25.5.1 m=video 49170 RTP/AVPF 96 97 a=rtpmap:96 MP4V-ES/90000 a=rtcp-fb:96 nack a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96;rtx-time=3000 9. RTSP considerations The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an application-level protocol for control over the delivery of data with real-time properties. This section looks at the issues involved in controlling RTP sessions that use retransmissions. 9.1 RTSP control with SSRC-multiplexing In the case of SSRC-multiplexing, the "m" line includes both original and retransmission payload types and has a single RTSP "control" attribute. The receiver uses the "m" line to request SETUP and TEARDOWN of the whole media session. The RTP profile contained in the transport header MUST be the AVPF profile or another suitable profile allowing extended feedback. In order to control the sending of the session original media stream, the receiver sends as usual PLAY and PAUSE requests to the sender for the session. The RTP-info header that is used to set RTP-specific parameters in the PLAY response MUST be set according to the RTP information of the original stream. When the receiver starts receiving the original stream, it can then request retransmission through RTCP NACKs without additional RTSP signalling. 9.2 RTSP control with session-multiplexing In the case of session-multiplexing, each SDP "m" line has an RTSP "control" attribute. Hence, when retransmission is used, both the original session and the retransmission have their own "control" attributes. The receiver can associate the original session and the retransmission session through the FID semantics as specified in Section 8. Rey, et al. [Page 19] Internet Draft RTP Retransmission Payload Format February 2003 The original and the retransmission streams are set up and torn down separately through their respective media "control" attribute. The RTP profile contained in the transport header MUST be the AVPF profile or another suitable profile allowing extended feedback for both the original and the retransmission session. The RTSP presentation SHOULD support aggregate control and SHOULD contain a session level RTSP URL. The receiver SHOULD use aggregate control for an original session and its associated retransmission session. Otherwise, there would need to be two different 'session- id' values, i.e. different values for the original and retransmission sessions, and the sender would not know how to associate them. The session-level "control" attribute is then used as usual to control the playing of the original stream. When the receiver starts receiving the original stream, it can then request retransmissions through RTCP without additional RTSP signalling. 9.3 RTSP control of the retransmission stream Because of the nature of retransmissions, the sending of retransmission packets SHOULD NOT be controlled through RTSP PLAY and PAUSE requests. The PLAY and PAUSE requests should not affect the retransmission stream. Retransmission packets are sent upon receiver requests in the original RTCP stream, regardless of the state. 9.4 Cache control Retransmission streams SHOULD NOT be cached. In the case of session-multiplexing, the "Cache-Control" header SHOULD be set to "no-cache" for the retransmission stream. In the case of SSRC-multiplexing, RTSP cannot specify independent caching for the retransmission stream, because there is a single "m" line in SDP. Therefore, the implementer should take this fact into account when deciding whether to cache an SSRC-multiplexed session or not. 10. Implementation examples This document mandates only the sender and receiver behaviours that are necessary for interoperability. In addition, certain algorithms, such as rate control or buffer management when targeted at specific environments, may enhance the retransmission efficiency. This section gives an overview of different implementation options allowed within this specification. Rey, et al. [Page 20] Internet Draft RTP Retransmission Payload Format February 2003 The first example describes a minimal receiver implementation. With this implementation, it is possible to retransmit lost RTP packets, detect efficiently the loss of retransmissions and perform multiple retransmissions, if needed. Most of the necessary processing is done at the server. The second example shows how a receiver may implement additional enhancements that might help reduce sender buffer requirements and optimise the retransmission efficiency The third example shows how retransmissions may be used in (small) multicast groups in conjunction with layered encoding. It illustrates that retransmissions and layered encoding may be complementary techniques. 10.1 A minimal receiver implementation example This section gives an example of an implementation supporting multiple retransmissions. The sender transmits the original data in RTP packets using the MPEG-4 video RTP payload format. It is assumed that NACK feedback messages are used, as per [1]. An SDP description example with SSRC-multiplexing is given below: v=0 o=mascha 2980675221 2980675778 IN IP4 at.home.ru c=IN IP4 125.25.5.1 m=video 49170 RTP/AVPF 96 97 a=rtpmap:96 MP4V-ES/90000 a=rtcp-fb:96 nack a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96;rtx-time=3000 The format-specific parameter "rtx-time" indicates that the server will buffer the sent packets in a retransmission buffer for 3.0 seconds, after which the packets are deleted from the retransmission buffer and will never be sent again. In this implementation example, the required RTP receiver processing to handle retransmission is kept to a minimum. The receiver detects packet loss from the gaps observed in the received sequence numbers. It signals lost packets to the sender through NACKs as defined in the AVPF profile [1]. The receiver should take into account the signalled sender retransmission buffer length in order to dimension its own reception buffer. It should also derive from the buffer length the maximum number of times the retransmission of a packet can be requested. The sender should retransmit the packets selectively, i.e. it should choose whether to retransmit a requested packet depending on the packet importance, the observed QoS and congestion state of the network connection to the receiver. Obviously, the sender processing Rey, et al. [Page 21] Internet Draft RTP Retransmission Payload Format February 2003 increases with the number of receivers as state information and processing load must be allocated to each receiver. 10.2 An enhanced receiver implementation example The receiver may have more accurate information than the sender about the current network QoS such as available bandwidth, packet loss rate, delay and jitter. In addition, other receiver-specific parameters such as buffer level, estimated importance of the lost packet and application level QoS may be used by the receiver to make a more efficient use of RTP retransmission by selectively sending NACKs for important lost packets and not for others. For example, a receiver may decide to suppress a request for a packet loss that could be concealed locally, or for a retransmission that would arrive late. Furthermore, a receiver may acknowledge the received packets. This can be done by sending ACKs, as per [1]. Upon receiving an ACK, the sender may delete all the acknowledged packets from its retransmission buffer. Note that this would also require only limited increase in the required RTCP bandwidth as long as ACK packets are sent seldom enough. This implementation may help reduce buffer requirements at the sender and optimise the performance of the implementation by using selective requests. Note that these receiver enhancements do not need to be negotiated as they do not affect the sender implementation. However, in order to allow the receiver to acknowledge packets, it is needed to allow the use of ACKs in the SDP description, by means of an additional SDP "a=rtcp-fb" line, as follows: v=0 o=mascha 2980675221 2980675778 IN IP4 at.home.ru c=IN IP4 125.25.5.1 m=video 49170 RTP/AVPF 96 97 a=rtpmap:96 MP4V-ES/90000 a=rtcp-fb:96 nack a=rtcp-fb:96 ack a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96;rtx-time=3000 10.3 Retransmission of Layered Encoded Media in Multicast This section shows how to combine retransmissions with layered encoding in multicast sessions. Note that the retransmission framework is not intended as a complete solution to reliable multicast. Refer to RFC 2887 [10], for an overview of the problems related with reliable multicast transmission. Packets of different importance are sent in different RTP sessions. The retransmission streams corresponding to the different layers can Rey, et al. [Page 22] Internet Draft RTP Retransmission Payload Format February 2003 themselves be seen as different retransmission layers. The relative importance of the different retransmission streams should reflect the relative importance of the different original streams. In multicast, SSRC-multiplexing of the original and retransmission streams is not allowed as per Section 5.3 of this document. For this reason, the retransmission stream(s) MUST be sent in different RTP session(s) using session-multiplexing. An SDP description example of multicast retransmissions for layered encoded media is given below: c=IN IP4 224.2.1.1/127/3 m=video 8000 RTP/AVPF 98 a=rtpmap:98 MP4V-ES/90000 a=rtcp-fb:98 nack c=IN IP4 224.2.1.4/127/3 m=video 8000 RTP/AVPF 99 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98;rtx-time=3000 The server and the receiver may implement the retransmission methods illustrated in the previous examples. In addition, they may choose to request and retransmit a lost packet depending on the layer it belongs to. 11. IANA considerations A new MIME subtype name, "rtx", has been registered. An additional REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", are defined. See Section 8 for details. 12. Security considerations Applications utilising encryption SHOULD encrypt both the original and the retransmission stream. Old keys will likely need to be cached so that when the keys change for the original stream, the old key is used until it is determined that the key has changed on the retransmission packets as well. The use of the same key for the retransmitted stream and the original stream may lead to security problems, e.g. two-time pads. This sharing has to be evaluated towards the chosen security protocol and security algorithms. RTP recommends that the initial RTP timestamp SHOULD be random to secure the stream against known plain text attacks. This payload format does not follow this recommendation as the initial timestamp will be the media timestamp of the first retransmitted packet. Rey, et al. [Page 23] Internet Draft RTP Retransmission Payload Format February 2003 However, since the initial timestamp of the original stream is itself random, if the original stream is encrypted, the first retransmitted packet timestamp would also be random to an attacker. Therefore, confidentiality would not be compromised. Congestion control considerations with the use of retransmission are dealt with in Section 7 of this document. Any other security considerations of the profile under which the retransmission scheme is used should be applied. The retransmission payload format MUST NOT be used under the SAVP profile defined by the Secure Real-Time Transport Protocol (SRTP)[12] but instead an extension of SRTP should be defined to secure the AVPF profile. The definition of such a profile is out of the scope of this document. 13. Acknowledgements We would like to express our gratitude to Carsten Burmeister for his participation in the development of this document. Our thanks also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, Go Hori and Rahul Agarwal for their helpful comments. 14. References 14.1 Normative References 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 04.txt, September 2002. 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", draft-ietf-avt- rtp-new-11.txt, May 2002. 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- ietf-avt-rtcp-bw-05.txt, May 2002. 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Rey, et al. [Page 24] Internet Draft RTP Retransmission Payload Format February 2003 14.2 Informative References 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998. 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000. 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", draft-ietf-avt-srtp-05.txt, June 2002. Author's Addresses Jose Rey rey@panasonic.de Panasonic European Laboratories GmbH Monzastr. 4c D-63225 Langen, Germany Phone: +49-6103-766-134 Fax: +49-6103-766-166 David Leon david.leon@nokia.com Nokia Research Center 6000 Connection Drive Irving, TX. USA Phone: 1-972-374-1860 Akihiro Miyazaki akihiro@isl.mei.co.jp Core Software Development Center Corporate Software Development Division Matsushita Electric Industrial Co., Ltd. 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 Viktor Varsa viktor.varsa@nokia.com Nokia Research Center 6000 Connection Drive Irving, TX. USA Phone: 1-972-374-1861 Rolf Hakenberg hakenberg@panasonic.de Panasonic European Laboratories GmbH Monzastr. 4c D-63225 Langen, Germany Phone: +49-6103-766-162 Fax: +49-6103-766-166 Rey, et al. [Page 25] Internet Draft RTP Retransmission Payload Format February 2003 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Rey, et al. [Page 26] --Boundary_(ID_/uxOfmE+gFrceUnEsPws3w)-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 4 10:18:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24774 for ; Tue, 4 Feb 2003 10:18:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14FNdx01017 for avt-archive@odin.ietf.org; Tue, 4 Feb 2003 10:23:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FMsJ00924; Tue, 4 Feb 2003 10:22:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FALJ00417 for ; Tue, 4 Feb 2003 10:10:21 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24467 for ; Tue, 4 Feb 2003 10:04:11 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14F7mKV027095; Tue, 4 Feb 2003 16:07:48 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5J3H1P; Tue, 4 Feb 2003 16:07:48 +0100 Message-ID: <3E3FD744.9040801@era.ericsson.se> Date: Tue, 04 Feb 2003 16:07:48 +0100 X-Sybari-Trust: fe54ab81 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Rey CC: "Avt@Ietf. Org" References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14FALJ00418 Subject: [AVT] Comments on draft-ietf-avt-rtp-retransmission-05.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jose, I have a few minor comments that I believe that you must address before a successful WGLC can be performed. A few of these are related to the ID-nits. See: http://www.ietf.org/ID-nits.html 1. The SDP examples contain FQDNs that are not belonging to the example domain, see chapter 3 of RFC 2606. 2. IP addresses in SDP examples does not belong to example range 192.0.2.0/24. 3. Section 4: Last paragraph. I think that it is erroneous formulated that the "M", "CC" and CSRC" bit MUST remain unchanged. I think one should clarify that they shall be copied as is from the original header instead, 4. Section 8.6, The MIME types listed as going into the m= line are missing "application". 5. Section 9.3: "The PLAY and PAUSE requests SHOULD NOT affect the retransmission stream." I think this is normative language and the should not shall be capitalized. 6. Section 10.3 The SDP example is in error: The c= lines shall be placed after its corresponding m= line. Please mind the order and place it directly after the m= line as no i= is present. 7. Section 11: Might be nice to say that the RTX subtype is register for four different media types. 8. An IPR statement prior to copyright section is missing. See ID-nits about required sections I think all is very easy to update. Best Regards Magnus Jose Rey wrote: >Hi all, > >attached the latest revision of the retransmission draft. We feel it is >ready for WGLC and would like to ask for your comments. > >This is the list of changes since version -04: > >a) s.3: 1st paragragh. Applicability of the retransmission payload >format (Colin's comment) >b) s.3.1: last paragraph (no SSRC-mux if multicast rtx, Colin's comment, >solved on the list) >c) s.4: 5th paragraph starting from the end. In section 4, two main >changes/additions: possibility to retransmit at a lower rate and >clarification of headers ordering (Colin's comment, the latter); plus >one minor thing: clarification of SSRC collision handling by the sender. >d) s.5.3: last paragraph but one >e) s.6.1: new, to separate sender and receiver RTCP. >f) s.10.2: implementation examples. Clarified. >g) s.11 MIME registration reorganised. >h) s.12: the retransmission payload format cannot be used under SAVP. >Reference to SAVP removed, as concluded on the list. > > >I think that's it. > >cheers, > >José > > > > > >------------------------------------------------------------------------ > > > > > Internet Draft > draft-ietf-avt-rtp-retransmission-05.txt J. Rey/Matsushita > D. Leon/Nokia > A. Miyazaki/Matsushita > V. Varsa/Nokia > R. Hakenberg/Matsushita > > > > Expires: August 2003 February 2003 > > > RTP Retransmission Payload Format > > Status of this Memo > > This document is an Internet-Draft and is in full conformance > with all provisions of Section 10 of RFC 2026. > > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > [Note to RFC Editor: This paragraph is to be deleted when this > draft is published as an RFC. References in this draft to RFC XXXX > should be replaced with the RFC number assigned to this document.] > > Abstract > > RTP retransmission is an effective packet loss recovery technique > for real-time applications with relaxed delay bounds. This document > describes an RTP payload format for performing retransmissions. > Retransmitted RTP packets are sent in a separate stream from the > original RTP stream. It is assumed that feedback from receivers to > senders is available. In particular, it is assumed that RTCP > > > IETF draft - Expires August 2003 [Page 1] > Internet Draft RTP Retransmission Payload Format February 2003 > > > feedback as defined in the extended RTP profile for RTCP-based > feedback (denoted RTP/AVPF), is available in this memo. > > >Table of Contents > > 1. Introduction....................................................3 > 2. Terminology.....................................................3 > 3. Requirements and design rationale for a retransmission scheme...4 > 4. Retransmission payload format...................................6 > 5. Association of a retransmission stream with its original stream.8 > 6. Use with the extended RTP profile for RTCP-based feedback......10 > 7. Congestion control.............................................12 > 8. Retransmission Payload Format MIME type registration...........13 > 9. RTSP considerations............................................19 > 10. Implementation examples.......................................20 > 11. IANA considerations...........................................23 > 12. Security considerations.......................................23 > 13. Acknowledgements..............................................24 > 14. References....................................................24 > Author's Addresses................................................25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rey, et al. [Page 2] > Internet Draft RTP Retransmission Payload Format February 2003 > > >1. Introduction > > Packet losses between an RTP sender and receiver may significantly > degrade the quality of the received media. Several techniques, such > as forward error correction (FEC), retransmissions or interleaving > may be considered to increase packet loss resiliency. RFC 2354 [8] > discusses the different options. > > When choosing a repair technique for a particular application, the > tolerable latency of the application has to be taken into account. > In the case of multimedia conferencing, the end-to-end delay has to > be at most a few hundred milliseconds in order to guarantee > interactivity, which usually excludes the use of retransmission. > > However, in the case of multimedia streaming, the user can tolerate > an initial latency as part of the session set-up and thus an end-to- > end delay of several seconds may be acceptable. Retransmission may > thus be considered for such applications. > > This document specifies a retransmission method for RTP applicable > to unicast and (small) multicast groups: it defines a payload format > for retransmitted RTP packets and provides protocol rules for the > sender and the receiver involved in retransmissions. > > Furthermore, this retransmission payload format was designed for use > with the extended RTP profile for RTCP-based feedback, AVPF [1]. It > may also be used with other RTP profiles defined in the future. > > The AVPF profile allows for more frequent feedback and for early > feedback. It defines a small number of general-purpose feedback > messages, e.g. ACKs and NACKs, as well as codec and application- > specific feedback messages. See [1] for details. > > >2. Terminology > > The following terms are used in this document: > > Original packet: refers to an RTP packet which carries user data > sent for the first time by an RTP sender. > > Original stream: refers to the RTP stream of original packets. > > Retransmission packet: refers to an RTP packet which is to be used > by the receiver instead of a lost original packet. Such a > retransmission packet is said to be associated with the original RTP > packet. > > Retransmission request: a means by which an RTP receiver is able to > request that the RTP sender should send a retransmission packet for > a given original packet. Usually, an RTCP NACK packet as specified > in [1] is used as retransmission request for lost packets. > > > Rey, et al. [Page 3] > Internet Draft RTP Retransmission Payload Format February 2003 > > > Retransmission stream: the stream of retransmission packets > associated with an original stream. > > Session-multiplexing: scheme by which the original stream and the > associated retransmission stream are sent into two different RTP > sessions. > > SSRC-multiplexing: scheme by which the original stream and the > retransmission stream are sent in the same RTP session with > different SSRC values. > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [2]. > > >3. Requirements and design rationale for a retransmission scheme > > The use of retransmissions in RTP as a repair method for streaming > media is appropriate in those scenarios with relaxed delay bounds > and where full reliability is not a requirement. More specifically, > RTP retransmission allows to trade-off reliability vs. delay, i.e. > the endpoints may give up retransmitting a lost packet after a given > buffering time has elapsed. Unlike TCP there is thus no head-of- > line blocking caused by RTP retransmissions. The implementer should > be aware that in cases where full reliability is required or higher > delay and jitter can be tolerated, TCP or other transport options > should be considered. > > The RTP retransmission scheme defined in this document is designed > to fulfil the following set of requirements: > > 1. It must not break general RTP and RTCP mechanisms. > 2. It must be suitable for unicast and small multicast groups. > 3. It must work with mixers and translators. > 4. It must work with all known payload types. > 5. It must not prevent the use of multiple payload types in a > session. > 6. In order to support the largest variety of payload formats, the > RTP receiver must be able to derive how many and which RTP > packets were lost as a result of a gap in received RTP sequence > numbers. This requirement is referred to as sequence number > preservation. Without such a requirement, it would be impossible > to use retransmission with payload formats, such as > conversational text [9] or most audio/video streaming > applications, that use the RTP sequence number to detect lost > packets. > > When designing a solution for RTP retransmission, several approaches > may be considered for the multiplexing of the original RTP packets > and the retransmitted RTP packets. > > > Rey, et al. [Page 4] > Internet Draft RTP Retransmission Payload Format February 2003 > > > One approach may be to retransmit the RTP packet with its original > sequence number and send original and retransmission packets in the > same RTP stream. The retransmission packet would then be identical > to the original RTP packet, i.e. the same header (and thus same > sequence number) and the same payload. However, such an approach is > not acceptable because it would corrupt the RTCP statistics. As a > consequence, requirement 1 would not be met. Correct RTCP > statistics require that for every RTP packet within the RTP stream, > the sequence number be increased by one. > > Another approach may be to multiplex original RTP packets and > retransmission packets in the same RTP stream using different > payload type values. With such an approach, the original packets > and the retransmission packets would share the same sequence number > space. As a result, the RTP receiver would not be able to infer how > many and which original packets (which sequence numbers) were lost. > > In other words, this approach does not satisfy the sequence number > preservation requirement (requirement 6). This in turn implies that > requirement 4 would not be met. Interoperability with mixers and > translators would also be more difficult if they did not understand > this new retransmission payload type in a sender RTP stream. For > these reasons, a solution based on payload type multiplexing of > original packets and retransmission packets in the same RTP stream > is excluded. > > Finally, the original and retransmission packets may be sent in two > separate streams. These two streams may be multiplexed either by > sending them in two different sessions , i.e. session-multiplexing, > or in the same session using different SSRC values, i.e. SSRC- > multiplexing. Since original and retransmission packets carry media > of the same type, the objections in Section 5.2 of RTP [3] to RTP > multiplexing do not apply in this case. > > Mixers and translators may process the original stream and simply > discard the retransmission stream if they are unable to utilise it. > Using two separate streams thus satisfies all the requirements > listed in this section. > >3.1 Multiplexing scheme choice > > Session-multiplexing and SSRC-multiplexing have different pros and > cons: > > Session-multiplexing is based on sending the retransmission stream > in a different RTP session (as defined in RTP [3]) from that of the > original stream, i.e. the original and retransmission streams are > sent to different network addresses and/or port numbers. Having a > separate session allows more flexibility. In multicast, using two > separate sessions for the original and the retransmission streams > allows a receiver to choose whether or not to subscribe to the RTP > session carrying the retransmission stream. The original session > may also be single-source multicast while separate unicast sessions > > Rey, et al. [Page 5] > Internet Draft RTP Retransmission Payload Format February 2003 > > > are used to convey retransmissions to each of the receivers, which > as a result will receive only the retransmission packets they > request. > > The use of separate sessions also facilitates differential treatment > by the network and may simplify processing in mixers, translators > and packet caches. > > With SSRC-multiplexing, a single session is needed for the original > and the retransmission stream. This allows streaming servers and > middleware which are involved in a high number of concurrent > sessions to minimise their port usage. > > This retransmission payload format allows both session-multiplexing > and SSRC-multiplexing for unicast sessions. From an implementation > point of view, there is little difference between the two > approaches. Hence, in order to maximise interoperability, both > multiplexing approaches SHOULD be supported by senders and > receivers. For multicast sessions, session-multiplexing MUST be > used because the association of the original stream and the > retransmission stream is problematic if SSRC-multiplexing is used > with multicast sessions(see Section 5.3 for motivation). > > >4. Retransmission payload format > > The format of a retransmission packet is shown below: > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RTP Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OSN | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Original RTP Packet Payload | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The RTP header usage is as follows: > > In the case of session-multiplexing, the same SSRC value MUST be > used for the original stream and the retransmission stream. In the > case of an SSRC collision in either the original session or the > retransmission session, the RTP specification requires that an RTCP > BYE packet MUST be sent in the session where the collision happened. > In addition, an RTCP BYE packet MUST also be sent for the associated > stream in its own session. After a new SSRC identifier is obtained, > the SSRC of both streams MUST be set to this value. > > In the case of SSRC-multiplexing, two different SSRC values MUST be > used for the original stream and the retransmission stream as > required by RTP. If an SSRC collision is detected for either the > > Rey, et al. [Page 6] > Internet Draft RTP Retransmission Payload Format February 2003 > > > original stream or the retransmission stream, the RTP specification > requires that an RTCP BYE packet MUST be sent for this stream. No > RTCP BYE packet MUST be sent for the associated stream. Therefore, > only the stream that experienced SSRC collision will choose a new > SSRC value. Refer to Section 5.3 for the implications on the > original and retransmission stream SSRC association at the receiver. > > For either multiplexing scheme, the sequence number has the standard > definition, i.e. it MUST be one higher than the sequence number of > the preceding packet sent in the retransmission stream. > > The retransmission packet timestamp is set to the original > timestamp, i.e. to the timestamp of the original packet. As a > consequence, the initial RTP timestamp for the first packet of the > retransmission stream is not random but equal to the original > timestamp of the first packet that is retransmitted. See the > security considerations section in this document for security > implications. > > Implementers have to be aware that the RTCP jitter value for the > retransmission stream does not reflect the actual network jitter > since there could be little correlation between the time a packet is > retransmitted and its original timestamp. > > The payload type is dynamic. Each payload type of the original > stream MUST map to a different payload type value in the > retransmission stream. Therefore, when multiple payload types are > used in the original stream, multiple dynamic payload types will be > mapped to the retransmission payload format. See Section 8.1 for > the specification of how the mapping between original and > retransmission payload types is done with SDP. > > As the retransmission packet timestamp carries the original media > timestamp, the timestamp clockrate used by the retransmission > payload type is the same as the one used by the associated original > payload type. It is thus possible to send retransmission packets > whose original payload types have different timestamp clockrates in > the same retransmission stream. Note that an RTP stream does not > usually carry payload types of different clockrates. > > The payload of the RTP retransmission packet comprises the > retransmission payload header followed by the payload of the > original RTP packet. The length of the retransmission payload > header is 2 octets. This payload header contains only one field, > OSN, which MUST be set to the sequence number of the associated > original RTP packet. The original RTP packet payload, including any > possible payload headers specific to the original payload type, is > placed right after the retransmission payload header. > > For payload types that support encoding at multiple rates, instead > of retransmitting the same payload as the original RTP packet the > sender MAY retransmit the same data encoded at a lower rate. This > aims at limiting the bandwidth usage of the retransmission stream. > > Rey, et al. [Page 7] > Internet Draft RTP Retransmission Payload Format February 2003 > > > When doing so, the sender MUST ensure that the receiver will still > be able to decode the payload of the already sent original packets > that might have been encoded based on the payload of the lost > original packet. In addition, if the sender chooses to retransmit > at a lower rate, the values in the payload header of the original > RTP packet may not longer apply to the retransmission packet and may > need to be modified in the retransmission packet to reflect the > change in rate. The sender should trade-off the decrease in > bandwidth usage with the decrease in quality caused by resending at > a lower rate. > > If the original RTP header carried any profile-specific extensions, > the retransmission packet SHOULD include the same extensions > immediately following the fixed RTP header as expected by > applications running under this profile. In this case, the > retransmission payload header is thus placed after the profile- > specific extensions. > > If the original RTP header carried an RTP header extension, the > retransmission packet SHOULD carry the same header extension. This > header extension MUST be placed right after the fixed RTP header, as > specified in RTP [3]. In this case, the retransmission payload > header is thus placed after the header extension. > > If the original RTP packet contained RTP padding, that padding MUST > be removed before constructing the retransmission packet. If > padding of the retransmission packet is needed, padding is performed > as with any RTP packets and the padding bit is set. > > The M, CC and CSRC bit of the original RTP header MUST remain > unchanged in the retransmission packet. > > >5. Association of a retransmission stream with its original stream > >5.1 Retransmission session sharing > > In the case of session-multiplexing, a retransmission session MUST > map to exactly one original session, i.e. the same retransmission > session cannot be used for different original sessions. > > If retransmission session sharing were allowed, it would be a > problem for receivers, since they would receive retransmissions for > original sessions they might not have joined. For example, a > receiver wishing to receive only audio would receive also > retransmitted video packets if an audio and video session shared the > same retransmission session. > >5.2 CNAME use > > In both the session-multiplexing and the SSRC-multiplexing cases, a > sender MUST use the same CNAME for an original stream and its > associated retransmission stream. > > Rey, et al. [Page 8] > Internet Draft RTP Retransmission Payload Format February 2003 > > > >5.3 Association at the receiver > > A receiver receiving multiple original and retransmission streams > needs to associate each retransmission stream with its original > stream. The association is done differently depending on whether > session-multiplexing or SSRC-multiplexing is used. > > If session-multiplexing is used, the receiver associates the two > streams having the same SSRC in the two sessions. Note that the > payload type field cannot be used to perform the association as > several media streams may have the same payload type value. The two > sessions are themselves associated out-of-band. See Section 8 for > how the grouping of the two sessions is done with SDP. > > If SSRC-multiplexing is used, the receiver should first of all look > for two streams that have the same CNAME in the session. In some > cases, the CNAME may not be enough to determine the association as > multiple original streams in the same session may share the same > CNAME. For example, there can be in the same video session multiple > video streams mapping to different SSRCs and still using the same > CNAME and possibly the same PT values. Each (or some) of these > streams may have an associated retransmission stream. > > In this case, in order to find out the association between original > and retransmission streams having the same CNAME, the receiver > SHOULD behave as follows. > > The association can generally be resolved when the receiver receives > a retransmission packet matching a retransmission request which had > been sent earlier. Upon reception of a retransmission packet whose > original sequence number has been previously requested, the receiver > can derive that the SSRC of the retransmission packet is associated > to the sender SSRC from which the packet was requested. > > However, this mechanism might fail if there are two outstanding > requests for the same packet sequence number in two different > original streams of the session. Note that since the initial packet > sequence numbers are random, the probability of having two > outstanding requests for the same packet sequence number would be > very small. Nevertheless, in order to avoid ambiguity in the > unicast case, the receiver MUST NOT have two outstanding requests > for the same packet sequence number in two different original > streams before the association is resolved. In multicast, this > ambiguity cannot be completely avoided, because another receiver may > have requested the same sequence number from another stream. > Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. > > If the receiver discovers that two senders are using the same SSRC > or if it receives an RTCP BYE packet, it MUST stop requesting > retransmissions for that SSRC. Upon reception of original RTP > packets with a new SSRC, the receiver MUST perform the SSRC > association again as described in this section. > > Rey, et al. [Page 9] > Internet Draft RTP Retransmission Payload Format February 2003 > > > > >6. Use with the extended RTP profile for RTCP-based feedback > > This section gives general hints for the usage of this payload > format with the extended RTP profile for RTCP-based feedback, > denoted AVPF [1]. Note that the general RTCP send and receive rules > and the RTCP packet format as specified in RTP apply, except for the > changes that the AVPF profile introduces. In short, the AVPF > profile relaxes the RTCP timing rules and specifies additional > general-purpose RTCP feedback messages. See [1] for details. > >6.1 RTCP at the sender > > In the case of session-multiplexing, Sender Report (SR) packets for > the original stream are sent in the original session and SR packets > for the retransmission stream are sent in the retransmission session > according to the rules of RTP. > > In the case of SSRC-multiplexing, SR packets for both original and > retransmission streams are sent in the same session according to the > rules of RTP. The original and retransmission streams are seen, as > far the RTCP bandwidth calculation is concerned, as independent > senders belonging to the same RTP session and are thus equally > sharing the RTCP bandwidth assigned to senders. > > Note that in both cases, session- and SSRC-multiplexing, BYE packets > MUST still be sent for both streams as specified in RTP. In other > words, it is not enough to send BYE packets for the original stream > only. > >6.2 RTCP Receiver Reports > > In the case of session-multiplexing, the receiver will send report > blocks for the original stream and the retransmission stream in > separate Receiver Report (RR) packets belonging to separate RTP > sessions. RR packets reporting on the original stream are sent in > the original RTP session while RR packets reporting on the > retransmission stream are sent in the retransmission session. The > RTCP bandwidth for these two sessions may be chosen independently > (for example through RTCP bandwidth modifiers [4]). > > In the case of SSRC-multiplexing, the receiver sends report blocks > for the original and the retransmission streams in the same RR > packet since there is a single session. > >6.3 Retransmission requests > > The NACK feedback message format defined in the AVPF profile SHOULD > be used by receivers to send retransmission requests. Whether a > receiver chooses to request a packet or not is an implementation > issue. An actual receiver implementation should take into account > > > Rey, et al. [Page 10] > Internet Draft RTP Retransmission Payload Format February 2003 > > > such factors as the tolerable application delay, the network > environment and the media type. > > The receiver should generally assess whether the retransmitted > packet would still be useful at the time it is received. The > timestamp of the missing packet can be estimated from the timestamps > of packets preceding and/or following the sequence number gap caused > by the missing packet in the original stream. In most cases, some > form of linear estimate of the timestamp is good enough. > > Furthermore, a receiver should compute an estimate of the round-trip > time (RTT) to the sender. This can be done, for example, by > measuring the retransmission delay to receive a retransmission > packet after a NACK has been sent for that packet. This estimate > may also be obtained from past observations, RTCP report round-trip > time if available or any other means. A standard mechanism for the > receiver to estimate the RTT is specified in RTP Extended Reports > [11]. > > The receiver should not send a retransmission request as soon as it > detects a missing sequence number but should add some extra delay to > compensate for packet reordering. This extra delay may, for > example, be based on past observations of the experienced packet > reordering. > > To increase the robustness to the loss of a NACK or of a > retransmission packet, a receiver may send a new NACK for the same > packet. This is referred to as multiple retransmissions. Before > sending a new NACK for a missing packet, the receiver should rely on > a timer to be reasonably sure that the previous retransmission > attempt has failed in order to avoid unnecessary retransmissions. > > NACKs MUST be sent only for the original RTP stream. Otherwise, if > a receiver wanted to perform multiple retransmissions by sending a > NACK in the retransmission stream, it would not be able to know the > original sequence number and a timestamp estimation of the packet it > requests. > >6.4 Timing rules > > The NACK feedback message may be sent in a regular full compound > RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a > NACK in an early packet allows to react more quickly to a given > packet loss. However, in that case if a new packet loss occurs > right after the early RTCP packet was sent, the receiver will then > have to wait for the next regular RTCP compound packet after the > early packet. Sending NACKs only in regular RTCP compound decreases > the maximum delay between detecting an original packet loss and > being able to send a NACK for that packet. Implementers should > consider the possible implications of this fact for the application > being used. > > > > Rey, et al. [Page 11] > Internet Draft RTP Retransmission Payload Format February 2003 > > > Furthermore, receivers may make use of the minimum interval between > regular RTCP compound packets. This interval can be used to keep > regular receiver reporting down to a minimum, while still allowing > receivers to send early RTCP packets during periods requiring more > frequent feedback, e.g. times of higher packet loss rate.. Note > that although RTCP packets may be suppressed because they do not > contain NACKs, the same RTCP bandwidth as if they were sent needs to > be available. See AVPF [1] for details on the use of the minimum > interval. > > >7. Congestion control > > RTP retransmission poses a risk of increasing network congestion. > In a best-effort environment, packet loss is caused by congestion. > Reacting to loss by retransmission of older data without decreasing > the rate of the original stream would thus further increase > congestion. Implementations SHOULD follow the recommendations below > in order to use retransmission. > > The RTP profile under which the retransmission scheme is used > defines an appropriate congestion control mechanism in different > environments. Following the rules under the profile, an RTP > application can determine its acceptable bitrate and packet rate in > order to be fair to other TCP or RTP flows. > > If an RTP application uses retransmission, the acceptable packet > rate and bitrate includes both the original and retransmitted data. > This guarantees that an application using retransmission achieves > the same fairness as one that does not. Such a rule would translate > in practice into the following actions: > > If enhanced service is used, it should be made sure that the total > bitrate and packet rate do not exceed that of the requested service. > It should be further monitored that the requested services are > actually delivered. In a best-effort environment, the sender SHOULD > NOT send retransmission packets without reducing the packet rate and > bitrate of the original stream (for example by encoding the data at > a lower rate). > > In addition, the sender MAY selectively retransmit only the packets > that it deems important and ignore NACK messages for other packets > in order to limit the bitrate. > > These congestion control mechanisms should keep the packet loss rate > within acceptable parameters. Packet loss is considered acceptable > if a TCP flow across the same network path and experiencing the same > network conditions would achieve, on a reasonable timescale, an > average throughput, that is not less than the one the RTP flow > achieves. If the packet loss rate exceeds an acceptable level, it > should be concluded that congestion is not kept under control and > retransmission should then not be used. It may further be necessary > to adapt the transmission rate (or the number of layers subscribed > > Rey, et al. [Page 12] > Internet Draft RTP Retransmission Payload Format February 2003 > > > for a layered multicast session), or to arrange for the receiver to > leave the session. > > >8. Retransmission Payload Format MIME type registration > >8.1 Introduction > > The following MIME subtype name and parameters are introduced in > this document: "rtx", "rtx-time" and "apt". > > The binding used for the retransmission stream to the payload type > number is indicated by an rtpmap attribute. The MIME subtype name > used in the binding is "rtx". > > The "apt" (associated payload type) parameter MUST be used to map > the retransmission payload type to the associated original stream > payload type. If multiple payload types are used for the original > streams, then multiple "apt" parameters MUST be included to map each > original stream payload type to a different retransmission payload > type. > > An OPTIONAL payload-format-specific parameter, "rtx-time," indicates > the maximum time a server will try to retransmit a packet. > > The syntax is as follows: > > a=fmtp: apt=;rtx-time= > where, > > : indicates the dynamic payload type number assigned to > the retransmission payload format in an rtpmap attribute. > > : the value of the original stream payload type to > which this retransmission stream payload type is associated. > > : indicates the time in milliseconds, measured > from the time a packet was first sent until the time the server > will stop trying to retransmit the packet. The absence of the > rtx-time parameter for a retransmission stream means that the > maximum retransmission time is not defined, but MAY be > negotiated by other means. > > >8.2 Registration of audio/rtx > > MIME type: audio > > MIME subtype: rtx > > Required parameters: > > > > Rey, et al. [Page 13] > Internet Draft RTP Retransmission Payload Format February 2003 > > > rate: the RTP timestamp clockrate is equal to the RTP timestamp > clockrate of the media that is retransmitted. > > apt: associated payload type. The value of this parameter is > the payload type of the associated original stream. > > Optional parameters: > > rtx-time: indicates the time in milliseconds, measured from the > time a packet was first sent until the time the server will > stop trying to retransmit the packet. > > > Encoding considerations: this type is only defined for transfer via > RTP. > > Security considerations: see Section 12 of RFC XXXX > > Interoperability considerations: none > > Published specification: RFC XXXX > > Applications which use this media type: multimedia streaming > applications > > Additional information: none > > Person & email address to contact for further information: > rey@panasonic.de > david.leon@nokia.com > avt@ietf.org > > Intended usage: COMMON > > Author/Change controller: > Jose Rey > David Leon > IETF AVT WG > >8.3 Registration of video/rtx > > MIME type: video > > MIME subtype: rtx > > Required parameters: > > rate: the RTP timestamp clockrate is equal to the RTP timestamp > clockrate of the media that is retransmitted. > > apt: associated payload type. The value of this parameter is > the payload type of the associated original stream. > > > Rey, et al. [Page 14] > Internet Draft RTP Retransmission Payload Format February 2003 > > > Optional parameters: > > rtx-time: indicates the time in milliseconds, measured from the > time a packet was first sent until the time the server will > stop trying to retransmit the packet. > > Encoding considerations: this type is only defined for transfer via > RTP. > > Security considerations: see Section 12 of RFC XXXX > > Interoperability considerations: none > > Published specification: RFC XXXX > > Applications which use this media type: multimedia streaming > applications > > Additional information: none > > Person & email address to contact for further information: > rey@panasonic.de > david.leon@nokia.com > avt@ietf.org > > Intended usage: COMMON > > Author/Change controller: > Jose Rey > David Leon > IETF AVT WG > >8.4 Registration of text/rtx > > MIME type: text > > MIME subtype: rtx > > Required parameters: > > rate: the RTP timestamp clockrate is equal to the RTP timestamp > clockrate of the media that is retransmitted. > > apt: associated payload type. The value of this parameter is > the payload type of the associated original stream. > > Optional parameters: > > rtx-time: indicates the time in milliseconds, measured from the > time a packet was first sent until the time the server will > stop trying to retransmit the packet. > > > > Rey, et al. [Page 15] > Internet Draft RTP Retransmission Payload Format February 2003 > > > Encoding considerations: this type is only defined for transfer via > RTP. > > Security considerations: see Section 12 of RFC XXXX > > Interoperability considerations: none > > Published specification: RFC XXXX > > Applications which use this media type: multimedia streaming > applications > > Additional information: none > > Person & email address to contact for further information: > rey@panasonic.de > david.leon@nokia.com > avt@ietf.org > > Intended usage: COMMON > > Author/Change controller: > Jose Rey > David Leon > IETF AVT WG > >8.5 Registration of application/rtx > > MIME type: application > > MIME subtype: rtx > > Required parameters: > > rate: the RTP timestamp clockrate is equal to the RTP timestamp > clockrate of the media that is retransmitted. > > apt: associated payload type. The value of this parameter is > the payload type of the associated original stream. > > Optional parameters: > > rtx-time: indicates the time in milliseconds, measured from the > time a packet was first sent until the time the server will > stop trying to retransmit the packet. > > Encoding considerations: this type is only defined for transfer via > RTP. > > Security considerations: see Section 12 of RFC XXXX > > Interoperability considerations: none > > > Rey, et al. [Page 16] > Internet Draft RTP Retransmission Payload Format February 2003 > > > Published specification: RFC XXXX > > Applications which use this media type: multimedia streaming > applications > > Additional information: none > > Person & email address to contact for further information: > rey@panasonic.de > david.leon@nokia.com > avt@ietf.org > > Intended usage: COMMON > > Author/Change controller: > Jose Rey > David Leon > IETF AVT WG > >8.6 Mapping to SDP > > The information carried in the MIME media type specification has a > specific mapping to fields in SDP [5], which is commonly used to > describe RTP sessions. When SDP is used to specify retransmissions > for an RTP stream, the mapping is done as follows: > > - The MIME types ("video"), ("audio") and ("text") go in the SDP > "m=" as the media name. > > - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding > name. The RTP clock rate in "a=rtpmap" MUST be that of the > retransmission payload type. See Section 4 for details on this. > > - The AVPF profile-specific parameters "ack" and "nack" go in SDP > "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of > feedback. See the AVPF profile [1] for details. > > - The retransmission payload-format-specific parameters "apt" and > "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of > parameter=value pairs. > > - Any remaining parameters go in the SDP "a=fmtp" attribute by > copying them directly from the MIME media type string as a semicolon > separated list of parameter=value pairs. > > In the following sections some example SDP descriptions are > presented. > >8.7 SDP description with session-multiplexing > > In the case of session-multiplexing, the SDP description contains > one media specification "m" line per RTP session. The SDP MUST > > > Rey, et al. [Page 17] > Internet Draft RTP Retransmission Payload Format February 2003 > > > provide the grouping of the original and associated retransmission > sessions' "m" lines, using the Flow Identification (FID) semantics > defined in RFC 3388 [6]. > > The following example specifies two original, AMR and MPEG-4, > streams on ports 49170 and 49174 and their corresponding > retransmission streams on ports 49172 and 49176, respectively: > > v=0 > o=mascha 2980675221 2980675778 IN IP4 at.home.ru > c=IN IP4 125.25.5.1 > a=group:FID 1 2 > a=group:FID 3 4 > m=audio 49170 RTP/AVPF 96 > a=rtpmap:96 AMR/8000 > a=fmtp:96 octet-align=1 > a=rtcp-fb:96 nack > a=mid:1 > m=audio 49172 RTP/AVPF 97 > a=rtpmap:97 rtx/8000 > a=fmtp:97 apt=96;rtx-time=3000 > a=mid:2 > m=video 49174 RTP/AVPF 98 > a=rtpmap:98 MP4V-ES/90000 > a=rtcp-fb:98 nack > a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F > a=mid:3 > m=video 49176 RTP/AVPF 99 > a=rtpmap:99 rtx/90000 > a=fmtp:99 apt=98;rtx-time=3000 > a=mid:4 > > > A special case of the SDP description is a description that contains > only one original session "m" line and one retransmission session > "m" line, the grouping is then obvious and FID semantics MAY be > omitted in this special case only. > > This is illustrated in the following example, which is an SDP > description for a single original MPEG-4 stream and its > corresponding retransmission session: > > v=0 > o=mascha 2980675221 2980675778 IN IP4 at.home.ru > c=IN IP4 125.25.5.1 > m=video 49170 RTP/AVPF 96 > a=rtpmap:96 MP4V-ES/90000 > a=rtcp-fb:96 nack > a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F > m=video 49172 RTP/AVPF 97 > a=rtpmap:97 rtx/90000 > a=fmtp:97 apt=96;rtx-time=3000 > > > Rey, et al. [Page 18] > Internet Draft RTP Retransmission Payload Format February 2003 > > >8.8 SDP description with SSRC-multiplexing > > The following is an example of an SDP description for an RTP video > session using SSRC-multiplexing with similar parameters as in the > single-session example above: > > v=0 > o=mascha 2980675221 2980675778 IN IP4 at.home.ru > c=IN IP4 125.25.5.1 > m=video 49170 RTP/AVPF 96 97 > a=rtpmap:96 MP4V-ES/90000 > a=rtcp-fb:96 nack > a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F > a=rtpmap:97 rtx/90000 > a=fmtp:97 apt=96;rtx-time=3000 > > >9. RTSP considerations > > The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an > application-level protocol for control over the delivery of data > with real-time properties. This section looks at the issues > involved in controlling RTP sessions that use retransmissions. > >9.1 RTSP control with SSRC-multiplexing > > In the case of SSRC-multiplexing, the "m" line includes both > original and retransmission payload types and has a single RTSP > "control" attribute. The receiver uses the "m" line to request > SETUP and TEARDOWN of the whole media session. The RTP profile > contained in the transport header MUST be the AVPF profile or > another suitable profile allowing extended feedback. > > In order to control the sending of the session original media > stream, the receiver sends as usual PLAY and PAUSE requests to the > sender for the session. The RTP-info header that is used to set > RTP-specific parameters in the PLAY response MUST be set according > to the RTP information of the original stream. > > When the receiver starts receiving the original stream, it can then > request retransmission through RTCP NACKs without additional RTSP > signalling. > >9.2 RTSP control with session-multiplexing > > In the case of session-multiplexing, each SDP "m" line has an RTSP > "control" attribute. Hence, when retransmission is used, both the > original session and the retransmission have their own "control" > attributes. The receiver can associate the original session and the > retransmission session through the FID semantics as specified in > Section 8. > > > > Rey, et al. [Page 19] > Internet Draft RTP Retransmission Payload Format February 2003 > > > The original and the retransmission streams are set up and torn down > separately through their respective media "control" attribute. The > RTP profile contained in the transport header MUST be the AVPF > profile or another suitable profile allowing extended feedback for > both the original and the retransmission session. > > The RTSP presentation SHOULD support aggregate control and SHOULD > contain a session level RTSP URL. The receiver SHOULD use aggregate > control for an original session and its associated retransmission > session. Otherwise, there would need to be two different 'session- > id' values, i.e. different values for the original and > retransmission sessions, and the sender would not know how to > associate them. > > The session-level "control" attribute is then used as usual to > control the playing of the original stream. When the receiver > starts receiving the original stream, it can then request > retransmissions through RTCP without additional RTSP signalling. > >9.3 RTSP control of the retransmission stream > > Because of the nature of retransmissions, the sending of > retransmission packets SHOULD NOT be controlled through RTSP PLAY > and PAUSE requests. The PLAY and PAUSE requests should not affect > the retransmission stream. Retransmission packets are sent upon > receiver requests in the original RTCP stream, regardless of the > state. > >9.4 Cache control > > Retransmission streams SHOULD NOT be cached. > > In the case of session-multiplexing, the "Cache-Control" header > SHOULD be set to "no-cache" for the retransmission stream. > > In the case of SSRC-multiplexing, RTSP cannot specify independent > caching for the retransmission stream, because there is a single "m" > line in SDP. Therefore, the implementer should take this fact into > account when deciding whether to cache an SSRC-multiplexed session > or not. > > >10. Implementation examples > > This document mandates only the sender and receiver behaviours that > are necessary for interoperability. In addition, certain algorithms, > such as rate control or buffer management when targeted at specific > environments, may enhance the retransmission efficiency. > > This section gives an overview of different implementation options > allowed within this specification. > > > > Rey, et al. [Page 20] > Internet Draft RTP Retransmission Payload Format February 2003 > > > The first example describes a minimal receiver implementation. With > this implementation, it is possible to retransmit lost RTP packets, > detect efficiently the loss of retransmissions and perform multiple > retransmissions, if needed. Most of the necessary processing is done > at the server. > > The second example shows how a receiver may implement additional > enhancements that might help reduce sender buffer requirements and > optimise the retransmission efficiency > > The third example shows how retransmissions may be used in (small) > multicast groups in conjunction with layered encoding. It > illustrates that retransmissions and layered encoding may be > complementary techniques. > >10.1 A minimal receiver implementation example > > This section gives an example of an implementation supporting > multiple retransmissions. The sender transmits the original data in > RTP packets using the MPEG-4 video RTP payload format. > It is assumed that NACK feedback messages are used, as per > [1]. An SDP description example with SSRC-multiplexing is given > below: > > v=0 > o=mascha 2980675221 2980675778 IN IP4 at.home.ru > c=IN IP4 125.25.5.1 > m=video 49170 RTP/AVPF 96 97 > a=rtpmap:96 MP4V-ES/90000 > a=rtcp-fb:96 nack > a=rtpmap:97 rtx/90000 > a=fmtp:97 apt=96;rtx-time=3000 > > The format-specific parameter "rtx-time" indicates that the server > will buffer the sent packets in a retransmission buffer for 3.0 > seconds, after which the packets are deleted from the retransmission > buffer and will never be sent again. > > In this implementation example, the required RTP receiver processing > to handle retransmission is kept to a minimum. The receiver detects > packet loss from the gaps observed in the received sequence numbers. > It signals lost packets to the sender through NACKs as defined in the > AVPF profile [1]. The receiver should take into account the > signalled sender retransmission buffer length in order to dimension > its own reception buffer. It should also derive from the buffer > length the maximum number of times the retransmission of a packet can > be requested. > > The sender should retransmit the packets selectively, i.e. it should > choose whether to retransmit a requested packet depending on the > packet importance, the observed QoS and congestion state of the > network connection to the receiver. Obviously, the sender processing > > > Rey, et al. [Page 21] > Internet Draft RTP Retransmission Payload Format February 2003 > > > increases with the number of receivers as state information and > processing load must be allocated to each receiver. > >10.2 An enhanced receiver implementation example > > The receiver may have more accurate information than the sender about > the current network QoS such as available bandwidth, packet loss > rate, delay and jitter. In addition, other receiver-specific > parameters such as buffer level, estimated importance of the lost > packet and application level QoS may be used by the receiver to make > a more efficient use of RTP retransmission by selectively sending > NACKs for important lost packets and not for others. For example, a > receiver may decide to suppress a request for a packet loss that > could be concealed locally, or for a retransmission that would arrive > late. > > Furthermore, a receiver may acknowledge the received packets. This > can be done by sending ACKs, as per [1]. Upon receiving an ACK, the > sender may delete all the acknowledged packets from its > retransmission buffer. Note that this would also require only > limited increase in the required RTCP bandwidth as long as ACK > packets are sent seldom enough. > > This implementation may help reduce buffer requirements at the sender > and optimise the performance of the implementation by using selective > requests. > > Note that these receiver enhancements do not need to be negotiated as > they do not affect the sender implementation. However, in order to > allow the receiver to acknowledge packets, it is needed to allow the > use of ACKs in the SDP description, by means of an additional SDP > "a=rtcp-fb" line, as follows: > > v=0 > o=mascha 2980675221 2980675778 IN IP4 at.home.ru > c=IN IP4 125.25.5.1 > m=video 49170 RTP/AVPF 96 97 > a=rtpmap:96 MP4V-ES/90000 > a=rtcp-fb:96 nack > a=rtcp-fb:96 ack > a=rtpmap:97 rtx/90000 > a=fmtp:97 apt=96;rtx-time=3000 > >10.3 Retransmission of Layered Encoded Media in Multicast > > This section shows how to combine retransmissions with layered > encoding in multicast sessions. Note that the retransmission > framework is not intended as a complete solution to reliable > multicast. Refer to RFC 2887 [10], for an overview of the problems > related with reliable multicast transmission. > > Packets of different importance are sent in different RTP sessions. > The retransmission streams corresponding to the different layers can > > Rey, et al. [Page 22] > Internet Draft RTP Retransmission Payload Format February 2003 > > > themselves be seen as different retransmission layers. The relative > importance of the different retransmission streams should reflect the > relative importance of the different original streams. > > In multicast, SSRC-multiplexing of the original and retransmission > streams is not allowed as per Section 5.3 of this document. For this > reason, the retransmission stream(s) MUST be sent in different RTP > session(s) using session-multiplexing. > > An SDP description example of multicast retransmissions for layered > encoded media is given below: > > c=IN IP4 224.2.1.1/127/3 > m=video 8000 RTP/AVPF 98 > a=rtpmap:98 MP4V-ES/90000 > a=rtcp-fb:98 nack > c=IN IP4 224.2.1.4/127/3 > m=video 8000 RTP/AVPF 99 > a=rtpmap:99 rtx/90000 > a=fmtp:99 apt=98;rtx-time=3000 > > The server and the receiver may implement the retransmission methods > illustrated in the previous examples. In addition, they may choose > to request and retransmit a lost packet depending on the layer it > belongs to. > > >11. IANA considerations > > A new MIME subtype name, "rtx", has been registered. An additional > REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", > are defined. See Section 8 for details. > > >12. Security considerations > > Applications utilising encryption SHOULD encrypt both the original > and the retransmission stream. Old keys will likely need to be > cached so that when the keys change for the original stream, the old > key is used until it is determined that the key has changed on the > retransmission packets as well. > > The use of the same key for the retransmitted stream and the > original stream may lead to security problems, e.g. two-time pads. > This sharing has to be evaluated towards the chosen security > protocol and security algorithms. > > RTP recommends that the initial RTP timestamp SHOULD be random to > secure the stream against known plain text attacks. This payload > format does not follow this recommendation as the initial timestamp > will be the media timestamp of the first retransmitted packet. > > > > Rey, et al. [Page 23] > Internet Draft RTP Retransmission Payload Format February 2003 > > > However, since the initial timestamp of the original stream is > itself random, if the original stream is encrypted, the first > retransmitted packet timestamp would also be random to an attacker. > Therefore, confidentiality would not be compromised. > > Congestion control considerations with the use of retransmission are > dealt with in Section 7 of this document. > > Any other security considerations of the profile under which the > retransmission scheme is used should be applied. The retransmission > payload format MUST NOT be used under the SAVP profile defined by > the Secure Real-Time Transport Protocol (SRTP)[12] but instead an > extension of SRTP should be defined to secure the AVPF profile. The > definition of such a profile is out of the scope of this document. > > >13. Acknowledgements > > We would like to express our gratitude to Carsten Burmeister for his > participation in the development of this document. Our thanks also > go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, > Go Hori and Rahul Agarwal for their helpful comments. > > >14. References > >14.1 Normative References > > 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP > profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- > 04.txt, September 2002. > > 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997 > > 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > Transport Protocol for Real-Time Applications", draft-ietf-avt- > rtp-new-11.txt, May 2002. > > 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- > ietf-avt-rtcp-bw-05.txt, May 2002. > > 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC > 2327, April 1998. > > 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media lines > in the Session Description Protocol (SDP)", RFC 3388, December > 2002. > > 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol > (RTSP)", RFC 2326, April 1998. > > > > Rey, et al. [Page 24] > Internet Draft RTP Retransmission Payload Format February 2003 > > >14.2 Informative References > > 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", > RFC 2354, June 1998. > > 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 > > 10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk > Data Transfer", RFC 2887, August 2000. > > 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. > > 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. > Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", > draft-ietf-avt-srtp-05.txt, June 2002. > > >Author's Addresses > > Jose Rey rey@panasonic.de > Panasonic European Laboratories GmbH > Monzastr. 4c > D-63225 Langen, Germany > Phone: +49-6103-766-134 > Fax: +49-6103-766-166 > > David Leon david.leon@nokia.com > Nokia Research Center > 6000 Connection Drive > Irving, TX. USA > Phone: 1-972-374-1860 > > Akihiro Miyazaki akihiro@isl.mei.co.jp > Core Software Development Center > Corporate Software Development Division > Matsushita Electric Industrial Co., Ltd. > 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan > Phone: +81-6-6900-9192 > Fax: +81-6-6900-9193 > > Viktor Varsa viktor.varsa@nokia.com > Nokia Research Center > 6000 Connection Drive > Irving, TX. USA > Phone: 1-972-374-1861 > > Rolf Hakenberg hakenberg@panasonic.de > Panasonic European Laboratories GmbH > Monzastr. 4c > D-63225 Langen, Germany > Phone: +49-6103-766-162 > Fax: +49-6103-766-166 > > > Rey, et al. [Page 25] > Internet Draft RTP Retransmission Payload Format February 2003 > > > > Full Copyright Statement > > "Copyright (C) The Internet Society (date). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will > not be revoked by the Internet Society or its successors or > assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > > > > > > > > > > > > > > > > > > > > > > > > > Rey, et al. [Page 26] > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 4 15:26:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03408 for ; Tue, 4 Feb 2003 15:26:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KWCm21114 for avt-archive@odin.ietf.org; Tue, 4 Feb 2003 15:32:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KVaJ21092; Tue, 4 Feb 2003 15:31:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KUcJ21046 for ; Tue, 4 Feb 2003 15:30:38 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03366; Tue, 4 Feb 2003 15:24:29 -0500 (EST) Received: from tmima-w2k.cisco.com ([171.71.129.25]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h14KRvB7001040; Tue, 4 Feb 2003 12:27:57 -0800 (PST) Message-Id: <4.3.2.7.2.20030204095404.02329608@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Feb 2003 10:36:51 -0800 To: "Daniel Feldman" , "Tmima Koren (E-mail)" , , , From: Tmima Koren Cc: , In-Reply-To: <88BC9E379956AE4DB689CC5FF6F5A43D47E929@exchange.Ic4ic.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_54060374==_.ALT" Subject: [AVT] Re: TCRTP, L2TPHC and L2TPoAAL5 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=====================_54060374==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:07 PM 2/3/2003 +0200, Daniel Feldman wrote: > Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson, > Section 3.3.2 of the current TCRTP draft has a bandwidth comparison > table, including TCRTP over PPP and TCRTP over AAL5. > From the text I understand that: >a) TCRTP over PPP includes Header Compression only once, so the IP header >(20 bytes) is not compressed. This could be reduced by using the >COMPRESSED_NON_TCP format described in RFC2507 below the L2TPHC tunnel. The L2TP packet traverses multiple links between source and destination If some individual links on the path are point to point, it is possible to compress the L2TP IP header using IPHC But it's not like you can do IPHC at the source and have the packet go compressed all the way to the destination Once the packet is an L2TP packet it is a regular IP packet and it can be compressed on individual links like any other IP packet So I'm not sure we need to add this to the TCRTP draft Regards Tmima >b) TCRTP over AAL5 includes a 20-bytes IP header which could be reduced to >zero, if L2TPHC worked straight over AAL5. > > My questions are: >1) Can we add the scenario described in (a) to the TCRTP draft? >2) Is it possible to extend L2TPHC so it is compatible with L2TPoAAL5 >(RFC3355)? >3) Can we add this scenario to the TCRTP draft? > > Thanks in advance and regards, > > Daniel Feldman. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Daniel Feldman >System Architecture Group Manager, IC4IC Ltd. >office: +972 (4) 959-4644 ext. 121 >mobile: +972 (55) 99-0299 >fax: +972 (4) 959-4944 >web: http://www.ic4ic.com >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > --=====================_54060374==_.ALT Content-Type: text/html; charset="us-ascii" At 12:07 PM 2/3/2003 +0200, Daniel Feldman wrote:
    Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson,
    Section 3.3.2 of the current TCRTP draft has a bandwidth comparison table, including TCRTP over PPP and TCRTP over AAL5.
    From the text I understand that:
a) TCRTP over PPP includes Header Compression only once, so the IP header (20 bytes) is not compressed. This could be reduced by using the COMPRESSED_NON_TCP format described in RFC2507 below the L2TPHC tunnel.

The L2TP packet traverses multiple links between source and destination
If some individual links on the path are point to point, it is possible to compress the L2TP IP header using IPHC
But it's not like you can do IPHC at the source and have the packet go compressed all the way to the destination
Once the packet is an L2TP packet it is a regular IP packet and it can be compressed on individual links like any other IP packet
So I'm not sure we need to add this to the TCRTP draft
Regards
Tmima

b) TCRTP over AAL5 includes a 20-bytes IP header which could be reduced to zero, if L2TPHC worked straight over AAL5.
 
    My questions are:
1) Can we add the scenario described in (a) to the TCRTP draft?
2) Is it possible to extend L2TPHC so it is compatible with L2TPoAAL5 (RFC3355)?
3) Can we add this scenario to the TCRTP draft?
 
    Thanks in advance and regards,
 
        Daniel Feldman.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Architecture Group Manager, IC4IC Ltd.
office: +972 (4) 959-4644 ext. 121
mobile: +972 (55) 99-0299
fax:    +972 (4) 959-4944
web:     http://www.ic4ic.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--=====================_54060374==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 5 06:46:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19180 for ; Wed, 5 Feb 2003 06:46:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15BqBj17826 for avt-archive@odin.ietf.org; Wed, 5 Feb 2003 06:52:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BppJ17793; Wed, 5 Feb 2003 06:51:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BoCJ17700 for ; Wed, 5 Feb 2003 06:50:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18832; Wed, 5 Feb 2003 06:43:45 -0500 (EST) Message-Id: <200302051143.GAA18832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Feb 2003 06:43:45 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-05.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Retransmission Payload Format Author(s) : J. Rey et al. Filename : draft-ietf-avt-rtp-retransmission-05.txt Pages : 26 Date : 2003-2-4 RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback [1] ( denoted AVPF ), is available in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-retransmission-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-4133845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4133845.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 6 10:52:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23338 for ; Thu, 6 Feb 2003 10:52:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16FxCH10040 for avt-archive@odin.ietf.org; Thu, 6 Feb 2003 10:59:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FwRp09973; Thu, 6 Feb 2003 10:58:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FuKp09842 for ; Thu, 6 Feb 2003 10:56:20 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23170 for ; Thu, 6 Feb 2003 10:49:18 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h16Fqnap026618; Thu, 6 Feb 2003 07:52:49 -0800 (PST) Received: from MCGREWW2K (stealth-10-34-251-98.cisco.com [10.34.251.98]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADX50211; Thu, 6 Feb 2003 07:48:39 -0800 (PST) From: "David A. Mcgrew" To: "Jose Rey" , "Avt@Ietf. Org" Cc: , , , , Date: Thu, 6 Feb 2003 07:52:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit José, > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Thursday, January 23, 2003 8:35 AM > To: Avt@Ietf. Org > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > mcgrew@cisco.com; mats.naslund@era.ericsson.se; > karl.norrman@era.ericsson.se; oran@cisco.com > Subject: Security for draft-ietf-avt-rtp-retransmission > > > Hi all, > > we are doing the final edits to the draft-ietf-avt-rtp-retransmission. > We have considered all your comments until the date, but there's > something for which we would like to get some feedback on: security. > > A couple of questions: > > 1.-As discussed on the list: > ... > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > > Perkins > > Sent: Friday, January 10, 2003 4:39 AM > > To: David.Leon@nokia.com > > Cc: avt@ietf.org > > Subject: Re: [AVT] Comments on > > draft-ietf-avt-rtp-retransmission-04.txt > > > ...snip... > > > >> - In section 12, how does this draft affect SRTP? Is it > > possible to use > > >> the two formats together? > > > > > >We'll try to draft something on that. My understanding is that the > > >retransmission stream is seen as any other stream by SRTP > > and there should > > >thus be no problem. > > > > I was not clear if retransmitting packets caused problems for > > SRTP; maybe > > one of the SRTP authors can comment on any potential security issue? > > > > we don't see any problems (except for SRTCP as below in 2) to use SRTP > with RTX since the RTP retransmission packets (with a two byte > retransmission payload header) are seen by SRTP as 'normal' RTP packets. > Is our assumption correct? I think so. Certainly if the retransmission packets are treated as a separate session or separate stream with its own set of SRTP keys, then there's no problem. The only potential issue that I see is that the SRTP protection for the retransmission data will need to get keys (and other parameters) somehow. Is the plan to signal the retransmission session/stream at the same time as the original stream, but then only use it if it is needed? In that case, I'd expect that all the SRTP info for both streams/sessions would be provided by the signaling, which seems like it would work well. > > 2.-The retransmission payload format needs of the AVPF profile to enable > more frequent feedback and to request packets. This profile defines > (besides the new timing rules) some general-purpose messages such as > ACKs and NACKs and a new RTCP packet format: the early feedback packet, > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > there should be no problem to encrypt/authenticate early packets, > according to the SRTP draft: > > " > According to [RFC1889] there is a "recommended" packet format for > compound packets. SRTCP MUST be given packets according to that > recommendation in the sense that the first part MUST be a sender > report or a receiver report. However, the encryption prefix (Section > 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known > plaintext attacks, MUST NOT be used (see below). > " > > > Also there should be no problem to authenticate/encrypt ACKs and NACKs > with SRTCP since they are sent in compound RTCP packets starting with an > RR or SR packet. Let us know if you disagree with this point. > > > 3.- if a new profile needs be defined, something like "SAVPF", where > shall this profile "SAVPF" be specified and registered? wouldn't it be > reasonable to do this in the SRTP draft which already registers the > "SAVP" profile given that the feedback draft would (presumably) have a > similar schedule to the SRTP draft? In this way the question 2. could > also be anwered there. The SRTP draft is in IESG review, so at this point it wouldn't be appropriate to drag it back. But if the new profile is uncomplicated, it shouldn't be hard to throw together a new draft that references AVPF and SRTP to make SAVPF. Could you point me in the right direction as to what differences between AVP and AVPF would be important w.r.t. SRTP? > > 4.- the security section in the retransmission draft already points out > the risks of using the same keys across sessions, e.g. two.-time pads > and points to the SRTP for solutions. That much is done. Are we missing > something else? The draft says that "Applications utilising encryption SHOULD encrypt both the original and the retransmission stream." IIUC, it might be better to state that "If cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, SHOULD be provided on the retransmission stream." Also, I'm wondering why you would want a SHOULD and not a MUST here! Correct me if I'm wrong, but here's my mental picture of how the combined srtp/retransmission system would work: sender side ----------- original rtp source -+------------------> srtp encrypter (key1) ---> ... | +-> rexmit buffer -> srtp encrypter (key2) ---> ... Another approach would be to move the retransmission buffer to the other side of the srtp encrypter, and get rid of key2. This would be workable, since the original sequence number is provided in the retransmitted packet. However, this scheme would not provide message authentication on the retransmission packet flow. Another demerit of this scheme is that it would interact badly with the SRTP anti-replay window; the recommended size for this window is 128, and this scheme might require an even larger one. So I like the first method (the way I think that you're doing it) better! At any rate, it might be good to describe how you want the retransmission mechanism to work with SRTP or other crypto mechanisms, to avoid confusion down the road. > > 5.-It is also pointed out that the Timestamp of the retransmission > packets is the same as in the original packets. Since this is random it > should be no problem for security. Is this assumption correct? I think that the non-randomness of the initial timestamp of the retransmission stream is not an issue. The unpredictability of the initial RTP timestamp makes a DoS attack more difficult for an attacker who is not able to observe the RTP flow, but who knows the destination address, destination port number, and SSRC of that flow. The same argument could be made for the avt-rtp-retranmission mechanism. If the attacker can't see the original flow, she can't predict the initial timestamp of the retransmission flow. If she can see the original flow, then there is no protection provided by having random timestamp on either flow. So there is no disadvantage to the avt-rtp-retransmission mechanism's re-use of the initial timestamp. David > > Thanks in advance, > > > José > > > PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > Baugher's. Probably a cut&paste error. Or maybe a subtle identity theft? :-) David > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Feb 8 20:07:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04874 for ; Sat, 8 Feb 2003 20:07:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h191FW521130 for avt-archive@odin.ietf.org; Sat, 8 Feb 2003 20:15:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h191Eep21097; Sat, 8 Feb 2003 20:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18EQvp23799 for ; Sat, 8 Feb 2003 09:26:57 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22039 for ; Sat, 8 Feb 2003 09:18:58 -0500 (EST) Received: (from christos@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h18EMAQ29533; Sat, 8 Feb 2003 06:22:10 -0800 (PST) From: Christos Papadopoulos Message-Id: <200302081422.h18EMAQ29533@boreas.isi.edu> To: Cost264@lip6.fr, tccc@cs.columbia.edu, rmt@lbl.gov, mboned@network-services.uoregon.edu, avt@ietf.org, nanog@merit.edu, news-announce-conferences@uunet.uu.net, amlist@takilab.k.dendai.ac.jp, cfp@mmlab.snu.ac.kr, conf@colmar.uha.fr Date: Sat, 8 Feb 2003 06:22:10 -0800 (PST) Cc: multicomm@research.panasonic.com, cmgrc@cmg.org, end2end-interest@postel.org, ippm@advanced.org, itc@i-teletraffic.org, cost279@coruja.lx.it.pt, ppvpn@ppvpn.francetelecom.com, mmb@ira.uka.de, itg524@imst.de, itgfg523@comnets.rwth-aachen.de X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Final Call For Papers: NOSSDAV2003 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Our sincere apologies if you receive this multiple times] The 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2003) June 1-3, 2003 Monterey California, USA http://www.nossdav.org/2003 CALL FOR PAPERS Important Dates --------------- Submission Deadline (HARD): February 14, 2003 (midnight PST) Acceptance Notification : March 31, 2003 Camera Ready Deadline : April 25, 2003 Submissions ----------- Submissions are sought in any area related to Network and Operating Systems Support for Digital Audio and Video. The topics of interest include, but are not limited to: * ubiquitous multimedia services * peer-to-peer multimedia services * Internet telephony * broadband streaming media content distribution * 3D multimedia and (networked) immersive environments * interactive network games * wireless and ad-hoc network multimedia systems * multimedia information appliances and consumer devices * collaborative conferencing * wireless multimedia * access grids * embedded multimedia devices (e.g., PVRs) * multimedia security * sensory interactive applications * digital rights management We solicit submissions of 5-page extended abstracts of technical papers, work-in-progress reports, and position statements. Papers should identify new problems and explain why they are important, challenge conventional wisdom, advocate a specific solution, and/or report on actual experience with real systems. All submissions will be reviewed by the members of the program committee. Submissions will be selected on the basis of their originality, technical merit and topical relevance, as well as the likelihood that the ideas will lead to insightful technical discussions. Papers submitted to NOSSDAV must not have been published or submitted elsewhere. Please do not submit abbreviated versions of journal or conference papers. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. All submissions must be made through the web. We suggest that authors use the two-column ACM format for the submissions. Sincerely, The co-chairs, Christos Papadopoulos, USC, Kevin Almeroth, UCSB, Program Committee: ------------------ Sanjoy Paul Bell Labs Mostafa Ammar GeorgiaTech Supratik Bhattacharyya Sprint ATL Zongming Fei Univ of Kentucky Wu-chi Feng Oregon Graduate Institute Charles Kalmanek AT&T Labs Robin Kravets Univ of Illinios Ketan Mayer-Patel UNC Sue Moon Sprint ATL Jason Nieh Columbia Venkata Padmanabhan Microsoft Research Reza Rejaie AT&T Labs Colin Perkins ISI Larry Rowe UC-Berkeley Henning Schulzrinne Columbia Cormac Sreenan University College Cork David Yau Purdue University Daniel Zappala University of Oregon Leana Golubchick USC Clay Shields Georgetown University _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 10 09:44:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10759 for ; Mon, 10 Feb 2003 09:44:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AEr2I19681 for avt-archive@odin.ietf.org; Mon, 10 Feb 2003 09:53:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEq8p19637; Mon, 10 Feb 2003 09:52:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEltp19481 for ; Mon, 10 Feb 2003 09:47:55 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10518 for ; Mon, 10 Feb 2003 09:38:57 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h1AEgYdw004067; Mon, 10 Feb 2003 09:42:35 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302101442.h1AEgYdw004067@purple.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Mon, 10 Feb 2003 09:42:34 -0500 From: Colin Perkins Subject: [AVT] Meeting in San Francisco 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The AVT working group is scheduled for two slots at the 56th IETF meeting in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. Those wanting agenda time at the meeting should contact the working group chairs by 3rd March. Submitting a draft does not automatically provide agenda time. You are reminded that the cut-off date for -00 Internet Draft submissions is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior approval from the chairs, -00 submissions should have filenames with the format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts received after 24th February will not be accepted. All other Internet-Draft submissions must be made by Monday, 3rd March at 9:00am EST. Drafts which are submitted late and do not make the cutoff date will not be discussed at the meeting. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 12 15:05:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14295 for ; Wed, 12 Feb 2003 15:05:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CKEb417835 for avt-archive@odin.ietf.org; Wed, 12 Feb 2003 15:14:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKDlp17810; Wed, 12 Feb 2003 15:13:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKBkp17727 for ; Wed, 12 Feb 2003 15:11:46 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14129 for ; Wed, 12 Feb 2003 15:01:43 -0500 (EST) Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.11) id A9091480220; Wed, 12 Feb 2003 15:05:29 -0500 Reply-To: From: "Alan Clark" To: , "Timur Friedman \(E-mail\)" Subject: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-02.txt Date: Wed, 12 Feb 2003 15:03:57 -0500 Message-ID: <008b01c2d2d1$e0fd9c30$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Timur The 02 draft specifies signal and noise levels in terms of dBm0 with respect to overload conditions - I'd like to change this to dBm if this is not a problem for anyone, but retain the definitions for talkspurts vs silence periods. The revised definition would be signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. Signal level = 10 log 10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period back ground noise level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. Noise level = 10 log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. The goal of these metrics is to highlight excessively high or low signal levels as these can cause many other problems (e.g. with echo cancellers and voice activity detectors) and to identify if high levels of background noise are present. This is easier if we define the power levels separately for both talkspurts and silence periods - as it avoids the reported signal level value being affected by speech activity factor. I've spoken to a number of DSP software vendors and it seems that these values are readily available or can be derived from available data. Alan Clark _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 13 06:25:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09602 for ; Thu, 13 Feb 2003 06:25:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBZ7E12755 for avt-archive@odin.ietf.org; Thu, 13 Feb 2003 06:35:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBYdp12719; Thu, 13 Feb 2003 06:34:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBX6p12665 for ; Thu, 13 Feb 2003 06:33:06 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09570 for ; Thu, 13 Feb 2003 06:22:44 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1DBQRVR028603 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Thu, 13 Feb 2003 12:26:28 +0100 X-pt: isis.lip6.fr Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1DBQR327673; Thu, 13 Feb 2003 12:26:27 +0100 (MET) From: "Timur Friedman" To: , Subject: RE : [AVT] Comments on draft-ietf-avt-rtcp-report-extns-02.txt Date: Thu, 13 Feb 2003 12:26:29 +0100 Message-ID: <000b01c2d352$c0d308b0$a648e384@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <008b01c2d2d1$e0fd9c30$6801a8c0@telchemy.com> X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DBX6p12666 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit OK, I will wait to see if there is comment, and incorporate the change accordingly. - Timur -----Message d'origine----- De : avt-admin@ietf.org [mailto:avt-admin@ietf.org] De la part de Alan Clark Envoyé : mercredi 12 février 2003 21:04 À : avt@ietf.org; Timur Friedman (E-mail) Objet : [AVT] Comments on draft-ietf-avt-rtcp-report-extns-02.txt Timur The 02 draft specifies signal and noise levels in terms of dBm0 with respect to overload conditions - I'd like to change this to dBm if this is not a problem for anyone, but retain the definitions for talkspurts vs silence periods. The revised definition would be signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. Signal level = 10 log 10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period back ground noise level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. Noise level = 10 log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. The goal of these metrics is to highlight excessively high or low signal levels as these can cause many other problems (e.g. with echo cancellers and voice activity detectors) and to identify if high levels of background noise are present. This is easier if we define the power levels separately for both talkspurts and silence periods - as it avoids the reported signal level value being affected by speech activity factor. I've spoken to a number of DSP software vendors and it seems that these values are readily available or can be derived from available data. Alan Clark _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 13 13:18:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20859 for ; Thu, 13 Feb 2003 13:18:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DILMg08297 for avt-archive@odin.ietf.org; Thu, 13 Feb 2003 13:21:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIKvp08276; Thu, 13 Feb 2003 13:20:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIIep08114 for ; Thu, 13 Feb 2003 13:18:40 -0500 Received: from nwd2mime2.analog.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20769 for ; Thu, 13 Feb 2003 13:14:53 -0500 (EST) Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Thu, 13 Feb 2003 13:18:28 -0500 Received: from nwd2mhb2 ([137.71.6.12]) by nwd2gtw1; Thu, 13 Feb 2003 13:18:27 -0500 (EST) Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id NAA05702 for ; Thu, 13 Feb 2003 13:18:25 -0500 (EST) Received: from analog.com (dhcp10 [137.71.139.75]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id KAA06354 for ; Thu, 13 Feb 2003 10:17:52 -0800 (PST) Message-ID: <3E4BE163.9070005@analog.com> Date: Thu, 13 Feb 2003 10:18:11 -0800 From: harikrishna vuppaladhadiam Reply-To: harikrishna.vuppaladhadiam@analog.com Organization: analog devices User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org References: <000b01c2d352$c0d308b0$a648e384@lip6.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] certification agencies 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello All, Are there any cetification agencies to validate H.323, SIP protocol based IADs or IP Phones ? Regards Hari V _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 13 23:14:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29295 for ; Thu, 13 Feb 2003 23:14:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E4IGM13355 for avt-archive@odin.ietf.org; Thu, 13 Feb 2003 23:18:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E4HYp13329; Thu, 13 Feb 2003 23:17:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E4Fcp13267 for ; Thu, 13 Feb 2003 23:15:38 -0500 Received: from mail2.hosting.bora.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29262 for ; Thu, 13 Feb 2003 23:11:28 -0500 (EST) Received: (qmail 664 invoked from network); 14 Feb 2003 04:15:10 -0000 Received: from unknown (HELO Young) (211.235.239.16) by mail2.hosting.bora.net with SMTP; 14 Feb 2003 04:15:10 -0000 Message-ID: <019e01c2d3df$aa8a8e10$b27eedd3@Young> Reply-To: "LIM, Young-Kwon" From: "LIM, Young-Kwon" To: , "Colin Perkins" Cc: , References: <200302101442.h1AEgYdw004067@purple.nge.isi.edu> Date: Fri, 14 Feb 2003 13:15:10 +0900 Organization: net&tv Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h1E4Fcp13268 Subject: [AVT] mpeg4-simple 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Colin and all, Could you inform me about the current status of mpeg4-simple payload format in IETF? I remeber that there was a revision for IESG last call a few months ago? Do you expect that there will be a call very soon? Are there any remaining issues need another revision? Sincerely, Young. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 14 05:32:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15631 for ; Fri, 14 Feb 2003 05:32:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EAaXt13925 for avt-archive@odin.ietf.org; Fri, 14 Feb 2003 05:36:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EAa5p13912; Fri, 14 Feb 2003 05:36:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EAYip13865 for ; Fri, 14 Feb 2003 05:34:44 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15609; Fri, 14 Feb 2003 05:30:26 -0500 (EST) From: jan.vandermeer@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 5CA2E953FD; Fri, 14 Feb 2003 11:34:11 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA10757; Fri, 14 Feb 2003 11:34:10 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA09096; Fri, 14 Feb 2003 11:34:09 +0100 (MET) To: "LIM, Young-Kwon" Cc: avt@ietf.org, avt-admin@ietf.org, casner@acm.org, "Colin Perkins" Subject: Re: [AVT] mpeg4-simple MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 14 Feb 2003 11:32:16 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 14/02/2003 11:32:19, Serialize complete at 14/02/2003 11:32:19 Content-Type: multipart/alternative; boundary="=_alternative 003A0D59C1256CCD_=" 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 003A0D59C1256CCD_= Content-Type: text/plain; charset="us-ascii" Young, I am about to produce rev7, intended to be the final one. Best regards / Groeten, Jan "LIM, Young-Kwon" Sent by: avt-admin@ietf.org 2003-02-14 05:15 AM Please respond to "LIM, Young-Kwon" To: "Colin Perkins" cc: Jan vanderMeer/EHV/CE/PHILIPS@EMEA3 Subject: [AVT] mpeg4-simple Classification: Hi Colin and all, Could you inform me about the current status of mpeg4-simple payload format in IETF? I remeber that there was a revision for IESG last call a few months ago? Do you expect that there will be a call very soon? Are there any remaining issues need another revision? Sincerely, Young. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 003A0D59C1256CCD_= Content-Type: text/html; charset="us-ascii"
Young,

I am about to produce rev7, intended to be the final one.

Best regards / Groeten,

Jan








"LIM, Young-Kwon" <young@netntv.co.kr>

Sent by:
avt-admin@ietf.org

2003-02-14 05:15 AM
Please respond to "LIM, Young-Kwon"

       
        To:        <avt@ietf.org>
"Colin Perkins" <csp@csperkins.org>
        cc:        <casner@acm.org>
Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
        Subject:        [AVT] mpeg4-simple

        Classification:        




Hi Colin and all,

Could you inform me about the current status of mpeg4-simple payload format in IETF? I remeber that there was a revision for IESG last call a few months ago? Do you expect that there will be a call very soon? Are there any remaining issues need another revision?

Sincerely,
Young.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 003A0D59C1256CCD_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Feb 16 02:12:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23045 for ; Sun, 16 Feb 2003 02:12:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1G7Gha18255 for avt-archive@odin.ietf.org; Sun, 16 Feb 2003 02:16:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G7FMp18220; Sun, 16 Feb 2003 02:15:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E9kxp11287 for ; Fri, 14 Feb 2003 04:46:59 -0500 Received: from maillog.itri.org.tw (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14693 for ; Fri, 14 Feb 2003 04:42:50 -0500 (EST) Received: from mail.itri.org.tw (mail.itri.org.tw [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id h1E9jYe14275 for ; Fri, 14 Feb 2003 17:45:34 +0800 (CST) Received: from ms2.itri.org.tw ([140.96.151.157]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id h1E9hGv10649 for ; Fri, 14 Feb 2003 17:43:16 +0800 (CST) Received: from dabearnb ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.11) with ESMTP id 2003021417403327:6418 ; Fri, 14 Feb 2003 17:40:33 +0800 From: "Guan-Hsiung Liaw" To: Date: Fri, 14 Feb 2003 17:40:08 +0800 Message-ID: <001801c2d40d$10023a40$4467608c@ccl.itri.org.tw> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2003-02-14 05:40:33 PM, Serialize by Router on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2003-02-14 05:44:55 PM, Serialize complete at 2003-02-14 05:44:55 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C2D450.1E257A40" Subject: [AVT] Is there any TCRTP Implementation now? 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C2D450.1E257A40 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi,=20 Is there any software implementation of TCRTP now? Where can I find them? =20 Thanks a lot. =20 Have a nice day !! -- Guan-Hsiung Liaw (=B9=F9=ABa=B6=AF) =20 Section Manager Dept. K300, Computer and Communications Research Lab. (CCL) Industrial Technology Research Institute (ITRI) =20 K300 CCL/ITRI, Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd. Chutung, Hsinchu, Taiwan 310, R.O.C. Tel: 886-3-5917247 Fax: 886-3-5825424 E-mail: ghliaw@itri.org.tw =20 ------=_NextPart_000_0019_01C2D450.1E257A40 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hi,

Is there any software implementation of TCRTP = now?

Where can I find them?

 

Thanks a lot.

 

Have a nice day !!

--

Guan-Hsiung Liaw (=B9=F9=ABa=B6= =AF)

 

Section Manager

Dept. K300, Computer and Communications Research Lab. = (CCL)

Industrial Technology Research Institute = (ITRI)

 

K300 CCL/ITRI, Bldg. 51, 195-11 Sec. 4, = Chung Hsing = Rd.

Chutung, Hsinchu, Taiwan 310, R.O.C.

Tel: 886-3-5917247

Fax: 886-3-5825424

E-mail: ghliaw@itri.org.tw

 

------=_NextPart_000_0019_01C2D450.1E257A40-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Feb 16 08:57:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26305 for ; Sun, 16 Feb 2003 08:57:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1GE1kG08222 for avt-archive@odin.ietf.org; Sun, 16 Feb 2003 09:01:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GE0pp08183; Sun, 16 Feb 2003 09:00:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GDvtp08077 for ; Sun, 16 Feb 2003 08:57:55 -0500 Received: from exchange.Ic4ic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26266 for ; Sun, 16 Feb 2003 08:52:30 -0500 (EST) Received: through eSafe SMTP Relay 1040832187; Sun Feb 16 16:54:40 2003 Content-Class: urn:content-classes:message Subject: RE: [AVT] Is there any TCRTP Implementation now? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D5C3.2E4033F6" Date: Sun, 16 Feb 2003 15:56:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D30862F@exchange.Ic4ic.com> Thread-Topic: [AVT] Is there any TCRTP Implementation now? Thread-Index: AcLVjhs7RHb6BNioTf+j+AMm+yWpMAANMfNw From: "Daniel Feldman" To: "Guan-Hsiung Liaw" , Cc: "Rafi Philosoph" , "Yosi Mazor" , "Ami Kraft" , "Dov Alon" , "Alex Trigub" 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D5C3.2E4033F6 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear Mr. Guan-Hsiung Liaw, my company has HW acceleration for TCRTP. I'll be happy to give you any information you require. Regards, Daniel Feldman. -----Original Message----- From: Guan-Hsiung Liaw [mailto:ghliaw@itri.org.tw] Sent: Friday, February 14, 2003 11:40 AM To: avt@ietf.org Subject: [AVT] Is there any TCRTP Implementation now? Hi,=20 Is there any software implementation of TCRTP now? Where can I find them? =20 Thanks a lot. =20 Have a nice day !! -- Guan-Hsiung Liaw (=B9=F9=ABa=B6=AF) =20 Section Manager Dept. K300, Computer and Communications Research Lab. (CCL) Industrial Technology Research Institute (ITRI) =20 K300 CCL/ITRI, Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd. Chutung, Hsinchu, Taiwan 310, R.O.C. Tel: 886-3-5917247 Fax: 886-3-5825424 E-mail: ghliaw@itri.org.tw =20 ------_=_NextPart_001_01C2D5C3.2E4033F6 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
    Dear Mr. Guan-Hsiung=20 Liaw,
    my company has HW acceleration for TCRTP. I'll b= e happy to=20 give you any information you require.
    Regards,
    Daniel Feldman.
-----Original Message-----
From: Guan-Hsiung Liaw=20 [mailto:ghliaw@itri.org.tw]
Sent: Friday, February 14, 2003 1= 1:40=20 AM
To: avt@ietf.org
Subject: [AVT] Is there any TCR= TP=20 Implementation now?

Hi,

Is there any software=20 implementation of TCRTP now?

Where can I find=20 them?

 

Thanks a lot.

 

Have a nice day !!

--

Guan-Hsiung Liaw (=B9=F9=ABa=B6=AF)

 

Section Manager

Dept. K300, Computer and Communications Research Lab.=20 (CCL)

Industrial Technology Research Institute=20 (ITRI)

 

K300 CCL/ITRI, Bldg. 51, 195-11 Sec. 4,=20 Chung=20 Hsing Rd.

Chutung, Hsinchu, Taiwan 310, R.O.C.

Tel: 886-3-5917247

Fax: 886-3-5825424

E-mail: ghliaw@itri.org.tw

 

------_=_NextPart_001_01C2D5C3.2E4033F6-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 17 10:41:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24216 for ; Mon, 17 Feb 2003 10:41:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HFl3Z02061 for avt-archive@odin.ietf.org; Mon, 17 Feb 2003 10:47:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HFkXp02034; Mon, 17 Feb 2003 10:46:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HFiTp01961 for ; Mon, 17 Feb 2003 10:44:29 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24180 for ; Mon, 17 Feb 2003 10:38:48 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HAG00HREM948W@panasonic.de> for avt@ietf.org; Mon, 17 Feb 2003 16:41:31 +0100 (MET) Date: Mon, 17 Feb 2003 16:41:29 +0100 From: Jose Rey Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission In-reply-to: To: "David A. Mcgrew" , "Avt@Ietf. Org" Cc: mbaugher@cisco.com, elisabetta.carrara@era.ericsson.se, mats.naslund@era.ericsson.se, karl.norrman@era.ericsson.se, oran@cisco.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8BIT 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT David, thanks for your comments, please see inline. > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of David > A. Mcgrew > Sent: Thursday, February 06, 2003 4:53 PM > To: Jose Rey; Avt@Ietf. Org > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; > oran@cisco.com > Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission > > > José, > > > -----Original Message----- > > From: Jose Rey [mailto:rey@panasonic.de] > > Sent: Thursday, January 23, 2003 8:35 AM > > To: Avt@Ietf. Org > > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > > mcgrew@cisco.com; mats.naslund@era.ericsson.se; > > karl.norrman@era.ericsson.se; oran@cisco.com > > Subject: Security for draft-ietf-avt-rtp-retransmission > > > > > > Hi all, > > > > we are doing the final edits to the > draft-ietf-avt-rtp-retransmission. > > We have considered all your comments until the date, but there's > > something for which we would like to get some feedback on: security. > > > > A couple of questions: > > > > 1.-As discussed on the list: > > ... > > > -----Original Message----- > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > Behalf Of Colin > > > Perkins > > > Sent: Friday, January 10, 2003 4:39 AM > > > To: David.Leon@nokia.com > > > Cc: avt@ietf.org > > > Subject: Re: [AVT] Comments on > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > > ...snip... > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > possible to use > > > >> the two formats together? > > > > > > > >We'll try to draft something on that. My understanding > is that the > > > >retransmission stream is seen as any other stream by SRTP > > > and there should > > > >thus be no problem. > > > > > > I was not clear if retransmitting packets caused problems for > > > SRTP; maybe > > > one of the SRTP authors can comment on any potential > security issue? > > > > > > > we don't see any problems (except for SRTCP as below in 2) > to use SRTP > > with RTX since the RTP retransmission packets (with a two byte > > retransmission payload header) are seen by SRTP as 'normal' > RTP packets. > > Is our assumption correct? > > I think so. Certainly if the retransmission packets are > treated as a separate > session or separate stream with its own set of SRTP keys, > then there's no > problem. Fine. > The only potential issue that I see is that the > SRTP protection for > the retransmission data will need to get keys (and other > parameters) somehow. > Is the plan to signal the retransmission session/stream at > the same time as the > original stream, but then only use it if it is needed? In > that case, I'd expect > that all the SRTP info for both streams/sessions would be > provided by the > signaling, which seems like it would work well. > This is also my understanding. > > > > 2.-The retransmission payload format needs of the AVPF > profile to enable > > more frequent feedback and to request packets. This profile defines > > (besides the new timing rules) some general-purpose messages such as > > ACKs and NACKs and a new RTCP packet format: the early > feedback packet, > > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > > there should be no problem to encrypt/authenticate early packets, > > according to the SRTP draft: > > > > " > > According to [RFC1889] there is a "recommended" packet format for > > compound packets. SRTCP MUST be given packets according to that > > recommendation in the sense that the first part MUST be a sender > > report or a receiver report. However, the encryption > prefix (Section > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > deter known > > plaintext attacks, MUST NOT be used (see below). > > " > > > > > > Also there should be no problem to authenticate/encrypt > ACKs and NACKs > > with SRTCP since they are sent in compound RTCP packets > starting with an > > RR or SR packet. Let us know if you disagree with this point. > > > > > > 3.- if a new profile needs be defined, something like "SAVPF", where > > shall this profile "SAVPF" be specified and registered? > wouldn't it be > > reasonable to do this in the SRTP draft which already registers the > > "SAVP" profile given that the feedback draft would > (presumably) have a > > similar schedule to the SRTP draft? In this way the > question 2. could > > also be anwered there. > > The SRTP draft is in IESG review, so at this point it > wouldn't be appropriate to > drag it back. Yes, I understand. > But if the new profile is uncomplicated, it > shouldn't be hard to > throw together a new draft that references AVPF and SRTP to > make SAVPF. Could > you point me in the right direction as to what differences > between AVP and AVPF > would be important w.r.t. SRTP? > AVPF introduces new feedback messages ACKs/NACKs and application layer messages which, as concluded above, don't represent any problem for SRTP. This is because the RTCP packets used by AVPF-compliant entities also use the "recommended" RTCP packet format as in RTP, thus not being a problem (see point 2 above). The other major change is that the AVPF profile abolishes the 5-second rule; this shouldn't be a problem for SRTP either (?) > > > > 4.- the security section in the retransmission draft > already points out > > the risks of using the same keys across sessions, e.g. > two.-time pads > > and points to the SRTP for solutions. That much is done. > Are we missing > > something else? > > The draft says that "Applications utilising encryption SHOULD > encrypt both the > original and the retransmission stream." IIUC, it might > be better to state > that "If cryptography is used to provide security services on > the original > stream, then the same services, with equivalent cryptographic > strength, SHOULD > be provided on the retransmission stream." Also, I'm > wondering why you would > want a SHOULD and not a MUST here! > Right, thanks for the rewording. I like a MUST instead better. > Correct me if I'm wrong, but here's my mental picture of how > the combined > srtp/retransmission system would work: > > sender side > ----------- > > original rtp source -+------------------> srtp encrypter > (key1) ---> ... > | > +-> rexmit buffer -> srtp encrypter > (key2) ---> ... > > Another approach would be to move the retransmission buffer > to the other side of > the srtp encrypter, and get rid of key2. This would be > workable, since the > original sequence number is provided in the retransmitted > packet. However, this > scheme would not provide message authentication on the > retransmission packet > flow. Another demerit of this scheme is that it would > interact badly with the > SRTP anti-replay window; the recommended size for this window > is 128, and this > scheme might require an even larger one. So I like the first > method (the way I > think that you're doing it) better! > > At any rate, it might be good to describe how you want the > retransmission > mechanism to work with SRTP or other crypto mechanisms, to > avoid confusion down > the road. The 1st possibility as depicted by you is the one we have in mind. Your other "option" could be given as an example of what not to do and why. This would rule out possible questions. > > > > > 5.-It is also pointed out that the Timestamp of the retransmission > > packets is the same as in the original packets. Since this > is random it > > should be no problem for security. Is this assumption correct? > > I think that the non-randomness of the initial timestamp of > the retransmission > stream is not an issue. The unpredictability of the initial > RTP timestamp makes > a DoS attack more difficult for an attacker who is not able > to observe the RTP > flow, but who knows the destination address, destination port > number, and SSRC > of that flow. The same argument could be made for the > avt-rtp-retranmission > mechanism. If the attacker can't see the original flow, she > can't predict the > initial timestamp of the retransmission flow. If she can see > the original flow, > then there is no protection provided by having random > timestamp on either flow. > So there is no disadvantage to the avt-rtp-retransmission > mechanism's re-use of > the initial timestamp. > OK. Now, I got a question: as discussed in previous emails (see the email from Elisabetta), in the case of SSRC-multiplexing the same master key might be used for both streams since the SSRC is unique among the streams. In the original packets the SN is sent in the header, thus accessible. However in the retransmission packets, the retransmission payload header (the two bytes containing the original SN, OSN) is sent encrypted and its location is known: right after the RTP header before the payload. Since both original and retransmission packets have the same TS, an attacker could easily identify an original packet and its retransmission by comparing the TS. Once this is done he could easily see how the cleartext SN is encrypted. Now, I am not a security expert but, intuitively, this is not secure. Is it not a security threat? Does SRTP solve this? thanks, José _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 17 19:49:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04885 for ; Mon, 17 Feb 2003 19:49:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1I0tAq04057 for avt-archive@odin.ietf.org; Mon, 17 Feb 2003 19:55:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1I0iXp03796; Mon, 17 Feb 2003 19:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1I0fKp03704 for ; Mon, 17 Feb 2003 19:41:20 -0500 Received: from copper.hf.tvia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04791 for ; Mon, 17 Feb 2003 19:35:22 -0500 (EST) Date: Tue, 18 Feb 2003 08:39:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: avt digest, Vol 1 #562 - 1 msg Thread-Index: AcLWphLFBygR7p4MSYGpvkA3vc1MBwAP/Muw From: "Hanyi Wu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1I0fKp03705 Subject: [AVT] ??: avt digest, Vol 1 #562 - 1 msg 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit thanks, please don't send the mail any more -----????----- ???: avt-request@ietf.org [mailto:avt-request@ietf.org] ????: 2003?2?18? 01:00 ???: avt@ietf.org ??: avt digest, Vol 1 #562 - 1 msg Send avt mailing list submissions to avt@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/avt or, via email, send a message with subject or body 'help' to avt-request@ietf.org You can reach the person managing the list at avt-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of avt digest..." Today's Topics: 1. RE: RE: Security for draft-ietf-avt-rtp-retransmission (Jose Rey) --__--__-- Message: 1 Date: Mon, 17 Feb 2003 16:41:29 +0100 From: Jose Rey Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission To: "David A. Mcgrew" , "Avt@Ietf. Org" Cc: mbaugher@cisco.com, elisabetta.carrara@era.ericsson.se, mats.naslund@era.ericsson.se, karl.norrman@era.ericsson.se, oran@cisco.com David, thanks for your comments, please see inline. > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of David > A. Mcgrew > Sent: Thursday, February 06, 2003 4:53 PM > To: Jose Rey; Avt@Ietf. Org > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; > oran@cisco.com > Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission > > > José, > > > -----Original Message----- > > From: Jose Rey [mailto:rey@panasonic.de] > > Sent: Thursday, January 23, 2003 8:35 AM > > To: Avt@Ietf. Org > > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > > mcgrew@cisco.com; mats.naslund@era.ericsson.se; > > karl.norrman@era.ericsson.se; oran@cisco.com > > Subject: Security for draft-ietf-avt-rtp-retransmission > > > > > > Hi all, > > > > we are doing the final edits to the > draft-ietf-avt-rtp-retransmission. > > We have considered all your comments until the date, but there's > > something for which we would like to get some feedback on: security. > > > > A couple of questions: > > > > 1.-As discussed on the list: > > ... > > > -----Original Message----- > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > Behalf Of Colin > > > Perkins > > > Sent: Friday, January 10, 2003 4:39 AM > > > To: David.Leon@nokia.com > > > Cc: avt@ietf.org > > > Subject: Re: [AVT] Comments on > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > > ...snip... > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > possible to use > > > >> the two formats together? > > > > > > > >We'll try to draft something on that. My understanding > is that the > > > >retransmission stream is seen as any other stream by SRTP > > > and there should > > > >thus be no problem. > > > > > > I was not clear if retransmitting packets caused problems for > > > SRTP; maybe > > > one of the SRTP authors can comment on any potential > security issue? > > > > > > > we don't see any problems (except for SRTCP as below in 2) > to use SRTP > > with RTX since the RTP retransmission packets (with a two byte > > retransmission payload header) are seen by SRTP as 'normal' > RTP packets. > > Is our assumption correct? > > I think so. Certainly if the retransmission packets are > treated as a separate > session or separate stream with its own set of SRTP keys, > then there's no > problem. Fine. > The only potential issue that I see is that the > SRTP protection for > the retransmission data will need to get keys (and other > parameters) somehow. > Is the plan to signal the retransmission session/stream at > the same time as the > original stream, but then only use it if it is needed? In > that case, I'd expect > that all the SRTP info for both streams/sessions would be > provided by the > signaling, which seems like it would work well. > This is also my understanding. > > > > 2.-The retransmission payload format needs of the AVPF > profile to enable > > more frequent feedback and to request packets. This profile defines > > (besides the new timing rules) some general-purpose messages such as > > ACKs and NACKs and a new RTCP packet format: the early > feedback packet, > > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > > there should be no problem to encrypt/authenticate early packets, > > according to the SRTP draft: > > > > " > > According to [RFC1889] there is a "recommended" packet format for > > compound packets. SRTCP MUST be given packets according to that > > recommendation in the sense that the first part MUST be a sender > > report or a receiver report. However, the encryption > prefix (Section > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > deter known > > plaintext attacks, MUST NOT be used (see below). > > " > > > > > > Also there should be no problem to authenticate/encrypt > ACKs and NACKs > > with SRTCP since they are sent in compound RTCP packets > starting with an > > RR or SR packet. Let us know if you disagree with this point. > > > > > > 3.- if a new profile needs be defined, something like "SAVPF", where > > shall this profile "SAVPF" be specified and registered? > wouldn't it be > > reasonable to do this in the SRTP draft which already registers the > > "SAVP" profile given that the feedback draft would > (presumably) have a > > similar schedule to the SRTP draft? In this way the > question 2. could > > also be anwered there. > > The SRTP draft is in IESG review, so at this point it > wouldn't be appropriate to > drag it back. Yes, I understand. > But if the new profile is uncomplicated, it > shouldn't be hard to > throw together a new draft that references AVPF and SRTP to > make SAVPF. Could > you point me in the right direction as to what differences > between AVP and AVPF > would be important w.r.t. SRTP? > AVPF introduces new feedback messages ACKs/NACKs and application layer messages which, as concluded above, don't represent any problem for SRTP. This is because the RTCP packets used by AVPF-compliant entities also use the "recommended" RTCP packet format as in RTP, thus not being a problem (see point 2 above). The other major change is that the AVPF profile abolishes the 5-second rule; this shouldn't be a problem for SRTP either (?) > > > > 4.- the security section in the retransmission draft > already points out > > the risks of using the same keys across sessions, e.g. > two.-time pads > > and points to the SRTP for solutions. That much is done. > Are we missing > > something else? > > The draft says that "Applications utilising encryption SHOULD > encrypt both the > original and the retransmission stream." IIUC, it might > be better to state > that "If cryptography is used to provide security services on > the original > stream, then the same services, with equivalent cryptographic > strength, SHOULD > be provided on the retransmission stream." Also, I'm > wondering why you would > want a SHOULD and not a MUST here! > Right, thanks for the rewording. I like a MUST instead better. > Correct me if I'm wrong, but here's my mental picture of how > the combined > srtp/retransmission system would work: > > sender side > ----------- > > original rtp source -+------------------> srtp encrypter > (key1) ---> ... > | > +-> rexmit buffer -> srtp encrypter > (key2) ---> ... > > Another approach would be to move the retransmission buffer > to the other side of > the srtp encrypter, and get rid of key2. This would be > workable, since the > original sequence number is provided in the retransmitted > packet. However, this > scheme would not provide message authentication on the > retransmission packet > flow. Another demerit of this scheme is that it would > interact badly with the > SRTP anti-replay window; the recommended size for this window > is 128, and this > scheme might require an even larger one. So I like the first > method (the way I > think that you're doing it) better! > > At any rate, it might be good to describe how you want the > retransmission > mechanism to work with SRTP or other crypto mechanisms, to > avoid confusion down > the road. The 1st possibility as depicted by you is the one we have in mind. Your other "option" could be given as an example of what not to do and why. This would rule out possible questions. > > > > > 5.-It is also pointed out that the Timestamp of the retransmission > > packets is the same as in the original packets. Since this > is random it > > should be no problem for security. Is this assumption correct? > > I think that the non-randomness of the initial timestamp of > the retransmission > stream is not an issue. The unpredictability of the initial > RTP timestamp makes > a DoS attack more difficult for an attacker who is not able > to observe the RTP > flow, but who knows the destination address, destination port > number, and SSRC > of that flow. The same argument could be made for the > avt-rtp-retranmission > mechanism. If the attacker can't see the original flow, she > can't predict the > initial timestamp of the retransmission flow. If she can see > the original flow, > then there is no protection provided by having random > timestamp on either flow. > So there is no disadvantage to the avt-rtp-retransmission > mechanism's re-use of > the initial timestamp. > OK. Now, I got a question: as discussed in previous emails (see the email from Elisabetta), in the case of SSRC-multiplexing the same master key might be used for both streams since the SSRC is unique among the streams. In the original packets the SN is sent in the header, thus accessible. However in the retransmission packets, the retransmission payload header (the two bytes containing the original SN, OSN) is sent encrypted and its location is known: right after the RTP header before the payload. Since both original and retransmission packets have the same TS, an attacker could easily identify an original packet and its retransmission by comparing the TS. Once this is done he could easily see how the cleartext SN is encrypted. Now, I am not a security expert but, intuitively, this is not secure. Is it not a security threat? Does SRTP solve this? thanks, José --__--__-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt End of avt Digest _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 18 03:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22552 for ; Tue, 18 Feb 2003 03:57:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1I92je09676 for avt-archive@odin.ietf.org; Tue, 18 Feb 2003 04:02:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1I92Cp09657; Tue, 18 Feb 2003 04:02:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1I90vp09286 for ; Tue, 18 Feb 2003 04:00:57 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22495 for ; Tue, 18 Feb 2003 03:54:55 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA19543; Tue, 18 Feb 2003 09:58:42 +0100 (MET) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA15376; Tue, 18 Feb 2003 09:58:43 +0100 (MET) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Feb 2003 09:58:43 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'harikrishna.vuppaladhadiam@analog.com'" , avt@ietf.org, Euchner Martin ICN M SR 3 Subject: RE: [AVT] certification agencies Date: Tue, 18 Feb 2003 09:58:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IMTC has been doing H.323 interop testing and also some SIP interop testing; they are now looking into certification of H.323 systems; see www.imtc.org With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: harikrishna vuppaladhadiam [mailto:harikrishna.vuppaladhadiam@analog.com] Sent: Thursday, February 13, 2003 7:18 PM To: avt@ietf.org Subject: [AVT] certification agencies Hello All, Are there any cetification agencies to validate H.323, SIP protocol based IADs or IP Phones ? Regards Hari V _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 18 05:29:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24281 for ; Tue, 18 Feb 2003 05:29:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IAYgd15455 for avt-archive@odin.ietf.org; Tue, 18 Feb 2003 05:34:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IAYIp15433; Tue, 18 Feb 2003 05:34:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IAWVp15364 for ; Tue, 18 Feb 2003 05:32:31 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24222; Tue, 18 Feb 2003 05:26:28 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA29243; Tue, 18 Feb 2003 11:30:08 +0100 (MET) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA02817; Tue, 18 Feb 2003 11:30:08 +0100 (MET) Received: by MCHH248E with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Feb 2003 11:29:17 +0100 Message-ID: From: Kreuter Ruediger To: "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" Date: Tue, 18 Feb 2003 11:29:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] updated "Clearmode" (64kbit/s unrestricted) Internet-draft 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , FYI, I have submitted an update of the CLEARMODE Internet draft. You find it at http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clearmode-01.txt The major update, due to comments according the support of Nx64kbit/s and similar standardization activities in ITU's SG 11, is the introduction of Nx64kbit/s support. Two remarks to this issue: 1) 1x64kbit/s is used in current VoIP products and supported by most DSP Providers. Therefore I would like to keep Nx64kbit/s with N>1 as an option. 2) We currently do not have a VoIP product supporting Nx64kbit/s, therefore I introduced this merely as a discussion input. So if anybody has a working Nx64kbit/s solution I would like to get some comments on the packatization method in that case. If nobody has a solution I will delete this feature from the next version of this draft. Besides, the first draft initiated a controverse discussion, if this should be "audio/CLEARMODE" or e.g. "application/CLEARMODE". IMHO none of the existing IANA content types really fits for CLEARMODE. Since 1x64kbit/s is also used for 7kHz voice (despite G.722) I kept "audio" in this draft. Regards Ruediger _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 18 07:28:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26428 for ; Tue, 18 Feb 2003 07:28:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ICYOw22562 for avt-archive@odin.ietf.org; Tue, 18 Feb 2003 07:34:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICXVp22525; Tue, 18 Feb 2003 07:33:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICV3p22434 for ; Tue, 18 Feb 2003 07:31:03 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26311 for ; Tue, 18 Feb 2003 07:24:55 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1ICSXVR015259 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Tue, 18 Feb 2003 13:28:34 +0100 X-pt: isis.lip6.fr Received: from minerve (rp-dhcp21 [132.227.61.221]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h1ICSW316475; Tue, 18 Feb 2003 13:28:32 +0100 (MET) From: "Timur Friedman" To: "Joerg Ott" Cc: , "Ramon Caceres" , "Alan Clark" , "Kevin Almeroth" , "Kamil Sarac" , "Robert Cole" , "Kaynam Hedayat" , "Nick Duffield" Subject: RE: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Tue, 18 Feb 2003 02:31:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3E5125E9.20607@tzi.uni-bremen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1ICV4p22436 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Joerg, Saving a full octet in an RTP XR block header is indeed tempting. Thank you for bringing this issue to our attention again. I don't think it has yet gotten the scrutiny it deserves. The following concerns lead me to hesitate about making the change: - Although RTP XR blocks should stay small (for scalability), one can envision good reasons for the occasional large report block. - The large report blocks are the ones that would benefit the most from compression. If the reported data are compressible, we wish to afford them a good compression ratio. It could be that, by requiring the data to be divided up into pieces before being compressed (in order to fit into 1020 byte units), we hurt the compression ratio. I do not have concrete examples to cite, but to my mind this is a real possibility. - Fragmentation and reassembly (in this case of reports, at the RTCP level) impose overhead. - It is true that SDES elements are limited by an 8 bit length field. However the elements, names, e-mail addresses, phone numbers, etc., are relatively short. The note or the private element might be an exception. In the case of RTP XR, several of the blocks are potentially very long (timestamp reports, for example). While it is a good general policy to limit their size, in my mind it is better to limit them as a function of the application's requirements and the environment (including MTU) rather than imposing an a priori constraint that is much less than the possible size of an RTCP packet. - The usual MTU is a constraint. But it is also something subject to change depending upon the environment, and a value that might well evolve over the long term. We don't necessarily want to lock in to a constraint that is subject to such change. - None of the report blocks currently defined in the RTP XR draft could be shortened by a full 32 bit word if the length field were reduced from 16 bits to 8 bits. One compelling argument in favor of the shortening would be a report block that would benefit. But I would remain concerned about the issues that I have listed. Best regards, Timur > -----Original Message----- > From: Joerg Ott [mailto:jo@tzi.uni-bremen.de] > Sent: Monday, February 17, 2003 1:12 PM > To: Timur Friedman > Cc: avt@ietf.org; Ramon Caceres; Alan Clark; Kevin Almeroth; Kamil > Sarac; Robert Cole; Kaynam Hedayat; Nick Duffield > Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt > > > Timur, > > while we are at it: I am currently revising the SSM RTCP draft and > hence came across an issue I also mentioned at the last IETF: > wouldn't it make sense to slightly revise the first few bytes of the > XR blocks defined in section 3: > > (sorry if you have gone through this again and again) > > From: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT | type-specific | block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : type-specific data : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > To: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT | block length | type-specific data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : type-specific data : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The first byte of your type-specific data field could easily become > the "type-specific" field before. > > As you are measuring block size if multiples of 32 bits, an 8 bit > value will cover block sizes of up to 1,020 bytes which seems quite > a lot (particularly as the packets are supposed to fit into a usual > MTU). If you need more, you could just include the same block > several times. You'll save one byte or two per report block. > > BTW: Except for the alignment requirement, the above structure would > also mirror the SDES format. > > Joerg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 19 22:20:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17015 for ; Wed, 19 Feb 2003 22:20:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K3R7530785 for avt-archive@odin.ietf.org; Wed, 19 Feb 2003 22:27:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3Qfp30751; Wed, 19 Feb 2003 22:26:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JH8jp26989 for ; Wed, 19 Feb 2003 12:08:45 -0500 Received: from antivir2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01541; Wed, 19 Feb 2003 12:02:01 -0500 (EST) Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 18:53:57 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 18:50:31 +0200 Message-ID: From: Sasha Vainshtein To: "'Kreuter Ruediger'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" , Alik Shimelmits , Akiva Sadovski , Israel Sasson Date: Wed, 19 Feb 2003 18:50:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [PWE3] updated "Clearmode" (64kbit/s unrestricted) Internet-d raft 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Ruediger and all, Please take a look at http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-05.txt , Section 6.6.2. It seems that the approach and the resulting format are pretty similar. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Kreuter Ruediger [mailto:ruediger.kreuter@siemens.com] > Sent: Tuesday, February 18, 2003 12:29 PM > To: 'avt@ietf.org'; 'mmusic@ietf.org'; 'pwe3@ietf.org' > Cc: 'kschong@att.com'; 'taylor@nortelnetworks.com' > Subject: [PWE3] updated "Clearmode" (64kbit/s unrestricted) > Internet-draft > > > FYI, > I have submitted an update of the CLEARMODE Internet draft. > You find it at > http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clea > rmode-01.txt > > The major update, due to comments according the support of Nx64kbit/s > and similar standardization activities in ITU's SG 11, is the > introduction of > Nx64kbit/s support. Two remarks to this issue: > 1) 1x64kbit/s is used in current VoIP products and supported > by most DSP > Providers. Therefore I would like to keep Nx64kbit/s with > N>1 as an option. > 2) We currently do not have a VoIP product supporting > Nx64kbit/s, therefore > I introduced this merely as a discussion input. > So if anybody has a working Nx64kbit/s solution I would > like to get some > comments on the packatization method in that case. If nobody has a > solution I will delete this feature from the next version > of this draft. > > Besides, the first draft initiated a controverse discussion, > if this should be > "audio/CLEARMODE" or e.g. "application/CLEARMODE". > IMHO none of the existing IANA content types really fits for > CLEARMODE. > Since 1x64kbit/s is also used for 7kHz voice (despite G.722) > I kept "audio" > in this draft. > > Regards > Ruediger > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 19 22:21:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17032 for ; Wed, 19 Feb 2003 22:21:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K3ReT30813 for avt-archive@odin.ietf.org; Wed, 19 Feb 2003 22:27:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3QSp30734; Wed, 19 Feb 2003 22:26:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HIF7p11900 for ; Mon, 17 Feb 2003 13:15:07 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27487 for ; Mon, 17 Feb 2003 13:09:09 -0500 (EST) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id h1HICh025485; Mon, 17 Feb 2003 19:12:43 +0100 (MET) Message-ID: <3E5125E9.20607@tzi.uni-bremen.de> Date: Mon, 17 Feb 2003 19:11:53 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Timur Friedman CC: avt@ietf.org, Ramon Caceres , Alan Clark , Kevin Almeroth , Kamil Sarac , Robert Cole , Kaynam Hedayat , Nick Duffield Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt References: <200301242135.31937.timur.friedman@lip6.fr> <200301242156.03464.timur.friedman@lip6.fr> 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Timur, while we are at it: I am currently revising the SSM RTCP draft and hence came across an issue I also mentioned at the last IETF: wouldn't it make sense to slightly revise the first few bytes of the XR blocks defined in section 3: (sorry if you have gone through this again and again) From: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | block length | type-specific data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first byte of your type-specific data field could easily become the "type-specific" field before. As you are measuring block size if multiples of 32 bits, an 8 bit value will cover block sizes of up to 1,020 bytes which seems quite a lot (particularly as the packets are supposed to fit into a usual MTU). If you need more, you could just include the same block several times. You'll save one byte or two per report block. BTW: Except for the alignment requirement, the above structure would also mirror the SDES format. Joerg Timur Friedman wrote: > Hello, > > Please find attached the latest version of the (new title) RTP Extended > Reports (RTP XR) draft, draft-ietf-avt-rtcp-report-extns-02.txt. This has > just been submitted to internet-drafts@ietf.org. We have updated the draft > based upon comments from this list and from the chairs. > > We hope to advance to Final Call at the March IETF in San Francisco. Your > comments are most welcome so that we may issue a final draft in good time. > > Here are the changes since the previous version: > > * Changed title from RTCP Reporting Extensions to RTP Extended Reports > (RTP XR). (Only very well known acronyms may appear in the title > without expansion. RTP appears in the titles of several RFCs, RTCP > in none to date.) > > * Reduced author list from seven authors to three editors. Created a > Contributors section. Nick Duffield added as author. (No more than five > names allowed on the front page authors list, mentioned by Colin.) > > * Added Magnus Westerlund, Dorgham Sisalem, and Adam Wolisz to the > acknowledgments. > > * Separated normative from informative references. (Now recommended > by the RFC Editor, mentioned by Colin.) > > * Renumbered the RTP packet type (PT) value for XR packets to 207. > This would be the next available value should the RTCP feedback > draft, which is in last call, become an RFC. Note that this would > require changes to any other drafts based on the XR packet (RTCP > Extensions for Single-Source Multicast is one). > > * Renumbered the block types from 1 to 7, replacing the legacy values. > (Requested by Colin in the absence of a clear rationale for the > legacy values.) > > * Rewrote the IANA Considerations section (as recommended by Colin). > > * Changed the required behavior for the receiver when it sees a > non-zero value in a reserved field. Now the receiver must ignore > the block or packet that contains this field. Previously the > receiver was to ignore the field if they were unaware of any defined > semantics for the field. (Allows for future definitions of these > fields to call for different behavior on the part of receivers.) > > * All report blocks now have "Report Block" as part of their name. > (This was inconsistent before.) > > * Some of the subsections of Section 4.7 have been combined. > > * Sections at the end of the document, such as the references and the > copyright statement, have been reordered. References divided into > Normative and Non-Normative References. > > * An appendix has been created for algorithms. The formatting for > algorithms has been harmonized. > > * The discussion of per-sender and per-packet accounting for the Loss > RLE Report Block (Section 4.1) has been updated, with an algorithm > in the appendix. > > * Variable geometry removed from the Statistics Summary Report Block > (Section 4.4). Now, if a statistic is not reported, the field is > set to zero, but the field itself is not removed. This should > considerably simplify parsing. > > * Clarified the wording specifying the length fields. (Thanks to > Magnus Westerlund.) > > * Clarified how late packets are accounted as losses. (Thanks to > Henning Schulzrinne and Magnus Westerlund.) > > * Made begin_seq and end_seq 16 bits in all cases. (Thanks to Magnus > Westerlund.) > > * Clarified what to do if there are losses or duplicates when sending > a Timestamp Report Block. (Thanks to Magnus Westerlund.) > > * Recommendations added to the Security Considerations section. > > * Gmin recommended value of 16 indicated for VoIP Metrics Report Block > (Section 4.7) > > * RERL calculation corrected in Section 4.7. (Thanks to Magnus > Westerlund.) > > * Burst metrics algorithm modified, and discussion updated. > > * Field renamed in the VoIP block: doubletalk now residual echo return loss > (RERL). Updated discussion of this field. > > * Fields reordered in VoIP block to better align on 16-bit boundaries. > > * Document indenting fixed to conform to that of the RTP spec. > > Regards, > > Timur Friedman > > > ------------------------------------------------------------------------ > > > > > > > > INTERNET-DRAFT 24 January 2003 > Internet Engineering Task Force Expires: 24 July 2003 > Audio/Video Transport Working Group > > Timur Friedman, Paris 6 > Ramon Caceres, ShieldIP > Alan Clark, Telchemy > Editors > > RTP Extended Reports (RTP XR) > > draft-ietf-avt-rtcp-report-extns-02.txt > > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > This document defines the extended report (XR) packet type for the > RTP control protocol (RTCP). XR packets are composed of report > blocks, and seven block types are defined here. The purpose of the > extended reporting format is to convey information that supplements > the six statistics that are contained in the report blocks used by > RTCP's sender report (SR) and receiver report (RR) packets. Some > applications, such as multicast inference of network characteristics > > > > Friedman, Caceres, and Clark, eds. [Page 1] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > (MINC) or voice over IP (VoIP) monitoring, require other and more > detailed statistics. In addition to the block types defined here, > additional block types may be defined in the future by adhereing to > the framework that this document provides. > > Table of Contents > > 1. Introduction .............................................. 2 > 1.1 Terminology ............................................... 3 > 2. XR Packet Format .......................................... 4 > 3. Extended Report Block Framework ........................... 5 > 4. Extended Report Blocks .................................... 6 > 4.1 Loss RLE Report Block ..................................... 6 > 4.1.1 Run Length Chunk .......................................... 12 > 4.1.2 Bit Vector Chunk .......................................... 12 > 4.1.3 Terminating Null Chunk .................................... 12 > 4.2 Duplicate RLE Report Block ................................ 13 > 4.3 Timestamp Report Block .................................... 13 > 4.4 Statistics Summary Report Block ........................... 16 > 4.5 Receiver Timestamp Report Block ........................... 19 > 4.6 DLRR Report Block ......................................... 20 > 4.7 VoIP Metrics Report Block ................................. 21 > 4.7.1 Packet Loss and Discard Metrics ........................... 23 > 4.7.2 Burst Metrics ............................................. 23 > 4.7.3 Delay Metrics ............................................. 26 > 4.7.4 Signal Related Metrics .................................... 26 > 4.7.5 Call Quality or Transmission Quality Metrics .............. 29 > 4.7.6 Configuration Parameters .................................. 30 > 4.7.7 Jitter Buffer Parameters .................................. 31 > 5. IANA Considerations ....................................... 32 > 5.1 XR Packet Type ............................................ 32 > 5.2 RTP XR Block Type Registry ................................ 32 > 6. Security Considerations ................................... 33 > A. Algorithms ................................................ 34 > A.1 Sequence Number Interpretation ............................ 34 > A.2 Example Burst Packet Loss Calculation ..................... 35 > Intellectual Property ..................................... 37 > Full Copyright Statement .................................. 38 > Acknowledegments .......................................... 38 > Contributors .............................................. 39 > Authors' Addresses ........................................ 39 > References ................................................ 40 > Normative References ...................................... 40 > Non-Normative References .................................. 41 > > 1. Introduction > > This document defines the extended report (XR) packet type for the > > > > Friedman, Caceres, and Clark, eds. [Page 2] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > RTP control protocol (RTCP) [7]. XR packets convey information > beyond that already contained in the reception report blocks of > RTCP's sender report (SR) or receiver report (RR) packets. The > information is of use across RTP profiles, and so is not > appropriately carried in SR or RR profile-specific extensions. > Information used for network management falls into this category, for > instance. > > The definition is broken out over the three following sections of > this document, starting with a general framework and finishing with > the specific information conveyed. The framework defined by Section > 2 contains common header information followed by a series of > components called report blocks. Section 3 defines the format common > to such blocks. Section 4 defines seven block types. > > Seven report block formats are defined by this document: > > - Loss RLE Report Block (Section 4.1): Run length encoding of RTP > packet loss reports. > > - Duplicate RLE Report Block (Section 4.2): Run length encoding of > reports of RTP packet duplicates. > > - Timestamp Report Block (Section 4.3): A list of timestamps of > received RTP packets. > > - Statistics Summary Report Block (Section 4.4): Statistics on RTP > packet sequence numbers, losses, duplicates, jitter, and TTL values. > > - Receiver Timestamp Report Block (Section 4.5): Receiver-end > timestamps that complement the sender-end timestamps already defined > for RTCP. > > - DLRR Report Block (Section 4.6): The delay since the last Receiver > Timestamp Report Block was received, allowing non-senders to > calculate round-trip times. > > - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring > Voice over IP (VoIP) calls. > > These blocks are defined within a minimal framework: a type field and > a length field are common to all XR blocks. The purpose is to > maintain flexibility and to keep overhead low. 0ther block formats, > beyond the seven defined here, may be defined within this framework > as the need arises. > > 1.1 Terminology > > > > > Friedman, Caceres, and Clark, eds. [Page 3] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [1] and > indicate requirement levels for compliance with this specification. > > 2. XR Packet Format > > The XR packet consists of a header of two 32-bit words, followed by a > number, possibly zero, of extended report blocks. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P|reserved | PT=XP=207 | length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC/CSRC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : report blocks : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > version (V): 2 bits > Identifies the version of RTP. This specification applies to > RTP version two. > > padding (P): 1 bit > If the padding bit is set, this XR packet contains some > additional padding octets at the end. The semantics of this > field are identical to the semantics of the padding field in the > the SR packet, as defined by the RTP specification. > > reserved: 5 bits > This field is reserved for future definition. In the absence of > such definition, the bits in this field MUST be set to zero and > the receiver MUST ignore any XR packet with a non-zero value in > this field. > > packet type (PT): 8 bits > Contains the constant 207 to identify this as an RTCP XR packet. > This value is registered with the Internet Assigned Numbers > Authority (IANA), as described in Section 5.1. > > length: 16 bits > As described for the RTP sender report (SR) packet (see Section > 6.3.1 of the RTP specification [7]). Briefly, the length of > this XR packet in 32-bit words minus one, including the header > and any padding. > > > > Friedman, Caceres, and Clark, eds. [Page 4] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > SSRC: 32 bits > The synchronization source identifier for the originator of this > XR packet. > > report blocks: variable length. > Zero or more extended report blocks. In keeping with the > extended report block framework defined below, each block MUST > consist of one or more 32-bit words. > > 3. Extended Report Block Framework > > Extended report blocks are stacked, one after the other, at the end > of an XR packet. An individual block's length is a multiple of 4 > octets. The XR header's length field describes the total length of > the packet, including these extended report blocks. > > Each block has block type and length fields that facilitate parsing. > A receiving application can demultiplex the blocks based upon their > type, and can use the length information to locate each successive > block, even in the presence of block types it does not recognize. > > An extended report block has the following format: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT | type-specific | block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : type-specific data : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > Identifies the block format. Seven block types are defined in > Section 4. Additional block types may be defined in future > specifications. This field's name space is managed by the > Internet Assigned Numbers Authority (IANA), as described in > Section 5.2. > > type-specific: 8 bits > The use of these bits is determined by the block type > definition. > > block length: 16 bits > The length of this report block including the header, in 32-bit > words minus one. If the block type definition permits, zero is > an acceptable value, signifying a block that consists of only > > > > Friedman, Caceres, and Clark, eds. [Page 5] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > the BT, type-specific, and block length fields, with a null > type-specific data field. > > type-specific data: variable length > The use of this field is defined by the particular block type, > subject to the constraint that it MUST be a multiple of 32 bits > long. If the block type definition permits, It MAY be zero bits > long. > > 4. Extended Report Blocks > > This section defines seven extended report blocks: block types for > losses, duplicates, packet reception timestamps, detailed reception > statistics, receiver timestamps, receiver inter-report delays, and > voice over IP (VoIP) metrics. An implementation MAY ignore incoming > blocks with types either not relevant or unknown to it. Additional > block types MUST be registered with the Internet Assigned Numbers > Authority (IANA) [5], as described in Section 5.2. > > 4.1 Loss RLE Report Block > > This block type permits detailed reporting upon individual packet > receipt and loss events. Such reports can be used, for example, for > multicast inference of network characteristics (MINC) [8]. With > MINC, one can discover the topology of the multicast tree used for > distributing a source's RTP packets, and of the loss rates along > links within that tree. Or they could be used to provide raw data to > a network management application. > > Since a Boolean trace of lost and received RTP packets is potentially > lengthy, this block type permits the trace to be compressed through > run length encoding. To further reduce block size, loss event > reports can be systematically dropped from the trace in a mechanism > called thinning that is described below and that is studied in [9]. > > A participant that generates a Loss RLE Report Block should favor > accuracy in reporting on observed events over interpretation of those > events whenever possible. Interpretation should be left to those who > observe the report blocks. Following this approach implies that > accounting for Loss RLE Report Blocks will differ from the accounting > for the generation of the SR and RR packets described in the RTP > specification [7] in the following two areas: per-sender accounting > and per-packet accounting. > > In its per-sender accounting, an RTP session participant SHOULD NOT > make the receipt of a threshold minimum number of RTP packets a > condition for reporting upon the sender of those packets. This > accounting technique differs from the technique described in Section > > > > Friedman, Caceres, and Clark, eds. [Page 6] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 6.2.1 and Appendix A.1 of the RTP specification that allows a > threshold to determine whether a sender is considered valid. > > In its per-packet accounting, an RTP session participant SHOULD treat > all sequence numbers as valid. This accouting technique differs from > the technique described in Appendix A.1 of the RTP specification that > suggests ruling a sequence number valid or invalid on the basis of > its contiguity with the sequence numbers of previously received > packets. > > Sender validity and sequence number validity are interpretations of > the raw data. Such interpretations are justified in the interest, > for example, of excluding the stray old packet from an unrelated > session from having an effect upon the calculation of the RTCP > transmission interval. The presence of stray packets might, on the > other hand, be of interest to a network monitoring application. > > One accounting interpretation that is still necessary is for a > participant to decide whether the 16 bit sequence number has rolled > over. Under ordinary circumstances this is not a difficult task. > For example, if packet number 65,535 (the highest possible sequence > number) is followed shortly by packet number 0, it is reasonable to > assume that there has been a rollover. However it is possible that > the packet is an earlier one (from 65,535 packets earlier). It is > also possible that the sequence numbers have rolled over multiple > times, either forward or backward. The interpretation becomes more > difficult when there are large gaps between the sequence numbers, > even accounting for rollover, and when there are long intervals > between received packets. > > The per-packet accounting technique mandated here is for a > participant to keep track of the sequence number of the packet most > recently received from a sender. For the next packet that arrives > from that sender, the sequence number MUST be judged to fall no more > than 32,768 packets ahead or behind the most recent one, whichever > choice places it closer. In the event that both choices are equally > distant (only possible when the distance is 32,768), the choice MUST > be the one that does not require a rollover. Appendix A.1 presents > an algorithm that implements this technique. > > Each block reports on a single source, identified by its SSRC. The > receiver that is supplying the report is identified in the header of > the RTCP packet. > > Choice of beginning and ending RTP packet sequence numbers for the > trace is left to the application. These values are reported in the > block. The last sequence number in the trace MAY differ from the > sequence number reported on in any accompanying SR or RR report. > > > > Friedman, Caceres, and Clark, eds. [Page 7] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > Note that because of sequence number wrap around the ending sequence > number MAY be less than the beginning sequence number. A Loss RLE > Report Block MUST NOT be used to report upon a range of 65,534 or > greater in the sequence number space, as there is no means to > identify multiple wrap arounds. > > The trace described by a Loss RLE report consists of a sequence of > Boolean values, one for each sequence number of the trace. A value > of one represents a packet receipt, meaning that one or more packets > having that sequence number have been received since the most recent > wrap around of sequence numbers (or since the beginning of the RTP > session if no wrap around has been judged to have occurred). A value > of zero represents a packet loss, meaning that there has been no > packet receipt for that sequence number as of the time of the report. > If a packet with a given sequence number is received after a report > of a loss for that sequence number, a later Loss RLE report MAY > report a packet receipt for that sequence number. > > The encoding itself consists of a series of 16 bit units called > chunks that describe sequences of packet receipts or losses in the > trace. Each chunk either specifies a run length or a bit vector, or > is a null chunk. A run length describes between 1 and 16,383 events > that are all the same (either all receipts or all losses). A bit > vector describes 15 events that may be mixed receipts and losses. A > null chunk describes no events, and is used to to round out the block > to a 32 bit word boundary. > > The mapping from a sequence of lost and received packets into a > sequence of chunks is not necessarily unique. For example, the > following trace covers 45 packets, of which the 22nd and 24th have > been lost and the others received: > > > 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 > > > One way to encode this would be: > > > bit vector 1111 1111 1111 111 > bit vector 1111 1101 0111 111 > bit vector 1111 1111 1111 111 > null chunk > > > Another way to encode this would be: > > > > > > Friedman, Caceres, and Clark, eds. [Page 8] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > run of 21 receipts > bit vector 0101 1111 1111 111 > run of 9 receipts > null chunk > > > The choice of encoding is left to the application. As part of this > freedom of choice, applications MAY terminate a series of run length > and bit vector chunks with a bit vector chunk that runs beyond the > sequence number space described by the report block. For example, if > the 44th packet in the same sequence were lost: > > > 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 > > > This could be encoded as: > > > run of 21 receipts > bit vector 0101 1111 1111 111 > bit vector 1111 1110 1000 000 > null chunk > > > In this example, the last five bits of the second bit vector describe > a part of the sequence number space that extends beyond the last > sequence number in the trace. These bits have been set to zero. > > All bits in a bit vector chunk that describe a part of the sequence > number space that extends beyond the last sequence number in the > trace MUST be set to zero, and MUST be ignored by the receiver. > > A null packet MUST appear at the end of a Loss RLE Report Block if > the number of run length plus bit vector chunks is odd. The null > chunk MUST NOT appear in any other context. > > Caution should be used in sending Loss RLE Report Blocks because, > even with the compression provided by run length encoding, they can > easily consume bandwidth out of proportion with normal RTCP packets. > The block type includes a mechanism, called thinning, that allows an > application to limit report sizes. > > A thinning value, T, selects a subset of packets within the sequence > number space: those with sequence numbers that are multiples of 2^T. > Packet reception and loss reports apply only to those packets. T can > vary between 0 and 15. If T is zero then every packet in the > sequence number space is reported upon. If T is fifteen then one in > > > > Friedman, Caceres, and Clark, eds. [Page 9] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > every 32,768 packets is reported upon. > > Suppose that the trace just described begins at sequence number > 13,821. The last sequence number in the trace is 13,865. If the > trace were to be thinned with a thinning value of T=2, then the > following sequence numbers would be reported upon: 13,824, 13,828, > 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, > 13,864. The thinned trace would be as follows: > > > 1 1 1 1 1 0 1 1 1 1 0 > > > This could be encoded as follows: > > > bit vector 1111 1011 1100 000 > null chunk > > > The last four bits in the bit vector, representing sequence numbers > 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are > thus set to zero and are ignored by the receiver. With thinning, the > loss of the 22nd packet goes unreported because its sequence number, > 13,842, is not a multiple of four. Packet receipts for all sequence > numbers that are not multiples of four also go unreported. However, > in this example thinning has permitted the Loss RLE Report Block to > be shortened by one 32 bit word. > > Choice of the thinning value is left to the application. > > The Loss RLE Report Block has the following format: > > > > > > > > > > > > > > > > > > > > Friedman, Caceres, and Clark, eds. [Page 10] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=1 | rsvd. | T | block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC of source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | begin_seq | end_seq | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | chunk 1 | chunk 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | chunk n-1 | chunk n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A Loss RLE Report Block is identified by the constant 1. > > rsvd.: 4 bits > This field is reserved for future definition. In the absence of > such definition, the bits in this field MUST be set to zero and > the receiver MUST ignore any Loss RLE Report Block with a non- > zero value in this field. > > thinning (T): 4 bits > The amount of thinning performed on the sequence number space. > Only those packets with sequence numbers 0 mod 2^T are reported > on by this block. A value of 0 indicates that there is no > thinning, and all packets are reported on. The maximum thinning > is one packet in every 32,768 (amounting to two packets within > each 16-bit sequence space). > > block length: 16 bits > Defined in Section 3. > > begin_seq: 16 bits > The first sequence number that this block reports on. > > end_seq: 16 bits > The last sequence number that this block reports on plus one. > > chunk i: 16 bits > There are three chunk types: run length, bit vector, and > terminating null, defined in the following sections. If the > chunk is all zeroes then it is a terminating null chunk. > Otherwise, the leftmost bit of the chunk determines its type: 0 > > > > Friedman, Caceres, and Clark, eds. [Page 11] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > for run length and 1 for bit vector. > > 4.1.1 Run Length Chunk > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C|R| run length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > chunk type (C): 1 bit > A zero identifies this as a run length chunk. > > run type (R): 1 bit > Zero indicates a run of 0s. One indicates a run of 1s. > > run length: 14 bits > A value between 1 and 16,383. The value MUST not be zero for a > run length chunk (zeroes in both the run type and run length > fields would make the chunk a terminating null chunk). Run > lengths of 15 or less MAY be described with a run length chunk > despite the fact that they could also be described as part of a > bit vector chunk. > > 4.1.2 Bit Vector Chunk > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| bit vector | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > chunk type (C): 1 bit > A one identifies this as a bit vector chunk. > > bit vector: 15 bits > The vector is read from left to right, in order of increasing > sequence number (with the appropriate allowance for wrap > around). > > 4.1.3 Terminating Null Chunk > > This chunk is all zeroes. > > > > > Friedman, Caceres, and Clark, eds. [Page 12] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 4.2 Duplicate RLE Report Block > > This block type permits per-sequence-number reports on duplicates in > a source's RTP packet stream. Such information can be used for > network diagnosis, and provide an alternative to packet losses as a > basis for multicast tree topology inference. > > The Duplicate RLE Report Block format is identical to the Loss RLE > Report Block format. Only the interpretation is different, in that > the information concerns packet duplicates rather than packet losses. > The trace to be encoded in this case also consists of zeros and ones, > but a zero here indicates the presence of duplicate packets for a > given sequence number, whereas a one indicates that no duplicates > were received. > > The existence of a duplicate for a given sequence number is > determined over the entire reporting period. For example, if packet > number 12,593 arrives, followed by other packets with other sequence > numbers, the arrival later in the reporting period of another packet > numbered 12,593 counts as a duplicate for that sequence number. The > duplicate does not need to follow immediately upon the first packet > of that number. Care must be taken that a report does not cover a > range of 65,534 or greater in the sequence number space. > > No distinction is made between the existance of a single duplicate > packet and multiple duplicate packets for a given sequence number. > Note also that since there is no duplicate for a lost packet, a loss > is encoded as a one in a Duplicate RLE Report Block. > > The Duplicate RLE Report Block has the following format: > > > > > > > > > > > > > > > Friedman, Caceres, and Clark, eds. [Page 13] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=2 | rsvd. | T | block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC of source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | begin_seq | end_seq | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | chunk 1 | chunk 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | chunk n-1 | chunk n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A Duplicate RLE Report Block is identified by the constant 2. > > rsvd.: 4 bits > This field is reserved for future definition. In the absence of > such definition, the bits in this field MUST be set to zero and > the receiver MUST ignore any Duplicate RLE Report Block with a > non-zero value in this field. > > thinning (T): 4 bits > As defined in Section 4.1. > > block length: 16 bits > Defined in Section 3. > > begin_seq: 16 bits > As defined in Section 4.1. > > end_seq: 16 bits > As defined in Section 4.1. > > chunk i: 16 bits > As defined in Section 4.1. > > 4.3 Timestamp Report Block > > This block type permits per-sequence-number reports on packet receipt > timestamps for a given source's RTP packet stream. Such information > can be used for MINC inference of the topology of the multicast tree > used to distribute the source's RTP packets, and of the delays along > the links within that tree. It can also be used to measure partial > > > > Friedman, Caceres, and Clark, eds. [Page 14] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > path characteristics and to model distributions for packet jitter. > > At least one packet MUST have been received for each sequence number > reported upon in this block. If this block type is used to report > timestamps for a series of sequence numbers that includes lost > packets, several blocks are required. If duplicate packets have been > received for a given sequence number, and those packets differ in > their receiver timestamps, any timestamp other than the earliest MUST > NOT be reported. This is to ensure consistency among reports. > > Timestamps consume more bits than loss or duplicate information, and > do not lend themselves to run length encoding. The use of thinning > is encouraged to limit the size of Timestamp Report Blocks. > > The Timestamp Report Block has the following format: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=3 | rsvd. | T | block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC of source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | begin_seq | end_seq | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RTP timestamp 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RTP timestamp 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RTP timestamp n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A Timestamp Report Block is identified by the constant 3. > > rsvd.: 4 bits > This field is reserved for future definition. In the absence of > such definition, the bits in this field MUST be set to zero and > the receiver MUST ignore any Timestamp Report Block with a non- > zero value in this field. > > thinning (T): 4 bits > As defined in Section 4.1. > > > > > Friedman, Caceres, and Clark, eds. [Page 15] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > block length: 16 bits > Defined in Section 3. > > begin_seq: 16 bits > As defined in Section 4.1. > > end_seq: 16 bits > As defined in Section 4.1. > > RTP timestamp i: 32 bits > The timestamp reflects the packet arrival time at the receiver. > It is preferable for the timestamp to be established at the link > layer interface, or in any case as close as possible to the wire > arrival time. Units and format are the same as for the > timestamp in RTP data packets. As opposed to RTP data packet > timestamps, in which nominal values may be used instead of > system clock values in order to convey information useful for > periodic playout, the receiver timestamps should reflect the > actual time as closely as possible. The initial value of the > timestamp is random, and subsequent timestamps are offset from > this value. > > 4.4 Statistics Summary Report Block > > This block reports statistics beyond the information carried in the > standard RTCP packet format, but not as fine grained as that carried > in the report blocks previously described. Information is recorded > about lost packets, duplicate packets, jitter measurements, and TTL > values (TTL values being taken from the TTL field of IPv4 packets, if > the data packets are carried over IPv4). Such information can be > useful for network management. > > The report block contents are dependent upon a bit vector carried in > the first part of the header. Not all parameters need to be reported > in each block. Flags indicate which are and which are not reported. > The fields corresponding to unreported parameters MUST be set to > zero. The receiver MUST ignore any Statistics Summary Report Block > with a non-zero value in any field flagged as unreported. > > The Statistics Summary Report Block has the following format: > > > > > > > > > > > > Friedman, Caceres, and Clark, eds. [Page 16] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=4 |L|D|J|T|resvd. | block length = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC of source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | begin_seq | end_seq | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lost_packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dup_packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | min_jitter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | max_jitter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | avg_jitter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dev_jitter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | min_ttl | max_ttl | avg_ttl | dev_ttl | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A Statistics Summary Report Block is identified by the constant > 4. > > loss report flag (L): 1 bit > Bit set to 1 if the lost_packets field contains a report, 0 > otherwise. > > duplicate report flag (D): 1 bit > Bit set to 1 if the dup_packets field contains a report, 0 > otherwise. > > jitter flag (J): 1 bit > Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and > dev_jitter fields all contain reports, 0 if none of them do. > > TTL flag (T): 1 bit > Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl > fields all contain reports, 0 if none of them do. > > resvd.: 4 bits > This field is reserved for future definition. In the absence of > such definition, all bits in this field MUST be set to zero, and > > > > Friedman, Caceres, and Clark, eds. [Page 17] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > the receiver MUST ignore any Statistics Summary Report Block > with a non-zero value in this field. > > block length: 16 bits > The constant 9, in accordance with the definition of this field > in Section 3. > > begin_seq: 16 bits > As defined in Section 4.1. > > end_seq: 16 bits > As defined in Section 4.1. > > lost_packets: 32 bits > Number of lost packets in the above sequence number interval. > > dup_packets: 32 bits > Number of duplicate packets in the above sequence number > interval. > > min_jitter: 32 bits > The minimum relative transit time between two packets in the > above sequence number interval. All jitter values are measured > as the difference between a packet's RTP timestamp and the > reporter's clock at the time of arrival, measured in the same > units. > > max_jitter: 32 bits > The maximum relative transit time between two packets in the > above sequence number interval. > > avg_jitter: 32 bits > The average relative transit time between each two packet series > in the above sequence number interval. > > dev_jitter: 32 bits > The standard deviation of the relative transit time between each > two packet series in the above sequence number interval. > > min_ttl: 8 bits > The minimum TTL value of data packets in sequence number range. > > max_ttl: 8 bits > The maximum TTL value of data packets in sequence number range. > > avg_ttl: 8 bits > The average TTL value of data packets in sequence number range. > > > > > Friedman, Caceres, and Clark, eds. [Page 18] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > dev_ttl: 8 bits > The standard deviation of TTL values of data packets in sequence > number range. > > 4.5 Receiver Timestamp Report Block > > This block extends RTCP's timestamp reporting so that non-senders may > also send timestamps. It recapitulates the NTP timestamp fields from > the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate > its RTT to other participants, as proposed in [11], by sending this > report block and receiving DLRR Report Blocks (see next section) in > reply. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=5 | reserved | block length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, most significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, least significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A Receiver Timestamp Report Block is identified by the constant > 5. > > reserved: 8 bits > This field is reserved for future definition. In the absence of > such definition, the bits in this field MUST be set to zero and > the receiver MUST ignore any Receiver Timestamp Report Block > with a non-zero value in this field. > > block length: 16 bits > The constant 2, in accordance with the definition of this field > in Section 3. > > NTP timestamp: 64 bits > Indicates the wallclock time when this block was sent so that it > may be used in combination with timestamps returned in DLRR > Report Blocks (see next section) from other receivers to measure > round-trip propagation to those receivers. Receivers should > expect that the measurement accuracy of the timestamp may be > limited to far less than the resolution of the NTP timestamp. > The measurement uncertainty of the timestamp is not indicated as > it may not be known. A report block sender that can keep track > > > > Friedman, Caceres, and Clark, eds. [Page 19] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > of elapsed time but has no notion of wallclock time may use the > elapsed time since joining the session instead. This is assumed > to be less than 68 years, so the high bit will be zero. It is > permissible to use the sampling clock to estimate elapsed > wallclock time. A report sender that has no notion of wallclock > or elapsed time may set the NTP timestamp to zero. > > 4.6 DLRR Report Block > > This block extends RTCP's delay since last sender report (DLSR) > mechanism [7, Sec. 6.3.1] so that non-senders may also calculate > round trip times, as proposed in [11]. It is termed DLRR for delay > since last receiver report, and may be sent in response to a Receiver > Timestamp Report Block (see previous section) from a receiver to > allow that receiver to calculate its round trip time to the > respondant. The report consists of one or more 3 word sub-blocks: > one sub-block per receiver report. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=6 | reserved | block length | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_1 (SSRC of first receiver) | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block > | last RR (LRR) | 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | delay since last RR (DLRR) | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_2 (SSRC of second receiver) | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block > : ... : 2 > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > > block type (BT): 8 bits > A DLRR Report Block is identified by the constant 6. > > reserved: 8 bits > This field is reserved for future definition. In the absence of > such definition, all bits in this field MUST be set to zero, the > receiver MUST ignore any DLRR Report Block with a non-zero value > in this field. > > block length: 16 bits > Defined in Section 3. > > > > > Friedman, Caceres, and Clark, eds. [Page 20] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > last RR timestamp (LRR): 32 bits > The middle 32 bits out of 64 in the NTP timestamp (as explained > in the previous section) received as part of a Receiver > Timestamp Report Block from participant SSRC_n. If no such block > has been received, the field is set to zero. > > delay since last RR (DLRR): 32 bits > The delay, expressed in units of 1/65536 seconds, between > receiving the last Receiver Timestamp Report Block from > participant SSRC_n and sending this DLRR Report Block. If no > Receiver Timestamp Report Block has been received yet from > SSRC_n, the DLRR field is set to zero (or the DLRR is omitted > entirely). Let SSRC_r denote the receiver issuing this DLRR > Report Block. Participant SSRC_n can compute the round-trip > propagation delay to SSRC_r by recording the time A when this > Receiver Timestamp Report Block is received. It calculates the > total round-trip time A-LSR using the last SR timestamp (LSR) > field, and then subtracting this field to leave the round-trip > propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig. > 2]. > > 4.7 VoIP Metrics Report Block > > The VoIP Metrics Report Block provides metrics for monitoring voice > over IP (VoIP) calls. These metrics include packet loss and discard > metrics, delay metrics, analog metrics, and voice quality metrics. > The block reports separately on packets lost on the IP channel, and > those that have been received but then discarded by the receiving > jitter buffer. It also reports on the combined effect of losses and > discards, as both have equal effect on call quality. > > In order to properly assess the quality of a Voice over IP call it is > desirable to consider the degree of burstiness of packet loss [10]. > Following a Gilbert-Elliott model [2], a period of time, bounded by > lost and/or discarded packets, with a high rate of losses and/or > discards is a "burst," and a period of time between two bursts is a > "gap." Bursts correspond to periods of time during which the packet > loss rate is high enough to produce noticeable degradation in audio > quality. Gaps correspond to periods of time during which only > isolated lost packets may occur, and in general these can be masked > by packet loss concealment. Delay reports include the transit delay > between RTCP end points and the VoIP end system processing delays, > both of which contribute to the user perceived delay. Additional > metrics include signal, echo, noise, and distortion levels. Call > quality metrics include R factors (as described by the E Model > defined in [2]) and mean opinion scores (MOS scores). > > An implementation that sends these blocks SHOULD send at least one > > > > Friedman, Caceres, and Clark, eds. [Page 21] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > every ten seconds for the duration of the call, SHOULD send one > whenever a CODEC type change or other significant change occurs, > SHOULD send one when significant call quality degradation is detected > and SHOULD send one upon call termination. Implementations MUST > provide values for all the fields defined here. For certain metrics, > if the value is undefined or unknown, then the specified default or > unknown field value MUST be provided. > > The block is encoded as seven 32-bit words: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=7 | reserved | block length = 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | loss rate | discard rate | burst density | gap density | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | burst duration | gap duration | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | round trip delay | end system delay | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | signal power | RERL | noise level | Gmin | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | R factor | ext. R factor | MOS-LQ | MOS-CQ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RX config | JB nominal | JB maximum | JB abs max | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > block type (BT): 8 bits > A VoIP Metrics Report Block is identified by the constant 7. > > reserved: 8 bits > This field is reserved for future definition. In the absence of > such definition, all bits in this field MUST be set to zero and > the receiver MUST ignore any VoIP Metrics Report Block with a > non-zero value in this field. > > block length: 16 bits > The constant 6, in accordance with the definition of this field > in Section 3. > > The remaining fields are described in the following six sections: > Packet Loss and Discard Metrics, Delay Metrics, Signal Related > Metrics, Call Quality or Transmission Quality Metrics, Configuration > Metrics, and Jitter Buffer Parameters. > > > > > Friedman, Caceres, and Clark, eds. [Page 22] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > 4.7.1 Packet Loss and Discard Metrics > > It is very useful to distinguish between packets lost by the network > and those discarded due to jitter. Both have equal effect on the > quality of the voice stream however having separate counts helps > identify the source of quality degradation. These fields MUST be > populated. > > loss rate: 8 bits > The fraction of RTP data packets from the source lost since the > beginning of reception, expressed as a fixed point number with > the binary point at the left edge of the field. This value is > calculated by dividing the total number of packets lost (after > the effects of applying any error protection such as FEC) by the > total number of packets expected, multiplying the result of the > division by 256, limiting the maximum value to 255 (to avoid > overflow), and taking the integer part. The numbers of > duplicated packets and discarded packets do not enter into this > calculation. Since receivers cannot be required to maintain > unlimited buffers, a receiver MAY categorize late-arriving > packets as lost. The degree of lateness that triggers a loss > SHOULD be significantly greater than that which triggers a > discard. > > discard rate: 8 bits > The fraction of RTP data packets from the source that have been > discarded since the beginning of reception, due to late or early > arrival, under-run or overflow at the receiving jitter buffer. > This value is expressed as a fixed point number with the binary > point at the left edge of the field. It is calculated by > dividing the total number of packets discarded (excluding > duplicate packet discards) by the total number of packets > expected, multiplying the result of the division by 256, > limiting the maximum value to 255 (to avoid overflow), and > taking the integer part. > > 4.7.2 Burst Metrics > > A burst, informally, is a period of high packet losses and/or > discards. Formally, a burst is defined as a longest sequence of > packets bounded by lost or discarded packets with the constraint that > within a burst any sequence of successive packets that were received, > and not discarded due to delay variation, is of length less than a > value Gmin. > > A gap, informally, is a period of low packet losses and/or discards. > Formally, a gap is defined as any of the following: (a) the period > from the start of an RTP session to the receipt time of the last > > > > Friedman, Caceres, and Clark, eds. [Page 23] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > received packet before the first burst, (b) the period from the end > of the last burst to either the time of the report or the end of the > RTP session, whichever comes first, or (c) the period of time between > two bursts. > > For the purpose of determining if a lost or discarded packet near the > start or end of an RTP session is within a gap or a burst it is > assumed that the RTP session is preceded and followed by at least > Gmin received packets, and that the time of the report is followed by > at least Gmin received packets. > > A gap has the property that any lost or discarded packets within the > gap must be preceded and followed by at least Gmin packets that were > received and not discarded. This gives a maximum loss/discard > density within a gap of: 1 / (Gmin + 1). > > A Gmin value of 16 is RECOMMENDED as it results in gap > characteristics that correspond to good quality (i.e. low packet loss > rate, a minimum distance of 16 received packets between lost packets) > and hence differentiates nicely between good and poor quality > periods. > > For example, a 1 denotes a received, 0 a lost, and X a discarded > packet in the following pattern covering 64 packets: > > > 11110111111111111111111X111X1011110111111111111111111X111111111 > |---------gap----------|--burst---|------------gap------------| > > > The burst consists of the twelve packets indicated above, starting at > a discarded packet and ending at a lost packet. The first gap starts > at the beginning of the session and the second gap ends at the time > of the report. > > If the packet spacing is 10 ms and the Gmin value is the recommended > value of 16, the burst duration is 120 ms, the burst density 0.33, > the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04. > > This would result in reported values as follows (see field > descriptions for semantics and details on how these are calculated): > > loss density 12, which corresponds to 5% > discard density 12, which corresponds to 5% > burst density 84, which corresponds to 33% > gap density 10, which corresponds to 4% > burst duration 120, value in milliseconds > gap duration 520, value in milliseconds > > > > Friedman, Caceres, and Clark, eds. [Page 24] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > burst density: 8 bits > The fraction of RTP data packets within burst periods since the > beginning of reception that were either lost or discarded. This > value is expressed as a fixed point number with the binary point > at the left edge of the field. It is calculated by dividing the > total number of packets lost or discarded (excluding duplicate > packet discards) within burst periods by the total number of > packets expected within the burst periods, multiplying the > result of the division by 256, limiting the maximum value to 255 > (to avoid overflow), and taking the integer part. > > gap density: 8 bits > The fraction of RTP data packets within inter-burst gaps since > the beginning of reception that were either lost or discarded. > The value is expressed as a fixed point number with the binary > point at the left edge of the field. It is calculated by > dividing the total number of packets lost or discarded > (excluding duplicate packet discards) within gap periods by the > total number of packets expected within the gap periods, > multiplying the result of the division by 256, limiting the > maximum value to 255 (to avoid overflow), and taking the integer > part. > > burst duration: 16 bits > The mean duration, expressed in milliseconds, of the burst > periods that have occurred since the beginning of reception. > The duration of each period is calculated based upon the packets > that mark the beginning and end of that period. It is equal to > the timestamp of the end packet, plus the duration of the end > packet, minus the timestamp of the beginning packet. If the > actual values are not available, estimated values MUST be used. > If there have been no burst periods, the burst duration value > MUST be zero. > > gap duration: 16 bits > The mean duration, expressed in milliseconds, of the gap periods > that have occurred since the beginning of reception. The > duration of each period is calculated based upon the packet that > marks the end of the prior burst and the packet that marks the > beginning of the subsequent burst. It is equal to the timestamp > of the subsequent burst packet, minus the timestamp of the prior > burst packet, plus the duration of the prior burst packet. If > the actual values are not available, estimated values MUST be > used. In the case of a gap that occurs at the beginning of > reception, the sum of the timestamp of the prior burst packet > and the duration of the prior burst packet are replaced by the > reception start time. In the case of a gap that occurs at the > end of reception, the timestamp of the subsequent burst packet > > > > Friedman, Caceres, and Clark, eds. [Page 25] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > is replaced by the reception end time. If there have been no > gap periods, the gap duration value MUST be zero. > > 4.7.3 Delay Metrics > > For the purpose of the following definitions, the RTP interface is > the interface between the RTP instance and the voice application > (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For > example, the time delay due to RTP payload multiplexing would be > considered to be part of the voice application or end-system delay > whereas delay due to multiplexing RTP frames within a UDP frame would > be considered part of the RTP reported delay. This distinction is > consistent with the use of RTCP for delay measurements. > > round trip delay: 16 bits > The most recently calculated round trip time between RTP > interfaces, expressed in milliseconds. This value is the time of > receipt of the most recent RTCP packet from source SSRC, minus > the LSR (last SR) time reported in its SR (sender report), minus > the DLSR (delay since last SR) reported in its SR. A non-zero > LSR value is REQUIRED in order to calculate round trip delay. A > value of 0 is permissible during the first two or three RTCP > exchanges as insufficient data may be available to determine > delay however MUST be populated as soon as a delay estimate is > available. > > end system delay: 16 bits > The most recently estimated end system delay, expressed in > milliseconds. End system delay is defined as the total > encoding, decoding and jitter buffer delay determined at the > reporting endpoint. This is the time required for an RTP frame > to be buffered, decoded, converted to analog form, looped back > at the local analog interface, encoded, and made available for > transmission as an RTP frame. The manner in which this value is > estimated is implementation dependent. This parameter MUST be > provided in all VoIP metrics reports. > > Note that the one way symmetric VoIP segment delay may be calculated > from the round trip and end system delays as follows. If the round > trip delay is denoted RTD and the end system delays associated with > the two endpoints are ESD(A) and ESD(B) then: > > > one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 > > > 4.7.4 Signal Related Metrics > > > > > Friedman, Caceres, and Clark, eds. [Page 26] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > The following metrics are intended to provide real time information > related to the non-packet elements of the voice over IP system to > assist with the identification of problems affecting call quality. > The values identified below must be determined for the received audio > signal. The information required to populate these fields may not be > available in all systems, although it is strongly recommended that > this data SHOULD be provided to support problem diagnosis. > > signal power: 8 bits > The voice signal relative level is defined as the ratio of the > signal level to overflow signal level, expressed in decibels as > a signed integer in two's complement form. This is measured > only for packets containing speech energy. The intent of this > metric is not to provide a precise measurement of the signal > level but to provide a real time indication that the signal > level may be excessively high or low. If the full range > (overflow level) of the Vocoder's digital to analog conversion > function is +/- L and the value of a decoded sample during a > talkspurt is V then the signal level is given by: > > signal level = 10 log10 ( mean( abs(V) / L ) ) > > A value of 127 indicates that this parameter is unavailable. > > residual echo return loss (RERL): 8 bits > The residual echo return loss is defined as the sum of the > measured echo return loss (ERL) and the echo return loss > enhancement (ERLE) expressed in dB as a signed integer in two's > complement form. It defines the ratio of a transmitted voice > signal that is reflected back to the talker. A low level of > echo return loss (say less than 20 dB) in conjunction with some > delay can lead to hollowness or audible echo. A high level of > echo return loss (say over 40 dB) is preferable. > > The ERL and ERLE parameters are often available directly from the > echo cancellor contained within the VoIP end system. They relate to > the echo on the external network attached to the end point. > > In the case of a VoIP gateway this would be line echo that typically > occurs at 2-4 wire conversion points in the network. Echo return > loss from typical 2-4 wire conversions can be in the 8-12 dB range. > A line echo cancellor can provide an ERLE of 30 dB or more and hence > reduce this to 40-50 dB. In the case of an IP phone this could be > residual acoustic echo from speakerphone operation, and may more > correctly be termed terminal coupling loss (TCL). A typical handset > would result in 40-50 dB of echo due to acoustic feedback. > > Typical values for RERL are as follows: > > > > Friedman, Caceres, and Clark, eds. [Page 27] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > (i) IP gateway connected to circuit switched network with 2 wire loop > Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB > RERL = ERL + ERLE = 12 + 0 = 12 dB > > (ii) IP gateway connected to circuit switched network with 2 wire loop > With echo cancellor that improves echo by 30 dB > RERL = ERL + ERLE = 12 + 30 = 42 dB > > (iii) IP phone with conventional handset > Acoustic coupling from handset speaker to microphone 40 dB > Residual echo return loss = TCL = 40 dB > > If we denote the "local" end of the VoIP path as A and the remote end > as B and if the sender loudness rating (SLR) and receiver loudness > rating (RLR) are known for A (default values 8 dB and 2 dB > respectively), then the echo loudness level at end A (talker echo > loudness rating or TELR) is given by: > > TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) > > TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) > > Hence in order to incorporate echo into a voice quality estimate at > the A end of a VoIP connection it is desirable to send the ERL + ERLE > value from B to A. > > For an IP phone with handset this metric MUST be set to the designed > or measured terminal coupling loss, which would typically be 40-50 > dB. > > For a PC softphone or speakerphone this metric MUST be set to either > the value reported by the acoustic echo cancellor or to 127 to > indicate an undefined value. > > For an IP gateway with ERL and ERLE measurements this metric MUST be > reported as ERL + ERLE. > > For an IP gateway without ERL and ERLE measurement capability then > this metric MUST be reported as 12 dB if line echo cancellation is > disabled and 40 dB if line echo cancellation is enabled. > > noise level: 8 bits > The noise level is defined as the ratio of the silent period > back ground noise level to overflow signal power, expressed in > decibels as a signed integer in two's complement form. If the > full range (overflow level) of the Vocoder's digital to analog > conversion function is +/- L and the value of a decoded sample > during a silence period is V then the noise level is given by > > > > Friedman, Caceres, and Clark, eds. [Page 28] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > noise level = 10 log10 ( mean( abs(V) / L ) ) > > A value of 127 indicates that this parameter is unavailable. > > Gmin > See Configuration Parameters (Section 4.7.6, below). > > 4.7.5 Call Quality or Transmission Quality Metrics > > The following metrics are direct measures of the call quality or > transmission quality, and incorporate the effects of CODEC type, > packet loss, discard, burstiness, delay etc. These metrics may not > be available in all systems however SHOULD be provided in order to > support problem diagnosis. > > R factor: 8 bits > The R factor is a voice quality metric describing the segment of > the call that is carried over this RTP session. It is expressed > as an integer in the range 0 to 100, with a value of 94 > corresponding to "toll quality" and values of 50 or less > regarded as unusable. This metric is defined as including the > effects of delay, consistent with ITU-T G.107 [4] and ETSI TS > 101 329-5 [2]. > > A value of 127 indicates that this parameter is unavailable. > > ext. R factor: 8 bits > The external R factor is a voice quality metric describing the > seg ment of the call that is carried over a network segment > external to the RTP segment, for example a cellular network. Its > values are interpreted in the same manner as for the RTP R > factor. This metric is defined as including the effects of > delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 > [2], and relates to the outward voice path from the Voice over > IP termination for which this metrics block applies. > > A value of 127 indicates that this parameter is unavailable. > > Note that an overall R factor may be estimated from the RTP segment R > factor and the external R factor, as follows: > > R total = RTP R factor + ext. R factor - 94 > > MOS-LQ: 8 bits > The estimated mean opinion score for listening quality (MOS-LQ) > is a voice quality metric on a scale from 1 to 5, in which 5 > represents excellent and 1 represents unacceptable. This metric > is defined as not including the effects of delay and can be > > > > Friedman, Caceres, and Clark, eds. [Page 29] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > compared to MOS scores obtained from listening quality (ACR) > tests. It is expressed as an integer in the range 10 to 50, > corresponding to MOS x 10. For example, a value of 35 would > correspond to an estimated MOS score of 3.5. > > A value of 127 indicates that this parameter is unavailable. > > MOS-CQ: 8 bits > The estimated mean opinion score for conversational quality > (MOS-CQ) is defined as including the effects of delay and other > effects that would affect conversational quality. The metric > may be calculated by converting an R factor determined according > to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated > MOS using the equation specified in G.107. It is expressed as > an integer in the range 10 to 50, corresponding to MOS x 10, as > for MOS-LQ. > > A value of 127 indicates that this parameter is unavailable. > > 4.7.6 Configuration Parameters > > Gmin: 8 bits > The gap threshold. This field contains the value used for this > report block to determine if a gap exists. The recommended > value of 16 corresponds to a burst period having a minimum > density of 6.25% of lost or discarded packets, which may cause > noticeable degradation in call quality; during gap periods, if > packet loss or dis card occurs, each lost or discarded packet > would be preceded by and followed by a sequence of at least 16 > received non-discarded packets. Note that lost or discarded > packets that occur within Gmin packets of a report being > generated may be reclassified as being part of a burst or gap in > later reports. ETSI TS 101 329-5 [2] defines a computationally > efficient algorithm for measuring burst and gap density using a > packet loss/discard event driven approach. This algorithm is > reproduced in Appendix A.2 of the present document. Gmin MUST > not be zero and MUST be provided. > > receiver configuration byte (RX config): 8 bits > This byte consists of the following fields: > > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |PLC|JBA|JB rate| > +-+-+-+-+-+-+-+-+ > > > > > > Friedman, Caceres, and Clark, eds. [Page 30] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > packet loss concealment (PLC): 2 bits > Standard (11) / enhanced (10) / disabled (01) / unspecified > (00). When PLC = 11 then a simple replay or interpolation > algorithm is being used to fill-in the missing packet. > This is typically able to conceal isolated lost packets > with loss rates under 3%. When PLC = 10 then an enhanced > interpolation algorithm is being used. This would > typically be able to conceal lost packets for loss rates of > 10% or more. When PLC = 01 then silence is inserted in > place of lost packets. When PLC = 00 then no information > is available concerning the use of PLC however for some > CODECs this may be inferred. > > jitter buffer adaptive (JBA): 2 bits > Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown > (00). When the jitter buffer is adaptive then its size is > being dynamically adjusted to deal with varying levels of > jitter. When non-adaptive, the jitter buffer size is > maintained at a fixed level. When either adaptive or non- > adaptive modes are specified then the jitter buffer size > parameters below MUST be specified. > > jitter buffer rate (JB rate): 4 bits > J = adjustment rate (0-15). This represents the > implementation specific adjustment rate of a jitter buffer > in adaptive mode. This parameter is defined in terms of the > approximate time taken to fully adjust to a step change in > peak to peak jitter from 30 ms to 100 ms such that: > > adjustment time = 2 * J * frame size (ms) > > This parameter is intended only to provide a guide to the > degree of "aggressiveness" of a an adaptive jitter buffer > and may be estimated. A value of 0 indicates that the > adjustment time is unknown for this implementation. > > 4.7.7 Jitter Buffer Parameters > > jitter buffer nominal size in frames (JB nominal): 8 bits > This is the current nominal fill point within the jitter buffer, > which corresponds to the nominal jitter buffer delay for packets > that arrive exactly on time. This parameter MUST be provided > for both fixed and adaptive jitter buffer implementations. > > jitter buffer maximum size in frames (JB maximum): 8 bits > This is the current maximum jitter buffer level corresponding to > the earliest arriving packet that would not be discarded. In > simple queue implementations this may correspond to the nominal > > > > Friedman, Caceres, and Clark, eds. [Page 31] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > size. In adaptive jitter buffer implementations this value may > dynamically vary up to JB abs max (see below). This parameter > MUST be provided for both fixed and adaptive jitter buffer > implementations. > > jitter buffer absolute maximum size in frames (JB abs max): 8 bits > This is the absolute maximum size that the adaptive jitter > buffer can reach under worst case jitter conditions. This > parameter MUST be provided for adaptive jitter buffer > implementations and its value MUST be set to JB maximum for > fixed jitter buffer implementations. > > 5. IANA Considerations > > This document defines a new RTP packet type, the extended report (XR) > type, within the existing Internet Assigned Numbers Authority (IANA) > registry of RTP RTCP Control Packet Types. This document also > defines a new IANA registry: the registry of RTP XR Block Types. > Within this new registry, this document defines an initial set of > seven block types and describes how the remaining types are to be > allocated. > > 5.1 XR Packet Type > > The IANA SHALL register the RTP extended report (XR) packet defined > by this document as packet type 207 in the registry of RTP RTCP > Control Packet types (PT). > > 5.2 RTP XR Block Type Registry > > The IANA SHALL create the RTP XR Block Type Registry to cover the > name space of the extended report block type (BT) field specified in > Section 3 of this document. The BT field contains eight bits, > allowing 256 values. The IANA SHALL manage the RTP XR Block Type > Registry according to the Specification Required policy of RFC 2434 > [6]. Future specifications SHOULD attribute block type values in > strict numeric order following the values attributed in this > document: > > > > > > > > > > > > > > Friedman, Caceres, and Clark, eds. [Page 32] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > BT name > -- ---- > 1 Loss RLE Report Block > 2 Duplicate RLE Report Block > 3 Timestamp Report Block > 4 Statistics Summary Report Block > 5 Receiver Timestamp Report Block > 6 DLRR Report Block > 7 VoIP Metrics Report Block > > > Furthermore, future specifications SHOULD avoid the values 0 and 255. > Doing so facilitates packet validity checking, since all-zeros and > all-ones are values that might commonly be found in ill-formed > packets. > > 6. Security Considerations > > This document extends the RTCP reporting mechanism. The security > considerations that apply to RTCP reports also apply to XR reports. > This section details the additional security considerations that > apply to the extensions. > > The extensions introduce heightened confidentiality concerns. > Standard RTCP reports contain a limited number of summary statistics. > The information contained in XR reports is both more detailed and > more extensive (covering a larger number of parameters). The per- > packet information contained in Loss RLE, Duplicate RLE, and > Timestamp Report Blocks facilitates MINC inference of multicast > distribution trees for RTP data packets, and inference of link > characteristics such as loss and delay. This inference reveals > information that might otherwise be considered confidential to > autonomous system administrators. The VoIP Metrics Report Block > provides information on the quality of ongoing voice calls. Though > such information might be carried in application specific format in > standard RTP sessions, making it available in a standard format here > makes it more available to potential eavesdroppers. > > No new mechanisms are introduced in this document to ensure > confidentiality. Standard encryption procedures can be used when > confidentiality is a concern to end hosts. Autonomous system > administrators concerned about the loss of confidentiality regarding > their networks can encrypt traffic, or filter it to exclude RTCP > packets containing the XR report blocks concerned. > > Any encryption or filtering of XR report blocks entails a loss of > monitoring information to third parties. For example, a network that > establishes a tunnel to encrypt VoIP Report Blocks denies that > > > > Friedman, Caceres, and Clark, eds. [Page 33] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > information to the service providers traversed by the tunnel. The > service providers cannot then monitor or respond to the quality of > the VoIP calls that they carry, potentially creating problems for the > network's users. As a default, XR packets SHOULD NOT be encrypted or > filtered. > > The extensions also make certain denial of service attacks easier. > This is because of the potential to create RTCP packets much larger > than average with the per packet reporting capabilities of the Loss > RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the > automatic bandwidth adjustment mechanisms in RTCP, if some session > participants are sending large RTCP packets, all participants will > see their RTCP reporting intervals lengthened, meaning they will be > able to report less frequently. To limit the effects of large > packets, even in the absence of denial of service attacks, > applications SHOULD limit the size of XR report blocks and employ the > thinning techniques described in this document in order to fit > reports into the space available. > > A. Algorithms > > A.1 Sequence Number Interpretation > > This the algorithm suggested by Section 4.1 for keeping track of the > sequence numbers from a given sender. It implements the accounting > practice required for the generation of Loss RLE Report Blocks. > > This algorithm keeps track of 16 bit sequence numbers by translating > them into a 32 bit sequence number space. The first packet received > from a source is considered to have arrived roughly in the middle of > that space. Each packet that follows is placed either ahead or > behind the prior one in this 32 bit space, depending upon which > choice would place it closer (or, in the event of a tie, which choice > would not require a rollover in the 16 bit sequence number). > > // The reference sequence number is an extended sequence number > // that serves as the basis for determining whether a new 16 bit > // sequence number comes earlier or later in the 32 bit sequence > // space. > u_int32 _src_ref_seq; > bool _uninitialized_src_ref_seq; > > // Place seq into a 32-bit sequence number space based upon a > // heuristic for its most likely location. > u_int32 extend_seq(const u_int16 seq) { > > u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; > if(_uninitialized_src_ref_seq) { > > > > Friedman, Caceres, and Clark, eds. [Page 34] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > // This is the first sequence number received. Place > // it in the middle of the extended sequence number > // space. > _src_ref_seq = seq | 0x80000000u; > _uninitialized_src_ref_seq = false; > extended_seq = _src_ref_seq; > } > else { > > // Prior sequence numbers have been received. > // Propose two candidates for the extended sequence > // number: seq_a is without wraparound, seq_b with > // wraparound. > seq_a = seq | (_src_ref_seq & 0xFFFF0000u); > if(_src_ref_seq < seq_a) { > seq_b = seq_a - 0x00010000u; > diff_a = seq_a - _src_ref_seq; > diff_b = _src_ref_seq - seq_b; > } > else { > seq_b = seq_a + 0x00010000u; > diff_a = _src_ref_seq - seq_a; > diff_b = seq_b - _src_ref_seq; > } > > // Choose the closer candidate. If they are equally > // close, the choice is somewhat arbitrary: we choose > // the candidate for which no rollover is necessary. > if(diff_a < diff_b) { > extended_seq = seq_a; > } > else { > extended_seq = seq_b; > } > > // Set the reference sequence number to be this most > // recently-received sequence number. > _src_ref_seq = extended_seq; > } > > // Return our best guess for a 32-bit sequence number that > // corresponds to the 16-bit number we were given. > return extended_seq; > } > > A.2 Example Burst Packet Loss Calculation. > > This is an algorithm for measuring the burst characteristics for the > > > > Friedman, Caceres, and Clark, eds. [Page 35] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI > TS 101 329-5 [2]. The algorithm is event driven and hence extremely > computationally efficient. > > Given the following definition of states: > > > state 1 = received a packet during a gap > state 2 = received a packet during a burst > state 3 = lost a packet during a burst > state 4 = lost an isolated packet during a gap > > > The "c" variables below correspond to state transition counts, i.e. > c14 is the transition from state 1 to state 4. It is possible to > infer one of a pair of state transition counts to an accuracy of 1 > which is generally sufficient for this application. > > "pkt" is the count of packets received since the last packet was > declared lost or discarded and "lost" is the number of packets lost > within the current burst. "packet_lost" and "packet_discarded" are > boolean variables that indicate if the event that resulted in this > function being invoked was a lost or discarded packet. > > if(packet_lost) { > loss_count++; > } > if(packet_discarded) { > discard_count++; > } > if(!packet_lost && !packet_discarded) { > pkt++; > } > else { > if(pkt >= gmin) { > if(lost == 1) { > c14++; > } > else { > c13++; > } > lost = 1; > c11 += pkt; > } > else { > lost++; > if(pkt == 0) { > c33++; > > > > Friedman, Caceres, and Clark, eds. [Page 36] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > } > else { > c23++; > c22 += (pkt - 1); > } > } > pkt = 0; > } > > At each reporting interval the burst and gap metrics can be > calculated as follows. > > // Calculate additional transition counts. > c31 = c13; > c32 = c23; > ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; > > // Calculate burst and densities. > p32 = c32 / (c31 + c32 + c33); > if((c22 + c23) < 1) { > p23 = 1; > } > else { > p23 = 1 - c22/(c22 + c23); > } > burst_density = 256 * p23 / (p23 + p32); > gap_density = 256 * c14 / (c11 + c14); > > // Calculate burst and gap durations in ms > m = frameDuration_in_ms * framesPerRTPPkt; > gap_length = (c11 + c14 + c13) * m / c13; > burst_length = ctotal * m / c13 - lgap; > > /* calculate loss and discard densities */ > loss_density = 256 * loss_count / ctotal; > discard_density = 256 * discard_count / ctotal; > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP 11 [3]. Copies > of claims of rights made available for publication and any assurances > > > > Friedman, Caceres, and Clark, eds. [Page 37] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > of licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgements > > We thank the following people: Colin Perkins, Steve Casner, and > Henning Schulzrinne for their considered guidance; Sue Moon for > helping foster collaboration between the authors; Magnus Westerlund > for his detailed comments; Mounir Benzaid for drawing our attention > to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz > for encouraging us to incorporate MLDA block types. > > > > > Friedman, Caceres, and Clark, eds. [Page 38] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > Contributors > > The following people are the authors of this document: > > Kevin Almeroth, UCSB > Ramon Caceres, ShieldIP > Alan Clark, Telchemy > Robert Cole, AT&T Labs > Nick Duffield, AT&T Labs-Research > Timur Friedman, Paris 6 > Kaynam Hedayat, Brix Networks > Kamil Sarac, UT Dallas > > The principal people to contact regarding the individual report > blocks described in this document are as follows: > > > sec. report block principal contributors > ---- ------------ ---------------------- > 4.1 Loss RLE Report Block Friedman, Caceres, Duffield > 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield > 4.3 Timestamp Report Block Friedman, Caceres, Duffield > 4.4 Statistics Summary Report Block Almeroth, Sarac > 4.5 Receiver Timestamp Report Block Friedman > 4.6 DLRR Report Block Friedman > 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat > > > Authors' Addresses > > Kevin Almeroth > Department of Computer Science > University of California > Santa Barbara, CA 93106 USA > > Ramon Caceres > ShieldIP, Inc. > 11 West 42nd Street, 31st Floor > New York, NY 10036 USA > > Alan Clark > Telchemy Incorporated > 3360 Martins Farm Road, Suite 200 > Suwanee, GA 30024 USA > Tel: +1 770 614 6944 > Fax: +1 770 614 3951 > > > > > > Friedman, Caceres, and Clark, eds. [Page 39] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > Robert Cole > AT&T Labs > 330 Saint Johns Street, > 2nd Floor > Havre de Grace, MD 21078 USA > Tel: +1 410 939 8732 > Fax: +1 410 939 8732 > > Nick Duffield > AT&T Labs-Research > 180 Park Avenue, P.O. Box 971 > Florham Park, NJ 07932-0971 USA > Tel: +1 973 360 8726 > Fax: +1 973 360 8050 > > Timur Friedman > Universite Pierre et Marie Curie (Paris 6) > Laboratoire LiP6-CNRS > 8, rue du Capitaine Scott > 75015 PARIS France > Tel: +33 1 44 27 71 06 > Fax: +33 1 44 27 74 95 > > Kaynam Hedayat > Brix Networks > 285 Mill Road > Chelmsford, MA 01824 USA > Tel: +1 978 367 5600 > Fax: +1 978 367 5700 > > Kamil Sarac > Department of Computer Science (ES 4.207) > Eric Jonsson School of Engineering & Computer Science > University of Texas at Dallas > Richardson, TX 75083-0688 USA > Tel: +1 972 883 2337 > Fax: +1 972 883 2349 > > References > > The references are divided into normative references and non- > normative references. > > Normative References > > [1] S. Bradner, "Key words for use in RFCs to indicate requirement > levels," BCP 14, RFC 2119, IETF, March 1997. > > > > > Friedman, Caceres, and Clark, eds. [Page 40] > > draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 > > > [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI > TS 101 329-5 V1.1.1 (2000-11), November 2000. > > [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF > Standards Process," best current practice BCP 11, RFC 2028, IETF, > October 1996. > > [4] ITU-T, "The E-Model, a computational model for use in > transmission planning," Recommendation G.107 (05/00), May 2000. > > [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, > RFC 1700, IETF, October 1994. > > [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA > Considerations Section in RFCs," best current practice BCP 26, RFC > 2434, IETF, October 1998. > > [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A > transport protocol for real-time applications," RFC 1889, IETF, > February 1996. > > Non-Normative References > > [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. > Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The > Use of End-to-End Multicast Measurements for Characterizing Internal > Network Behavior," IEEE Communications Magazine, May 2000. > > [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu > measurement infrastructures using RTP," Proc. IEEE Infocom 2002. > > [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and > Recency on Subjective Voice Quality," Proc. IP Telephony Workshop > 2001. > > [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion > Control Framework for Heterogeneous Multicast Environments", Proc. > IWQoS 2000. > > > > > > > > > > > > > > Friedman, Caceres, and Clark, eds. [Page 41] > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 20 05:17:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06338 for ; Thu, 20 Feb 2003 05:17:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KAO7S00522 for avt-archive@odin.ietf.org; Thu, 20 Feb 2003 05:24:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KANgp00510; Thu, 20 Feb 2003 05:23:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KAK4p00379 for ; Thu, 20 Feb 2003 05:20:04 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06248 for ; Thu, 20 Feb 2003 05:13:00 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1KAGoAv028240; Thu, 20 Feb 2003 11:16:50 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4GB4A8; Thu, 20 Feb 2003 11:16:50 +0100 Message-ID: <3E54AB12.4040509@era.ericsson.se> Date: Thu, 20 Feb 2003 11:16:50 +0100 X-Sybari-Trust: 64e02af6 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timur Friedman CC: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt References: <200301242135.31937.timur.friedman@lip6.fr> <200301242156.03464.timur.friedman@lip6.fr> Content-Type: text/plain; charset=UTF-8; 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Timur, I have in the last few weeks come to some insight on where I desire to use some of the reporting blocks. Therefore I have two general comments on what I would in fact like to add to the XR format: 1. I would like to add SDP signaling to the draft. In the use case of streaming when only the server sends media to the client there is no need for the server to send XR report blocks of other types then responses to RTT measurements. However the server may very much desire to receive the XR formats. However some other servers may not support the XR format and then it would be waste of bandwidth. Therefore I see a need for allowing the server to ask the client to send XR reports and which formats it is interested in. It also seem to be interesting to have the recipient ask for what thinning factor it would like to see. Also the reporting overlap between each packet, i.e. should each packet report on the new data from last report and also how many already reported packets. All this is of course only recommendations to the send of the XR packet. They may need to reevaluate the request based on bandwidth consumption etc. This is my motivation therefore I propose the following SDP parameter chapter to be included in the draft: ---------------------------------- x SDP Signaling for the XR Format To allow the recipient of XR format to specify what format it would like to receive the following media level SDP attribute is defined. If included in a SDP media block the recipient of the SDP is RECOMMENDED to send RTCP XR reports containing the report blocks indicated in the attribute. To allow the recipient to also direct the sender of XR reports on what configuration it desires on each block some parameters are also possible to define for each report block type. These are also only recommendations to the sender and MAY be ignored due to other considerations. Such other considerations is for example, complexity of gathering the information, and the bandwidth usage imposed by the reporting. The SDP attribute is defined as following in ABNF of RFC 2234 XR-attriute = "a" "=" "rtcp-xr" ":" xr-format *(";" xr-format) CRLF xr-format = loss-rle-def / dupp-rle-def / timestamp-def / stat-sum-def / rcv-time-RTT-def / DLRR-def / VOIP-metrics-def / extension-type loss-rle-def = "loss-rle" "=" overlap "/" thinning-factor dupp-rle-def = "dupp-rle" "=" overlap "/" thinning-factor timestamp-def = "rcv-time" "=" overlap "/" thinning-factor stat-sum-def = "stat-sum" "=" loss-flag "/" dupp-flag "/" jitt-flag "/" TTL-flag loss-flag = boolean ; Include loss block dupp-flag = boolean ; Include duplicate block jitt-flag = boolean ; Include jitter block ttl-flag = boolean ; Include TTL block boolean = "0" / "1" ; False or True rcv-time-RTT-def = "rcv-rtt" "=" boolean DLRR-def = "dlrr" "=" boolean VOIP-metrics-def = "voip" "=" "1" extension-type = token "=" Value *("/" Value) Value = token / quoted-stirng overlap = 1*DIGIT ; thinning-factor = 1*2DIGIT ; 0-15 is valid values The "overlap" factor tells the sender of reports how many reporting intervals the statistics should cover. A overlap factor of 0 means only information gathered since the last report using this format. An overlap factor of 1 would mean that the reporter should send information gathered both since the last sent report and the previous sent report packet. The thinning factor is the value the reporter should use in its report. It is defined for each of the report blocks that has this value and valid values are 0-15. The "stat-sum" parameter contains boolean flags (0 or 1) for each of the four parts that can be included in this packet. The "stat-sum" parameter SHOULD NOT be included unless at least one of the block flags are true, i.e. signaling inclusion of some block. The "rcv-rtt" parameter tells the receiver of this SDP if it can use the block or not within the session. By including this parameter with a true value the source of the SDP indicates that it will respond using the DLRR report block and that it is meaningful to send Receiver Timestamp Report Block. This parameter is useful for servers or multicast senders to indicate its support for allowing the receiver to measure the RTT. It is always the receivers choice to send Receiver Timestamp Report blocks. The "dlrr" parameter indicates by its value of true or false if the reporter SHOULD answer Receiver Timestamp report blocks it receives using the DLRR report block. This allows a multicast session sender to recommend the receiver of the session to not waste RTCP bandwidth on RTT measurements. The presence of the "voip" parameter indicates that the reporter is RECOMMENDED to include the report block in the RTCP XR format. It has a hard coded value to simplify parsing as all parameters have the structure = This format is extensible as new report blocks are included. Recipients of the SDP attribute SHOULD ignore any unknown parameters by skipping to past the next ";" or if non present to the end of line. ----------------------------------- A IANA repository needs to be established for this SDP attribute to enable future extensions. The same rules that applies to registering XR report blocks apply to registering new attribute parameters. 2. The timestamp report block results in extremely large reports I think the block would much more useful if it default contains a less bandwidth using scheme for reporting the timestamps. My proposal is to change the format to the following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First RTP timestamp and base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable length encoded diff 1| diff 2 | Diff 3 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ My idea is to take the first packet reception timestamp as is to form a base. Then for each following packet only the delta timestamp value from the previous packet is included. To save bytes this values is then encoded as one, two, three or four octets. This would in most case allow for reducing this block with 50% or more. At the same time the operation is not that complex and does not require substantial amount of processing. to end up on the next 32 bit boundary padding is required. This padding is easy to find as the number of reports are indicated with initial and last sequence number of the packets and the thinning factor. A simple variable length encoding would be: 0-127 1 byte with first bit = 0, i.e. 0xxxxxxx 128-16383 2 bytes in the form 0xxxxxxx1xxxxxxx 16384-2097151 3 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx 2097151-268435455 4 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx1xxxxxxx As this clock is running at the media clocks used it will have rates from 1000 up to 90000 in most case. For most packet rates that will mean that the diff between each packet will fit into a 2 byte value instead of four, reducing the necessary block size with almost 50 %. I assume that there are smarter variable encoding. So please propose anything that works better. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Feb 20 17:25:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01986 for ; Thu, 20 Feb 2003 17:25:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KMWB021739 for avt-archive@odin.ietf.org; Thu, 20 Feb 2003 17:32:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMTOp21545; Thu, 20 Feb 2003 17:29:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMROp21485 for ; Thu, 20 Feb 2003 17:27:24 -0500 Received: from snnyroch50.secarch.gblxint.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01813 for ; Thu, 20 Feb 2003 17:20:07 -0500 (EST) Received: from snnyroch50.secarch.gblxint.com (localhost [127.0.0.1]) by localhost.secarch.gblxint.com (Postfix) with ESMTP id 5AFAE77809; Thu, 20 Feb 2003 17:23:57 -0500 (EST) Received: from snnyroch03.east.globalcrossing.com (snnyroch03.ams.gblxint.com [10.60.16.183]) by snnyroch50.secarch.gblxint.com (Postfix) with ESMTP id 03BBA77773; Thu, 20 Feb 2003 17:23:56 -0500 (EST) Received: from exnarocims2.ams.gblxint.com (exnarocims2.ams.gblxint.com [10.60.19.33]) by snnyroch03.east.globalcrossing.com (8.9.3/8.9.3) with ESMTP id RAA04413; Thu, 20 Feb 2003 17:23:51 -0500 (EST) Received: by exnarocims2.ams.gblxint.com with Internet Mail Service (5.5.2653.19) id <1NKSMH5D>; Thu, 20 Feb 2003 17:23:56 -0500 Message-ID: <81BF85F8C018D511B44A00508BB8B4790500A9DD@exnarocmbx1.ams.gblxint.com> From: "Uzelac, Adam" To: "'avt@ietf.org'" Cc: "'auzelac@gblx.net'" Date: Thu, 20 Feb 2003 17:23:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] Concurrent Call Rate Information 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Is there anywhere within the data structure of RTCP where concurrent call rate information is captured, or could be captured? Thank you in advance.... -Adam Uzelac _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 21 10:23:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03262 for ; Fri, 21 Feb 2003 10:23:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LFUJa30456 for avt-archive@odin.ietf.org; Fri, 21 Feb 2003 10:30:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFTlp30389; Fri, 21 Feb 2003 10:29:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFSAp30344 for ; Fri, 21 Feb 2003 10:28:10 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03206 for ; Fri, 21 Feb 2003 10:20:32 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h1LFOMsH003721 for ; Fri, 21 Feb 2003 10:24:22 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302211524.h1LFOMsH003721@purple.nge.isi.edu> To: avt@ietf.org Subject: Re: [AVT] Meeting in San Francisco In-Reply-To: Your message of "Mon, 10 Feb 2003 09:42:34 EST." <200302101442.h1AEgYdw004067@purple.nge.isi.edu> Date: Fri, 21 Feb 2003 10:24:22 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , A reminder that the submission deadline for -00 internet-drafts is 9:00am EST (GMT -05:00) on Monday. Colin --> Colin Perkins writes: >The AVT working group is scheduled for two slots at the 56th IETF meeting >in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am >on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These >dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. > >Those wanting agenda time at the meeting should contact the working group >chairs by 3rd March. Submitting a draft does not automatically provide >agenda time. > >You are reminded that the cut-off date for -00 Internet Draft submissions >is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior >approval from the chairs, -00 submissions should have filenames with the >format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts >received after 24th February will not be accepted. > >All other Internet-Draft submissions must be made by Monday, 3rd March at >9:00am EST. > >Drafts which are submitted late and do not make the cutoff date will not be >discussed at the meeting. > >-- >Colin Perkins >http://csperkins.org/ >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Feb 22 19:41:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18313 for ; Sat, 22 Feb 2003 19:41:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N0mqQ18588 for avt-archive@odin.ietf.org; Sat, 22 Feb 2003 19:48:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0mEp18577; Sat, 22 Feb 2003 19:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0hEp18370 for ; Sat, 22 Feb 2003 19:43:14 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18275 for ; Sat, 22 Feb 2003 19:34:55 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1N0cjVR023743 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Sun, 23 Feb 2003 01:38:45 +0100 X-pt: isis.lip6.fr Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1N0cj302970; Sun, 23 Feb 2003 01:38:45 +0100 (MET) From: "Timur Friedman" To: "'Magnus Westerlund'" Cc: Subject: RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Sun, 23 Feb 2003 01:38:45 +0100 Message-ID: <02ad01c2dad3$ec6127e0$a648e384@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E54AB12.4040509@era.ericsson.se> X-Scanned-By: isis.lip6.fr 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Magnus, [I address the signalling in this mail, and the timestamp block in a subsequent mail.] Getting a handle on the signalling for RTP XR reports is a major priority. Thank you for taking the initiative to think through how it might be done. I wonder, though, if it would be alright if we were to submit this as a subsequent draft. The concern is that introducing a significant change at this point would make it difficult to proceed to working group last call at San Francisco. If not having signalling means we should not propose a standard then of course we should wait. But to my mind the extended reports are useful in themselves, and a proposed standard will allow important work to go forward. Part of this work will entail applications that deploy these reports. With the experience gained, we may be in a better position to say exactly how signalling should be done than we are now. Best regards, Timur -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Thursday, February 20, 2003 11:17 AM To: Timur Friedman Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Hi Timur, I have in the last few weeks come to some insight on where I desire to use some of the reporting blocks. Therefore I have two general comments on what I would in fact like to add to the XR format: 1. I would like to add SDP signaling to the draft. In the use case of streaming when only the server sends media to the client there is no need for the server to send XR report blocks of other types then responses to RTT measurements. However the server may very much desire to receive the XR formats. However some other servers may not support the XR format and then it would be waste of bandwidth. Therefore I see a need for allowing the server to ask the client to send XR reports and which formats it is interested in. It also seem to be interesting to have the recipient ask for what thinning factor it would like to see. Also the reporting overlap between each packet, i.e. should each packet report on the new data from last report and also how many already reported packets. All this is of course only recommendations to the send of the XR packet. They may need to reevaluate the request based on bandwidth consumption etc. This is my motivation therefore I propose the following SDP parameter chapter to be included in the draft: ---------------------------------- x SDP Signaling for the XR Format To allow the recipient of XR format to specify what format it would like to receive the following media level SDP attribute is defined. If included in a SDP media block the recipient of the SDP is RECOMMENDED to send RTCP XR reports containing the report blocks indicated in the attribute. To allow the recipient to also direct the sender of XR reports on what configuration it desires on each block some parameters are also possible to define for each report block type. These are also only recommendations to the sender and MAY be ignored due to other considerations. Such other considerations is for example, complexity of gathering the information, and the bandwidth usage imposed by the reporting. The SDP attribute is defined as following in ABNF of RFC 2234 XR-attriute = "a" "=" "rtcp-xr" ":" xr-format *(";" xr-format) CRLF xr-format = loss-rle-def / dupp-rle-def / timestamp-def / stat-sum-def / rcv-time-RTT-def / DLRR-def / VOIP-metrics-def / extension-type loss-rle-def = "loss-rle" "=" overlap "/" thinning-factor dupp-rle-def = "dupp-rle" "=" overlap "/" thinning-factor timestamp-def = "rcv-time" "=" overlap "/" thinning-factor stat-sum-def = "stat-sum" "=" loss-flag "/" dupp-flag "/" jitt-flag "/" TTL-flag loss-flag = boolean ; Include loss block dupp-flag = boolean ; Include duplicate block jitt-flag = boolean ; Include jitter block ttl-flag = boolean ; Include TTL block boolean = "0" / "1" ; False or True rcv-time-RTT-def = "rcv-rtt" "=" boolean DLRR-def = "dlrr" "=" boolean VOIP-metrics-def = "voip" "=" "1" extension-type = token "=" Value *("/" Value) Value = token / quoted-stirng overlap = 1*DIGIT ; thinning-factor = 1*2DIGIT ; 0-15 is valid values The "overlap" factor tells the sender of reports how many reporting intervals the statistics should cover. A overlap factor of 0 means only information gathered since the last report using this format. An overlap factor of 1 would mean that the reporter should send information gathered both since the last sent report and the previous sent report packet. The thinning factor is the value the reporter should use in its report. It is defined for each of the report blocks that has this value and valid values are 0-15. The "stat-sum" parameter contains boolean flags (0 or 1) for each of the four parts that can be included in this packet. The "stat-sum" parameter SHOULD NOT be included unless at least one of the block flags are true, i.e. signaling inclusion of some block. The "rcv-rtt" parameter tells the receiver of this SDP if it can use the block or not within the session. By including this parameter with a true value the source of the SDP indicates that it will respond using the DLRR report block and that it is meaningful to send Receiver Timestamp Report Block. This parameter is useful for servers or multicast senders to indicate its support for allowing the receiver to measure the RTT. It is always the receivers choice to send Receiver Timestamp Report blocks. The "dlrr" parameter indicates by its value of true or false if the reporter SHOULD answer Receiver Timestamp report blocks it receives using the DLRR report block. This allows a multicast session sender to recommend the receiver of the session to not waste RTCP bandwidth on RTT measurements. The presence of the "voip" parameter indicates that the reporter is RECOMMENDED to include the report block in the RTCP XR format. It has a hard coded value to simplify parsing as all parameters have the structure = This format is extensible as new report blocks are included. Recipients of the SDP attribute SHOULD ignore any unknown parameters by skipping to past the next ";" or if non present to the end of line. ----------------------------------- A IANA repository needs to be established for this SDP attribute to enable future extensions. The same rules that applies to registering XR report blocks apply to registering new attribute parameters. ... _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Feb 22 19:55:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18449 for ; Sat, 22 Feb 2003 19:55:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N13ki19285 for avt-archive@odin.ietf.org; Sat, 22 Feb 2003 20:03:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N13Ap19273; Sat, 22 Feb 2003 20:03:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N10vp19223 for ; Sat, 22 Feb 2003 20:00:57 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18427 for ; Sat, 22 Feb 2003 19:52:36 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1N0uRVR024007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Sun, 23 Feb 2003 01:56:27 +0100 X-pt: isis.lip6.fr Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1N0uR303306; Sun, 23 Feb 2003 01:56:27 +0100 (MET) From: "Timur Friedman" To: "'Magnus Westerlund'" Cc: Subject: RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Sun, 23 Feb 2003 01:56:27 +0100 Message-ID: <02cd01c2dad6$655aef30$a648e384@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E54AB12.4040509@era.ericsson.se> X-Scanned-By: isis.lip6.fr 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Magnus, [I address the comments relating to the timestamp report block in this mail. A previous mail addressed the comments relating to signalling.] I agree that the timestamp report block potentially uses a large amount of space, and could benefit from compression. The method you propose looks promising to me. As in the case of signalling, though, I wonder if we could not go forward with the present format and consider this for a subsequent draft. We proposed the Loss RLE block, for instance, after studying a number of different compression techniques and concluding that run length encoding, while not always offering the best ratio, was simple and could reliably provide 5:1 compression over a fair range, given typical observed loss patterns. The current format for timestamps allows timestamps to be reported in a simple and straightforward way. It does not preclude a future format that would show better compression characteristics. Best regards, Timur -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Thursday, February 20, 2003 11:17 AM To: Timur Friedman Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Hi Timur, I have in the last few weeks come to some insight on where I desire to use some of the reporting blocks. Therefore I have two general comments on what I would in fact like to add to the XR format: ... 2. The timestamp report block results in extremely large reports I think the block would much more useful if it default contains a less bandwidth using scheme for reporting the timestamps. My proposal is to change the format to the following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First RTP timestamp and base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable length encoded diff 1| diff 2 | Diff 3 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ My idea is to take the first packet reception timestamp as is to form a base. Then for each following packet only the delta timestamp value from the previous packet is included. To save bytes this values is then encoded as one, two, three or four octets. This would in most case allow for reducing this block with 50% or more. At the same time the operation is not that complex and does not require substantial amount of processing. to end up on the next 32 bit boundary padding is required. This padding is easy to find as the number of reports are indicated with initial and last sequence number of the packets and the thinning factor. A simple variable length encoding would be: 0-127 1 byte with first bit = 0, i.e. 0xxxxxxx 128-16383 2 bytes in the form 0xxxxxxx1xxxxxxx 16384-2097151 3 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx 2097151-268435455 4 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx1xxxxxxx As this clock is running at the media clocks used it will have rates from 1000 up to 90000 in most case. For most packet rates that will mean that the diff between each packet will fit into a 2 byte value instead of four, reducing the necessary block size with almost 50 %. I assume that there are smarter variable encoding. So please propose anything that works better. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 03:07:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04253 for ; Mon, 24 Feb 2003 03:07:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O8Fn005846 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 03:15:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8FBp05830; Mon, 24 Feb 2003 03:15:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8Cdp05756 for ; Mon, 24 Feb 2003 03:12:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04238 for ; Mon, 24 Feb 2003 03:03:41 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1O87YAv014725; Mon, 24 Feb 2003 09:07:34 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVNDPQ4; Mon, 24 Feb 2003 09:07:34 +0100 Message-ID: <3E59D2C6.80708@era.ericsson.se> Date: Mon, 24 Feb 2003 09:07:34 +0100 X-Sybari-Trust: 995a2910 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timur Friedman CC: avt@ietf.org Subject: Re: RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt References: <02ad01c2dad3$ec6127e0$a648e384@lip6.fr> 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Timur, Comments below. Timur Friedman wrote: >I wonder, though, if it would be alright if we were to submit this as a >subsequent draft. The concern is that introducing a significant change >at this point would make it difficult to proceed to working group last >call at San Francisco. > > I think that signaling is fundamental enough to this draft that it warrants to put it in directly. I would also not like to delay this draft. I would like to see it submitted to the IESG before May. I think that is still possible, especially if you would add this functionality in a update that you can submit before mondays cut-off date. You can take my text and rework it into suitable text for your draft. Then we can have a healthy discussion on this in San Francisco. Then after the meeting update the draft if any comments has been given. The have a WG last call in early April. There is no need to either ask or have WG last calls in relations to meetings. It might even be better as people will have more time to read the document. In my opinion the author of a draft can very much effect the time that a draft takes to finish. You can shave of many weeks by simple being quick to reply and create updates when needed. Then ensuring that the WG chairs perform there work and makes last calls, send it to IESG, etc. also speeds things up. >If not having signalling means we should not propose a standard then of >course we should wait. But to my mind the extended reports are useful >in themselves, and a proposed standard will allow important work to go >forward. > > Yes, they are useful in applications that are of more conversational type. In these you can detect that the other party implements and send them. Then you can also send them. However in applications like on-demand streaming where media only flows one way it is not possible in a sensible way to make the receiver application aware of the servers desire to receive XR reports. Sending empty XR packets just to indicate support for XR formats seems wasteful of bandwidth. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 11:00:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17558 for ; Mon, 24 Feb 2003 11:00:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OG8cj03132 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 11:08:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OG80p03091; Mon, 24 Feb 2003 11:08:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OG6Dp02303 for ; Mon, 24 Feb 2003 11:06:13 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17525 for ; Mon, 24 Feb 2003 10:57:06 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h1OG10w11925 for ; Mon, 24 Feb 2003 11:01:00 -0500 Message-Id: <200302241601.h1OG10w11925@chiron.nge.isi.edu> To: avt@ietf.org Subject: Re: [AVT] Meeting in San Francisco In-Reply-To: Your message of "Mon, 10 Feb 2003 09:42:34 EST." <200302101442.h1AEgYdw004067@purple.nge.isi.edu> Date: Mon, 24 Feb 2003 11:01:00 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Folks, The submission deadline for -00 drafts has now passed. Other drafts are due one week from today. If you have submitted a draft, and need agenda time to discuss it, you should contact the working group chairs. We currently have agenda requests for the following: RTP Extended Reports (RTP XR) (Friedman/Clark) Framing RTP over Connection-Oriented Transport (Lazzaro) The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) RTP Payload Format for iLBC Speech (Duric) RTP payload format for a 64 kbit/s voice band data call (Kreuter) RTP Payload Format for the Speex Codec (Herlien) Colin --> Colin Perkins writes: >The AVT working group is scheduled for two slots at the 56th IETF meeting >in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am >on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These >dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. > >Those wanting agenda time at the meeting should contact the working group >chairs by 3rd March. Submitting a draft does not automatically provide >agenda time. > >You are reminded that the cut-off date for -00 Internet Draft submissions >is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior >approval from the chairs, -00 submissions should have filenames with the >format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts >received after 24th February will not be accepted. > >All other Internet-Draft submissions must be made by Monday, 3rd March at >9:00am EST. > >Drafts which are submitted late and do not make the cutoff date will not be >discussed at the meeting. > >-- >Colin Perkins >http://csperkins.org/ >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 11:08:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17701 for ; Mon, 24 Feb 2003 11:08:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OGGeY03481 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 11:16:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGGBp03441; Mon, 24 Feb 2003 11:16:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGFtp03413 for ; Mon, 24 Feb 2003 11:15:55 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17676 for ; Mon, 24 Feb 2003 11:06:48 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030224161016.KYDV9465.mailhost.chi1.ameritech.net@repligate>; Mon, 24 Feb 2003 10:10:16 -0600 Message-ID: <073e01c2dc1f$3910bb90$8500a8c0@repligate> From: "Jim Fleming" To: , "Colin Perkins" References: <200302241601.h1OG10w11925@chiron.nge.isi.edu> Subject: Re: [AVT] Meeting in San Francisco Date: Mon, 24 Feb 2003 10:10:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Working code appears to be more useful than meetings of the I* society... http://lists.digium.com/pipermail/asterisk-users/2003-February/007532.html Jim Fleming http://IPv8.vrx.net ----- Original Message ----- From: "Colin Perkins" To: Sent: Monday, February 24, 2003 10:01 AM Subject: Re: [AVT] Meeting in San Francisco > Folks, > > The submission deadline for -00 drafts has now passed. Other drafts are due > one week from today. If you have submitted a draft, and need agenda time to > discuss it, you should contact the working group chairs. > > We currently have agenda requests for the following: > > RTP Extended Reports (RTP XR) (Friedman/Clark) > Framing RTP over Connection-Oriented Transport (Lazzaro) > The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) > RTP Payload Format for iLBC Speech (Duric) > RTP payload format for a 64 kbit/s voice band data call (Kreuter) > RTP Payload Format for the Speex Codec (Herlien) > > Colin > > > > --> Colin Perkins writes: > >The AVT working group is scheduled for two slots at the 56th IETF meeting > >in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am > >on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These > >dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. > > > >Those wanting agenda time at the meeting should contact the working group > >chairs by 3rd March. Submitting a draft does not automatically provide > >agenda time. > > > >You are reminded that the cut-off date for -00 Internet Draft submissions > >is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior > >approval from the chairs, -00 submissions should have filenames with the > >format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts > >received after 24th February will not be accepted. > > > >All other Internet-Draft submissions must be made by Monday, 3rd March at > >9:00am EST. > > > >Drafts which are submitted late and do not make the cutoff date will not be > >discussed at the meeting. > > > >-- > >Colin Perkins > >http://csperkins.org/ > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 11:17:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17973 for ; Mon, 24 Feb 2003 11:17:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OGQHD03884 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 11:26:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGP8p03843; Mon, 24 Feb 2003 11:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGO3p03795 for ; Mon, 24 Feb 2003 11:24:03 -0500 Received: from dlana.elec.gla.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17927 for ; Mon, 24 Feb 2003 11:14:55 -0500 (EST) Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 18nLJZ-0003lq-00 for avt@ietf.org; Mon, 24 Feb 2003 16:18:49 +0000 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Mon, 24 Feb 2003 16:18:49 +0000 Message-ID: <1046103529.3e5a45e91c86d@dlana.elec.gla.ac.uk> Date: Mon, 24 Feb 2003 16:18:49 +0000 From: philkerr@elec.gla.ac.uk To: AVT WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Subject: [AVT] Updated Vorbis RTP draft 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, An updated Vorbis RTP draft is now available: http://www.ietf.org/internet-drafts/draft-kerr-avt-vorbis-rtp-01.txt Comments and feedback welcomed. Best regards Phil ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 11:57:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18989 for ; Mon, 24 Feb 2003 11:57:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OH6Rh06514 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 12:06:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OH5mp06473; Mon, 24 Feb 2003 12:05:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OH0Vp05843 for ; Mon, 24 Feb 2003 12:00:31 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18849 for ; Mon, 24 Feb 2003 11:51:24 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h1OGe8b20949; Mon, 24 Feb 2003 08:40:08 -0800 Date: Mon, 24 Feb 2003 08:55:17 -0800 (PST) From: Greg Herlein To: Jim Fleming cc: avt@ietf.org Subject: Re: [AVT] Meeting in San Francisco In-Reply-To: <073e01c2dc1f$3910bb90$8500a8c0@repligate> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Working code appears to be more useful than meetings of the I* society... > http://lists.digium.com/pipermail/asterisk-users/2003-February/007532.html Well, I might as well introduce myself on this list by disagreeing. :) Your link discusses Asterisk's non-standard implementation of the use of Speex in RTP. It may be working code for asterisk, but it can't talk to anything else. In fact, it may work for Asterisk, but since it does not do dyunamic payload types, it can't talk to much of anything else. Currently, Speex is trying to finalize a draft profile for use in RTP. Currently, there is interoperability between gnomemeeting and ohphone, for example, but only because both use the OpenH323 implementation of speex. Linphone can talk to other linphone apps, but I don't know of any other SIP-based apps that have implemented libspeex. We do have a draft that we just submitted that should make interoperability possible. Getting to where we are has been a lot of hours spent emailing between the primary authors of the above apps to get everyone to agree. I'd rather not repeat that when the next VoIP app comes along and wants to play. I'd rather say "go read the RFC." Now, if like Asterisk, they chose to not even follow the basic rules, that't their issue. The objective of these meetings is to get specs to a point where there is hope for interoperable implementations. Working code is easy - any fool programmer can do that. Getting that code to interoperate with other implementations is much harder. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 12:02:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19124 for ; Mon, 24 Feb 2003 12:02:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OHAtL07429 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 12:10:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHARp07413; Mon, 24 Feb 2003 12:10:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OH9kp07362 for ; Mon, 24 Feb 2003 12:09:46 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19082 for ; Mon, 24 Feb 2003 12:00:40 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030224170317.MDKB9465.mailhost.chi1.ameritech.net@repligate>; Mon, 24 Feb 2003 11:03:17 -0600 Message-ID: <079e01c2dc26$a1d1e2b0$8500a8c0@repligate> From: "Jim Fleming" To: "Greg Herlein" Cc: References: Subject: Re: [AVT] Meeting in San Francisco Date: Mon, 24 Feb 2003 11:03:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Greg Herlein" > > Working code appears to be more useful than meetings of the I* society... > > http://lists.digium.com/pipermail/asterisk-users/2003-February/007532.html > > Getting to where we are has been a lot of hours spent emailing > between the primary authors of the above apps to get everyone to > agree. I'd rather not repeat that when the next VoIP app comes > along and wants to play. I'd rather say "go read the RFC." > Was NAT developed that way ? https://www1.ietf.org/mail-archive/working-groups/ipr-wg/current/msg00613.html From: Brian E Carpenter This is exactly why we evolved the current IETF policy, and why it works (and has not stopped the open source community from flourishing in a world that runs on IETF protocols). ======== A few facts.... 1. The 160-bit Internet Protocol header, is basically a Uni* O/S data structure. 2. The Uni* O/S existed long before the IETF, the ISOC and the I* society. (small s...aka the Big Lie Society) 3. Open Source has been the basis for Uni* O/S development since the 1970's. 4. IBM was never an advocate of that movement or a major contributor. 5. As for protocols, some of the major ones that the average netizen views as "the Net", were not invented, developed, etc. by the IETF, which is described as an activity of the ISOC. ==== Quotes to consider ===== http://www.spectrum.ieee.org/select/1098/int.html NATs are a no-no HEATH: I was going to say that IEEE Spectrum should make it very clear that this group's consensus would appear to be: let's discourage NATs--I mean the manufacture of them at all--because there is a real need for IPv6. HUITEMA: It's more than that. There is a real need for security and you can't have security with NATs. CERF: NAT is a guaranteed spoofing box in effect. ==== http://IPv8.no-ip.com http://www.go-mono.com/ http://www.knoppix.com http://www.netfilter.org http://www.digium.com http://www.asterisk.org http://www.openss7.org http://www.zapatatelephony.org http://www.new.net http://IPv8.vrx.net Jim Fleming Inter.C@T.Inter.NAT Consultant http://www.Unir.NET http://www.Unir.com http://www.Uni%ae.com http://www.Uni®.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 12:41:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20131 for ; Mon, 24 Feb 2003 12:41:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OHnls09812 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 12:49:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHmBp09728; Mon, 24 Feb 2003 12:48:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHlrp09696 for ; Mon, 24 Feb 2003 12:47:53 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20002 for ; Mon, 24 Feb 2003 12:38:45 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1OHgcSS004367; Mon, 24 Feb 2003 09:42:38 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-214.cisco.com [64.100.135.214]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS13895; Mon, 24 Feb 2003 09:42:37 -0800 (PST) Message-Id: <4.3.2.7.2.20030224123730.0168aee8@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:42:36 -0500 To: Colin Perkins , avt@ietf.org From: "Michael A. Ramalho" Subject: Re: [AVT] Meeting in San Francisco In-Reply-To: <200302241601.h1OG10w11925@chiron.nge.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 11:01 AM 2/24/2003 -0500, Colin Perkins wrote: >Folks, > >The submission deadline for -00 drafts has now passed. Other drafts are due >one week from today. If you have submitted a draft, and need agenda time to >discuss it, you should contact the working group chairs. > >We currently have agenda requests for the following: > > RTP Extended Reports (RTP XR) (Friedman/Clark) > Framing RTP over Connection-Oriented Transport (Lazzaro) > The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) > RTP Payload Format for iLBC Speech (Duric) > RTP payload format for a 64 kbit/s voice band data call (Kreuter) > RTP Payload Format for the Speex Codec (Herlien) > >Colin Colin/Steve, I plan on revving the following drafts to -01: draft-ramalho-rgl-desc-00.txt and draft-ramalho-rgl-rtpformat-00.txt The second (RGL payload format) is a major re-write/proposal (based primarily on Steve's feedback). The first (RGL description) has trivial changes from the "00" version that were made to more easily accommodate the new proposed RTP payload format(s). I plan to meet the "non-00" deadline for both. Michael Ramalho >--> Colin Perkins writes: > >The AVT working group is scheduled for two slots at the 56th IETF meeting > >in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am > >on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These > >dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. > > > >Those wanting agenda time at the meeting should contact the working group > >chairs by 3rd March. Submitting a draft does not automatically provide > >agenda time. > > > >You are reminded that the cut-off date for -00 Internet Draft submissions > >is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior > >approval from the chairs, -00 submissions should have filenames with the > >format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts > >received after 24th February will not be accepted. > > > >All other Internet-Draft submissions must be made by Monday, 3rd March at > >9:00am EST. > > > >Drafts which are submitted late and do not make the cutoff date will not be > >discussed at the meeting. > > > >-- > >Colin Perkins > >http://csperkins.org/ > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 13:42:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22132 for ; Mon, 24 Feb 2003 13:42:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OIpAp14087 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 13:51:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIoQp14066; Mon, 24 Feb 2003 13:50:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OInOp14030 for ; Mon, 24 Feb 2003 13:49:24 -0500 Received: from osiris.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22082 for ; Mon, 24 Feb 2003 13:40:15 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1OIi60S026695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 24 Feb 2003 19:44:06 +0100 X-pt: osiris.lip6.fr Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1OIi6304481; Mon, 24 Feb 2003 19:44:06 +0100 (MET) From: "Timur Friedman" To: "'Magnus Westerlund'" Cc: Subject: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Mon, 24 Feb 2003 19:44:04 +0100 Message-ID: <003501c2dc34$b4726080$a648e384@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3E59D2C6.80708@era.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: osiris.lip6.fr 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Magnus, > I think that signaling is fundamental enough to this draft that it > warrants to put it in directly. I would also not like to delay this > draft. I would like to see it submitted to the IESG before May. I think > that is still possible, especially if you would add this functionality > in a update that you can submit before mondays cut-off date. You can > take my text and rework it into suitable text for your draft. Then we > can have a healthy discussion on this in San Francisco. Then after the > meeting update the draft if any comments has been given. The have a WG > last call in early April. There is no need to either ask or have WG last > calls in relations to meetings. It might even be better as people will > have more time to read the document. There is no question in my mind that it would be a plus to specify SDP signalling for RTP XR reports. Of course until the precise form is settled, there is nothing to stop applications from experimenting with different signalling approaches. My hesitation is whether the signalling text that you suggest is settled enough to paste into the document between now and the Monday deadline. We should really solicit the opinions of others on the list. Have a number of people experienced in the issues surrounding signalling had a chance to go over the text and say that it is solid in its present form? Regards, Timur _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Feb 24 14:28:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23492 for ; Mon, 24 Feb 2003 14:28:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OJauM17123 for avt-archive@odin.ietf.org; Mon, 24 Feb 2003 14:36:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJaGp17067; Mon, 24 Feb 2003 14:36:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJZ7p17014 for ; Mon, 24 Feb 2003 14:35:07 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23448 for ; Mon, 24 Feb 2003 14:25:57 -0500 (EST) Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.11) id A2DF1550378; Mon, 24 Feb 2003 14:30:39 -0500 Reply-To: From: "Alan Clark" To: "'Timur Friedman'" , "'Magnus Westerlund'" Cc: Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Mon, 24 Feb 2003 14:27:48 -0500 Message-ID: <007f01c2dc3a$d1131da0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003501c2dc34$b4726080$a648e384@lip6.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Magnus' suggestion of providing a means for signalling to indicate that RTP XR reports are required, the type and frequency of report, is a useful one. I would suggest however that: (i) This would be useful for a variety of different feedback mechanisms - including RTP XR, RTCP and potentially others (ii) There may be other protocols than SDP that would be more appropriate for negotiating feedback in different applications. These would both seem to suggest that it may be preferable to develop such functionality but to keep it independent from RTP XR. We should also review the RTP XR draft to ensure that it is amenable to being negotiated. The new draft could cover the following:- - general framework for real time feedback - reference to available report types - RTCP - RTP XR - video? - ..... - protocol independent model for report negotiation - specific protocol implementations - SDP - SIP? - H.xxx? - As Magnus comments, there are applications such as streaming which have particular requirements. We need to consider other applications such as conferencing, multicast, broadcast.... to see what would make sense (e.g. in a broadcast application would you still want to negotiate feedback with a sample population of receivers?). Trying to cover the range of potential applications within the RTP XR draft could make it overly complicated. Regards Alan Clark Telchemy -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Monday, February 24, 2003 1:44 PM To: 'Magnus Westerlund' Cc: avt@ietf.org Subject: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Hello Magnus, > I think that signaling is fundamental enough to this draft that it > warrants to put it in directly. I would also not like to delay this > draft. I would like to see it submitted to the IESG before May. I think > that is still possible, especially if you would add this functionality > in a update that you can submit before mondays cut-off date. You can > take my text and rework it into suitable text for your draft. Then we > can have a healthy discussion on this in San Francisco. Then after the > meeting update the draft if any comments has been given. The have a WG > last call in early April. There is no need to either ask or have WG last > calls in relations to meetings. It might even be better as people will > have more time to read the document. There is no question in my mind that it would be a plus to specify SDP signalling for RTP XR reports. Of course until the precise form is settled, there is nothing to stop applications from experimenting with different signalling approaches. My hesitation is whether the signalling text that you suggest is settled enough to paste into the document between now and the Monday deadline. We should really solicit the opinions of others on the list. Have a number of people experienced in the issues surrounding signalling had a chance to go over the text and say that it is solid in its present form? Regards, Timur _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 25 06:46:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24946 for ; Tue, 25 Feb 2003 06:46:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBt8p21228 for avt-archive@odin.ietf.org; Tue, 25 Feb 2003 06:55:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBsep21180; Tue, 25 Feb 2003 06:54:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBqXp21111 for ; Tue, 25 Feb 2003 06:52:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24171; Tue, 25 Feb 2003 06:43:04 -0500 (EST) Message-Id: <200302251143.GAA24171@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:43:04 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3119bis-01.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rfc3119bis-01.txt Pages : 0 Date : 2003-2-24 This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as 'MP3'). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3119bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc3119bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc3119bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-24141902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc3119bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc3119bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24141902.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 25 13:09:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08943 for ; Tue, 25 Feb 2003 13:09:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIIBO18756 for avt-archive@odin.ietf.org; Tue, 25 Feb 2003 13:18:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIHDp18696; Tue, 25 Feb 2003 13:17:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIFkp18636 for ; Tue, 25 Feb 2003 13:15:46 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08861 for ; Tue, 25 Feb 2003 13:06:08 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PIA1Ye006082; Tue, 25 Feb 2003 19:10:01 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 19:09:56 +0100 Message-ID: <034BEFD03799D411A59F00508BDF754602BF4174@esealnt448.al.sw.ericsson.se> From: "Magnus Westerlund (EAB)" To: "'Alan Clark '" , "''Timur Friedman' '" Cc: "'avt@ietf.org '" Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Tue, 25 Feb 2003 19:05:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PIFlp18637 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Alan, My comment is that the XR does not need to consider all applications, only what is necessary in relation to the XR format. From my perspective it seems that my proposed attrbiutes for the XR report is covering this. To my knowledge the necessary signalling is in place for all other types of RTCP reporting. The AVPF defines SDP attribute that allows control of the usage of the formats within that proposal. So I don´t think arguing that it is a general problem would lessen the need for SDP attributes in regards to XR formats. By supporting SDP you support the basic signalling that are currenlty in use by the most common real-time media applications using RTP/RTCP. SIP uses SDP, RTSP uses SDP. So my view is still that providing the basic SDP functionality outlined in my initial mail we have all functionality currently needed. Best Regards Magnus Westerlund -----Original Message----- From: Alan Clark To: 'Timur Friedman'; Magnus Westerlund (EAB) Cc: avt@ietf.org Sent: 24.02.2003 20:27 Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Magnus' suggestion of providing a means for signalling to indicate that RTP XR reports are required, the type and frequency of report, is a useful one. I would suggest however that: (i) This would be useful for a variety of different feedback mechanisms - including RTP XR, RTCP and potentially others (ii) There may be other protocols than SDP that would be more appropriate for negotiating feedback in different applications. These would both seem to suggest that it may be preferable to develop such functionality but to keep it independent from RTP XR. We should also review the RTP XR draft to ensure that it is amenable to being negotiated. The new draft could cover the following:- - general framework for real time feedback - reference to available report types - RTCP - RTP XR - video? - ..... - protocol independent model for report negotiation - specific protocol implementations - SDP - SIP? - H.xxx? - As Magnus comments, there are applications such as streaming which have particular requirements. We need to consider other applications such as conferencing, multicast, broadcast.... to see what would make sense (e.g. in a broadcast application would you still want to negotiate feedback with a sample population of receivers?). Trying to cover the range of potential applications within the RTP XR draft could make it overly complicated. Regards Alan Clark Telchemy -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Monday, February 24, 2003 1:44 PM To: 'Magnus Westerlund' Cc: avt@ietf.org Subject: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Hello Magnus, > I think that signaling is fundamental enough to this draft that it > warrants to put it in directly. I would also not like to delay this > draft. I would like to see it submitted to the IESG before May. I think > that is still possible, especially if you would add this functionality > in a update that you can submit before mondays cut-off date. You can > take my text and rework it into suitable text for your draft. Then we > can have a healthy discussion on this in San Francisco. Then after the > meeting update the draft if any comments has been given. The have a WG > last call in early April. There is no need to either ask or have WG last > calls in relations to meetings. It might even be better as people will > have more time to read the document. There is no question in my mind that it would be a plus to specify SDP signalling for RTP XR reports. Of course until the precise form is settled, there is nothing to stop applications from experimenting with different signalling approaches. My hesitation is whether the signalling text that you suggest is settled enough to paste into the document between now and the Monday deadline. We should really solicit the opinions of others on the list. Have a number of people experienced in the issues surrounding signalling had a chance to go over the text and say that it is solid in its present form? Regards, Timur _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 25 13:30:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09776 for ; Tue, 25 Feb 2003 13:30:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIdSn20577 for avt-archive@odin.ietf.org; Tue, 25 Feb 2003 13:39:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PId5p20556; Tue, 25 Feb 2003 13:39:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIcVp20518 for ; Tue, 25 Feb 2003 13:38:31 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09705 for ; Tue, 25 Feb 2003 13:28:54 -0500 (EST) Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.11) id A6D32070148; Tue, 25 Feb 2003 13:32:51 -0500 Reply-To: From: "Alan Clark" To: "'Magnus Westerlund \(EAB\)'" , "''Timur Friedman' '" Cc: Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Tue, 25 Feb 2003 13:30:41 -0500 Message-ID: <002301c2dcfc$0132a200$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <034BEFD03799D411A59F00508BDF754602BF4174@esealnt448.al.sw.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Magnus >To my knowledge the necessary signalling is in place for all other types of RTCP reporting. The AVPF defines SDP attribute that allows control of the usage of the formats within that proposal. So I don´t think arguing that it is a general problem would lessen the need for SDP attributes in regards to XR formats. [Alan] I don't recall seeing any explicit means of turning RTCP reports on and off and was only able to locate an expired draft on using SDP to negotiate RTCP bandwidth. It would be helpful if you could provide some references to existing signalling protocols. >By supporting SDP you support the basic signalling that are currenlty in use by the most common real-time media applications using RTP/RTCP. SIP uses SDP, RTSP uses SDP. [Alan] How about H.323? Regards Alan Clark Telchemy _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Feb 25 21:55:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25887 for ; Tue, 25 Feb 2003 21:55:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q34x519584 for avt-archive@odin.ietf.org; Tue, 25 Feb 2003 22:04:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q30op19446; Tue, 25 Feb 2003 22:00:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q2B8p17363 for ; Tue, 25 Feb 2003 21:11:08 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25154; Tue, 25 Feb 2003 21:01:09 -0500 (EST) From: jan.vandermeer@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 3EC7290228; Wed, 26 Feb 2003 03:05:00 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id DAA14302; Wed, 26 Feb 2003 03:04:59 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id DAA24482; Wed, 26 Feb 2003 03:04:58 +0100 (MET) To: avt@ietf.org Cc: avt-admin@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Feb 2003 03:02:45 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 26/02/2003 03:03:11 Content-Type: multipart/mixed; boundary="=_mixed 000B64EDC1256CD9_=" Subject: [AVT] New draft-ietf-avt-mpeg4-simple-07 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=_mixed 000B64EDC1256CD9_= Content-Type: multipart/alternative; boundary="=_alternative 000B64EDC1256CD9_=" --=_alternative 000B64EDC1256CD9_= Content-Type: text/plain; charset="us-ascii" Dear all, This is to let you know that I just submitted draft-ietf-avt-mpeg4-simple-07 for upload to the IETF. For your convenience I attached the draft to this email. Compared to -06 there are several editorial improvements. In addition, all comments provided by Colin are incorporated with one small difference. Colin suggested the following text on interleaving in 3.2.3.2 (page 17): If the "constantDuration" parameter is not present, then Access Units are assumed to have a variable duration. In this case, the transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of the first AU in the RTP packet. ... I changed this to the following text, in order to accomodate "early implementations" that do not use the constantDuration parameter when transmitting constant duration AUs. If the "constantDuration" parameter is not present, then Access Units are assumed to have a variable duration, unless the AU-Index is present and coded with the value 0 in each RTP packet. When transmitting Access Units of variable duration, then the "constantDuration" parameter MUST NOT be present, and the transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of each AU in the RTP packet. ... From my perspective the document is ready now. All known comments are incorporated (Colin and Steve thanks for your help !) and therefore I think we are done, unless any further issues are identified. Best regards / Groeten, Jan ----------------------------------------------------------- Jan van der Meer Philips - MP4Net Prof Holstlaan 4 Building WDB-1 P.O. Box 80021 5600 JZ Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 --=_alternative 000B64EDC1256CD9_= Content-Type: text/html; charset="us-ascii"
Dear all,

This is to let you know that I just submitted draft-ietf-avt-mpeg4-simple-07 for upload to the IETF. For your convenience I attached the draft to this email.

Compared to -06 there are several editorial improvements. In addition, all comments provided by Colin are incorporated with one small difference. Colin suggested the following text on interleaving in 3.2.3.2 (page 17):

    If the "constantDuration" parameter is not present, then Access Units
   are assumed to have a variable duration. In this case, the transmitter
   MUST use the AU-Index to encode the index information required for
   re-ordering, and the receiver MUST use that value to determine the
   index of the first AU in the RTP packet. ...

I changed this to the following text, in order to accomodate "early implementations" that do not use the constantDuration parameter when transmitting constant duration AUs.

   If the "constantDuration" parameter is not present, then Access
   Units are assumed to have a variable duration, unless the AU-Index
   is present and coded with the value 0 in each RTP packet. When
   transmitting Access Units of variable duration, then the
   "constantDuration" parameter MUST NOT be present, and the
   transmitter MUST use the AU-Index to encode the index information
   required for re-ordering, and the receiver MUST use that value to
   determine the index of each AU in the RTP packet. ...

From my perspective the document is ready now. All known comments are incorporated (Colin and Steve thanks for your help !) and therefore I think we are done, unless any further issues are identified.

Best regards / Groeten,

Jan



-----------------------------------------------------------
Jan van der Meer
Philips - MP4Net
Prof Holstlaan 4
Building WDB-1
P.O. Box 80021
5600 JZ Eindhoven
The Netherlands
Phone +31 402 735 774
Fax +31 402 735 545
 --=_alternative 000B64EDC1256CD9_=-- --=_mixed 000B64EDC1256CD9_= Content-Type: text/plain; name="draft-ietf-avt-mpeg4-simple-07.txt" Content-Disposition: attachment; filename="draft-ietf-avt-mpeg4-simple-07.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force J. van der Meer Internet Draft Philips Electronics D. Mackie Apple Computer V. Swaminathan Sun Microsystems Inc. D. Singer Apple Computer P. Gentric Philips Electronics=20 February 2003 Expires August 2003 Document: draft-ietf-avt-mpeg4-simple-07.txt RTP Payload Format for Transport of MPEG-4 Elementary Streams Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. =20 This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are=20 solicited and should be addressed to the working group's mailing=20 list at avt@ietf.org and/or the authors. =20 << Note for the RFC editor: xxxx should be replaced with the RFC=20 number that will be assigned. >>=20 =20 Abstract The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in=20 ISO that produced the MPEG-4 standard. MPEG defines tools to=20 compress content such as audio-visual information into elementary=20 streams. This specification defines a simple, but generic RTP=20 payload format for transport of any non-multiplexed MPEG-4=20 elementary stream.=20 van der Meer et al. Expires August 2003 [Page 1] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . 6 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . 6 2.3. Concatenation of Access Units . . . . . . . . . . . . . . 6 2.4. Fragmentation of Access Units . . . . . . . . . . . . . . 7 2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Time stamp information . . . . . . . . . . . . . . . . . . 8 2.7. State indication of MPEG-4 system streams . . . . . . . . 8 2.8. Random Access Indication . . . . . . . . . . . . . . . . . 8 2.9. Carriage of auxiliary information . . . . . . . . . . . . 9 2.10. MIME format parameters and configuring conditional field . 9 2.11. Global structure of payload format . . . . . . . . . . . . 9 2.12. Modes to transport MPEG-4 streams . . . . . . . . . . . . 10 2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . . 10 3. Payload format . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Usage of RTP header fields and RTCP . . . . . . . . . . . 11 3.2. RTP payload structure . . . . . . . . . . . . . . . . . . 12 3.2.1. The AU Header Section . . . . . . . . . . . . . . . . . 12 3.2.1.1. The AU-header . . . . . . . . . . . . . . . . . . . . 12 3.2.2. The Auxiliary Section . . . . . . . . . . . . . . . . . 15 3.2.3. The Access Unit Data Section . . . . . . . . . . . . . . 15 3.2.3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 16 3.2.3.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 16 3.2.3.3. Constraints for interleaving . . . . . . . . . . . . . 18 3.2.3.4. Crucial and non-crucial AUs with MPEG-4 System data . 20 3.3. Usage of this specification . . . . . . . . . . . . . . . 22 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2. The generic mode . . . . . . . . . . . . . . . . . . . . 22 3.3.3. Constant bit rate CELP . . . . . . . . . . . . . . . . . 23 3.3.4. Variable bit rate CELP . . . . . . . . . . . . . . . . . 23 3.3.5. Low bit rate AAC . . . . . . . . . . . . . . . . . . . . 24 3.3.6. High bit rate AAC . . . . . . . . . . . . . . . . . . . 25 3.3.7. Additional modes . . . . . . . . . . . . . . . . . . . . 26 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 27 4.1. MIME type registration . . . . . . . . . . . . . . . . . . 27 4.2. Registration of mode definitions with IANA . . . . . . . . 32 4.3. Concatenation of parameters . . . . . . . . . . . . . . . 32 4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1. The a=3Dfmtp keyword . . . . . . . . . . . . . . . . . . . 33 5. Security considerations . . . . . . . . . . . . . . . . . . 33 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 34 7.2 Informative references . . . . . . . . . . . . . . . . . . . 34 8. Author addresses . . . . . . . . . . . . . . . . . . . . . . 35 van der Meer et al. Expires August 2003 [Page 2] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 APPENDIX: Usage of this payload format . . . . . . . . . . . 37 A. Examples of delay analysis with interleave . . . . . . . 37 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 37 A.2 De-interleaving and error concealment . . . . . . . . . 37 A.3 Simple Group interleave . . . . . . . . . . . . . . . . 37 A.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 37 A.3.2 Determining the de-interleave buffer size . . . . . . 38 A.3.3 Determining the maximum displacement . . . . . . . . . 38 A.4 More subtle group interleave . . . . . . . . . . . . . . 38 A.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 38 A.4.2 Determining the de-interleave buffer size . . . . . . 39 A.4.3 Determining the maximum displacement . . . . . . . . . 39 A.5 Continuous interleave . . . . . . . . . . . . . . . . . 40 A.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . 40 A.5.2 Determining the de-interleave buffer size . . . . . . 40 A.5.3 Determining the maximum displacement . . . . . . . . . 41 van der Meer et al. Expires August 2003 [Page 3] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 1. Introduction The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29=20 that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4=20 standards [1]. The MPEG-4 standard specifies compression of=20 audio-visual data into for example an audio or video elementary=20 stream. In the MPEG-4 standard, these streams take the form of=20 audio-visual objects that may be arranged into an audio-visual scene by means of a scene description. Each MPEG-4 elementary stream=20 consists of a sequence of Access Units; examples of an Access Unit=20 (AU) are an audio frame and a video picture.=20 This specification defines a general and configurable payload=20 structure to transport MPEG-4 elementary streams, in particular=20 MPEG-4 audio (including speech) streams, MPEG-4 video streams and also MPEG-4 systems streams, such as BIFS (BInary Format for=20 Scenes), OCI (Object Content Information), OD (Object Descriptor)=20 and IPMP (Intellectual Property Management and Protection) streams. The RTP payload defined in this document is simple to implement and reasonably efficient. It allows for optional interleaving of Access Units (such as audio frames) to increase error resiliency in packet loss. Some types of MPEG-4 elementary streams include "crucial" information whose loss cannot be tolerated, but RTP does not provide reliable transmission so receipt of that crucial information is not assured. Section 3.2.3.4 specifies how stream state is conveyed so that the receiver can detect the loss of crucial information and cease decoding until the next random access point is received. Applications transmitting streams that include crucial information, such as OD commands, BIFS commands, or programmatic content such as MPEG-J (Java) and ECMAScript, should include random access points sufficiently often, depending upon the probability of loss, to reduce stream corruption to an acceptable level. An example is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1. Such applications may also employ additional protocols or services to reduce the probability of loss. At the RTP layer, these measures include payload formats and profiles for retransmission or forward error correction (such as in RFC 2733 [10]), which must be employed with due consideration to congestion control. Another solution that may be appropriate for some applications is to carry RTP over TCP=20 (such as in RFC 2326 [8], section 10.12). At the network layer,=20 resource allocation or preferential service may be available to=20 reduce the probability of loss. For a general description of methods to repair streaming media see RFC 2354 [9]. van der Meer et al. Expires August 2003 [Page 4] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Though the RTP payload format defined in this document is capable=20 of transporting any MPEG-4 stream, other, more specific, formats=20 may exist, such as RFC 3016 [12] for transport of MPEG-4 video=20 (ISO/IEC 14496 [1] part 2). Configuration of the payload is provided to accommodate transport=20 of any MPEG-4 stream at any possible bit rate. However, for a=20 specific MPEG-4 elementary stream typically only very few=20 configurations are needed. So as to allow for the design of=20 simplified, but dedicated receivers, this specification requires=20 that specific modes are defined for transport of MPEG-4 streams.=20 This document defines modes for MPEG-4 CELP and AAC streams, as=20 well as a generic mode that can be used to transport any MPEG-4=20 stream. In the future new RFCs are expected to specify additional=20 modes for transport of MPEG-4 streams.=20 The RTP payload format defined in this document specifies carriage=20 of system-related information that is often equivalent to the=20 information that may be contained in the MPEG-4 Sync Layer (SL) as defined in MPEG-4 Systems [1]. This document does not prescribe how to transcode or map information from the SL to fields defined in=20 the RTP payload format. Such processing, if any, is left to the=20 discretion of the application. However, to anticipate the need for=20 transport of any additional system-related information in future,=20 an auxiliary field can be configured that may carry any such data.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. van der Meer et al. Expires August 2003 [Page 5] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 2. Carriage of MPEG-4 elementary streams over RTP=20 2.1 Introduction With this payload format a single MPEG-4 elementary stream can be=20 transported. Information on the type of MPEG-4 stream carried in=20 the payload is conveyed by MIME format parameters, for example in=20 an SDP [5] message or by other means (see section 4). These MIME=20 format parameters specify the configuration of the payload. To=20 allow for simplified and dedicated receivers, a MIME format=20 parameter is available to signal a specific mode of using this=20 payload. A mode definition MAY include the type of MPEG-4=20 elementary stream as well as the applied configuration, so as to=20 avoid the need for receivers to parse all MIME format parameters.=20 The applied mode MUST be signaled. 2.2 MPEG Access Units For carriage of compressed audio-visual data MPEG defines Access=20 Units. An MPEG Access Unit (AU) is the smallest data entity to=20 which timing information is attributed. In case of audio an Access=20 Unit may represent an audio frame and in case of video a picture.=20 MPEG Access Units are by definition octet-aligned. If for example=20 an audio frame is not octet-aligned, up to 7 zero-padding bits MUST be inserted at the end of the frame to achieve the octet-aligned=20 Access Units, as required by the MPEG-4 specification. MPEG-4=20 decoders MUST be able to decode AUs in which such padding is=20 applied. Consistent with the MPEG-4 specification, this document requires=20 that each MPEG-4 part 2 video Access Unit includes all the coded=20 data of a picture, any video stream headers that may precede the=20 coded picture data, and any video stream stuffing that may follow=20 it, up to, but not including the startcode indicating the start of=20 a new video stream or the next Access Unit. 2.3 Concatenation of Access Units Frequently it is possible to carry multiple Access Units in one RTP packet. This is particularly useful for audio; for example, when=20 AAC is used for encoding of a stereo signal at 64 kbits/sec, AAC=20 frames contain on average approximately 200 octets. On a LAN with a 1500 octet MTU this would allow on average 7 complete AAC frames to=20 be carried per RTP packet. Access Units may have a fixed size in octets, but a variable size=20 is also possible. To facilitate parsing in case of multiple=20 concatenated AUs in one RTP packet, the size of each AU is made=20 known to the receiver. When concatenating in case of a constant AU=20 size, this size is communicated "out of band" through a MIME format=20 parameter. When concatenating in case of variable size AUs, the RTP payload carries "in band" an AU size field for each contained AU.=20 van der Meer et al. Expires August 2003 [Page 6] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 In combination with the RTP payload length the size information=20 allows the RTP payload to be split by the receiver back into the=20 individual AUs. To simplify the implementation of RTP receivers, it is required=20 that when multiple AUs are carried in an RTP packet, each AU MUST=20 be complete, i.e. the number of AUs in an RTP packet MUST be=20 integral. In addition, an AU MUST NOT be repeated in other RTP=20 packets; hence repetition of an AU is only possible by using a=20 duplicate RTP packet. 2.4 Fragmentation of Access Units MPEG allows for very large Access Units. Since most IP networks=20 have significantly smaller MTU sizes, this payload format allows=20 for the fragmentation of an Access Unit over multiple RTP packets=20 so as to avoid IP layer fragmentation. To simplify the=20 implementation of RTP receivers, an RTP packet SHALL either carry=20 one or more complete Access Units or a single fragment of one=20 Access Unit (i.e. packets MUST NOT contain fragments of multiple Access Units).=20 2.5 Interleaving When an RTP packet carries a contiguous sequence of Access Units,=20 the loss of such a packet can result in a "decoding gap" for the=20 user. One method to alleviate this problem is to allow for the=20 Access Units to be interleaved in the RTP packets. For a modest=20 cost in latency and implementation complexity, significant error=20 resiliency to packet loss can be achieved.=20 To support optional interleaving of Access Units, this payload=20 format allows for index information to be sent for each Access Unit. After informing receivers about buffer resources to allocate for=20 de-interleaving, the RTP sender is free to choose the interleaving=20 pattern without propagating this information a priori to the=20 receiver(s). Indeed the sender could dynamically adjust the=20 interleaving pattern based on the Access Unit size, error rates,=20 etc. The RTP receiver does not need to know the interleaving=20 pattern used, it only needs to extract the index information of the Access Unit and insert the Access Unit into the appropriate=20 sequence in the decoding or rendering queue. An example of=20 interleaving is given below.=20 For example, if we assume that an RTP packet contains 3 AUs, and=20 that the AUs are numbered 0, 1, 2, 3, 4, and so forth, and if an=20 interleaving group length of 9 is chosen, then RTP packet(i)=20 contains the following AU(n): RTP packet(0): AU(0), AU(3), AU(6) RTP packet(1): AU(1), AU(4), AU(7) RTP packet(2): AU(2), AU(5), AU(8) RTP packet(3): AU(9), AU(12), AU(15) RTP packet(4): AU(10), AU(13), AU(16) Etc. van der Meer et al. Expires August 2003 [Page 7] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 2.6 Time stamp information The RTP time stamp MUST carry the sampling instant of the first AU (fragment) in the RTP packet. When multiple AUs are carried within=20 an RTP packet, the time stamps of subsequent AUs can be calculated=20 if the frame period of each AU is known. For audio and video this is possible if the frame rate is constant. However, in some cases=20 it is not possible to make such calculation. For example, for=20 variable frame rate video, or for MPEG-4 BIFS streams carrying=20 composition information. To support such cases, this payload format can be configured to carry a time stamp in the RTP payload for each contained Access Unit. A time stamp MAY be conveyed in the RTP=20 payload only for non-first AUs in the RTP packet, and SHALL NOT be=20 conveyed for the first AU (fragment), as the time stamp for the=20 first AU in the RTP packet is carried by the RTP time stamp.=20 MPEG-4 defines two types of time stamp: the composition time stamp=20 (CTS) and the decoding time stamp (DTS). The CTS represents the=20 sampling instant of an AU, and hence the CTS is equivalent to the=20 RTP time stamp. The DTS may be used in MPEG-4 video streams that=20 use bi-directional coding, i.e. when pictures are predicted in both forward and backward direction by using either a reference picture=20 in the past, or a reference picture in the future. The DTS cannot=20 be carried in the RTP header. In some cases the DTS can be derived=20 from the RTP time stamp using frame rate information; this requires deep parsing in the video stream, which may be considered=20 objectionable. But if the video frame rate is variable, the required information may not even be present in the video stream. For both=20 reasons, the capability has been defined to optionally carry the=20 DTS in the RTP payload for each contained Access Unit. To keep the coding of time stamps efficient, each time stamp=20 contained in the RTP payload is coded differentially, the CTS from the RTP time stamp, and the DTS from the CTS.=20 2.7 State indication of MPEG-4 system streams ISO/IEC 14496-1 defines states for MPEG-4 system streams. So as to=20 convey state information when transporting MPEG-4 system streams,=20 this payload format allows for the optional carriage in the RTP=20 payload of the stream state for each contained Access Unit. Stream=20 states are used to signal "crucial" AUs that carry information whose loss cannot be tolerated and are also useful when repeating AUs=20 according to the carousel mechanism defined in ISO/IEC 14496-1. 2.8 Random access indication Random access to the content of MPEG-4 elementary streams may be possible at some but not all Access Units. To signal Access Units=20 where random access is possible, a random access point flag can=20 optionally be carried in the RTP payload for each contained Access Unit. Carriage of random access points is particularly useful for=20 MPEG-4 system streams in combination with the stream state.=20 van der Meer et al. Expires August 2003 [Page 8] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 2.9 Carriage of auxiliary information. This payload format defines a specific field to carry auxiliary=20 data. The auxiliary data field is preceded by a field that specifies the length of the auxiliary data, so as to facilitate skipping of=20 the data without parsing it. The coding of the auxiliary data is not defined in this document; instead the format, meaning and signaling=20 of auxiliary information is expected to be specified in one or more future RFCs. Auxiliary information MUST NOT be transmitted until its format, meaning and signaling have been specified and its use has=20 been signaled. Receivers that have knowledge of the auxiliary data MAY decode the auxiliary data, but receivers without knowledge of such data MUST skip the auxiliary data field. 2.10 MIME format parameters and configuring conditional fields To support the features described in the previous sections several=20 fields are defined for carriage in the RTP payload. However, their=20 use strongly depends on the type of MPEG-4 elementary stream that=20 is carried. Sometimes a specific field is needed with a certain=20 length, while in other cases such field is not needed at all. To be efficient in either case, the fields to support these features are=20 configurable by means of MIME format parameters. In general, a MIME format parameter defines the presence and length of the associated=20 field. A length of zero indicates absence of the field. As a=20 consequence, parsing of the payload requires knowledge of MIME=20 format parameters. The MIME format parameters are conveyed to the=20 receiver via SDP [5] messages, as specified in section 4.4.1, or=20 through other means. 2.11 Global structure of payload format The RTP payload following the RTP header, contains three=20 octet-aligned data sections, of which the first two MAY be empty.=20 See figure 1. +---------+-----------+-----------+---------------+ | RTP | AU Header | Auxiliary | Access Unit | | Header | Section | Section | Data Section | +---------+-----------+-----------+---------------+ <----------RTP Packet Payload-----------> Figure 1: Data sections within an RTP packet The first data section is the AU (Access Unit) Header Section, that contains one or more AU-headers; however, each AU-header MAY be=20 empty, in which case the entire AU Header Section is empty. The=20 second section is the Auxiliary Section, containing auxiliary data; this section MAY also be configured empty. The third section is the=20 Access Unit Data Section, containing either a single fragment of=20 van der Meer et al. Expires August 2003 [Page 9] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 one Access Unit or one or more complete Access Units. The Access=20 Unit Data Section MUST NOT be empty. 2.12 Modes to transport MPEG-4 streams While it is possible to build fully configurable receivers capable=20 of receiving any MPEG-4 stream, this specification also allows for=20 the design of simplified, but dedicated receivers, that are capable for example of receiving only one type of MPEG-4 stream. This is achieved by requiring that specific modes be defined for using=20 this specification. Each mode may define constraints for transport of one or more type of MPEG-4 streams, for instance on the payload=20 configuration. The applied mode MUST be signaled. Signaling the mode is=20 particularly important for receivers that are only capable of=20 decoding one or more specific modes. Such receivers need to=20 determine whether the applied mode is supported, so as to avoid=20 problems with processing of payloads that are beyond the=20 capabilities of the receiver.=20 In this document several modes are defined for transport of MPEG-4=20 CELP and AAC streams, as well as a generic mode that can be used=20 for any MPEG-4 stream. In the future, new RFCs may specify other modes of using this specification. However, each mode MUST be in=20 full compliance with this specification (see section 3.3.7). 2.13 Alignment with RFC 3016 This payload can be configured to be nearly identical to the=20 payload format defined in RFC 3016 [12] for the MPEG-4 video=20 configurations recommended in RFC 3016. Hence, receivers that=20 comply with RFC 3016 can decode such RTP payload, providing that additional packets containing video decoder configuration (VO,=20 VOL, VOSH) are inserted in the stream, as required by RFC 3016. Conversely, receivers that comply with the specification in this=20 document SHOULD be able to decode payloads, names and parameters defined for MPEG-4 video in RFC 3016. In this respect it is=20 strongly RECOMMENDED to implement the ability to ignore "in band"=20 video decoder configuration packets in the RFC 3016 payload. Note the "out of band" availability of the video decoder configuration is optional in RFC 3016. To achieve maximum=20 interoperability with the RTP payload format defined in this=20 document, applications that use RFC 3016 to transport MPEG-4 video=20 (part 2) are recommended to make the video decoder configuration=20 available as a MIME parameter.=20 van der Meer et al. Expires August 2003 [Page 10] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 3. Payload Format 3.1 Usage of RTP Header Fields and RTCP=20 Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is=20 specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g. using SDP). Marker (M) bit: The M bit is set to 1 to indicate that the RTP=20 packet payload contains either the final fragment of a fragmented=20 Access Unit or one or more complete Access Units. Extension (X) bit: Defined by the RTP profile used. Sequence Number: The RTP sequence number SHOULD be generated by the sender in the usual manner with a constant random offset. Timestamp: Indicates the sampling instant of the first AU=20 contained in the RTP payload. This sampling instant is equivalent=20 to the CTS in the MPEG-4 time domain. When using SDP the clock rate of the RTP time stamp MUST be expressed using the "rtpmap"=20 attribute. If an MPEG-4 audio stream is transported, the rate SHOULD be set to the same value as the sampling rate of the audio stream.=20 If an MPEG-4 video stream is transported, it is RECOMMENDED to set=20 the rate to 90 kHz. In all cases, the sender SHALL make sure that RTP time stamps are identical only if the RTP time stamp refers to fragments of the same Access Unit. According to RFC 1889 [2] (section 5.1), RTP time stamps are=20 RECOMMENDED to start at a random value for security reasons. This=20 is not an issue for synchronization of multiple RTP streams. When, however, streams from multiple sources are to be synchronized (for=20 example one stream from local storage, another from an RTP streaming server), synchronization may become impossible if the receiver only knows the original time stamp relationships. Synchronization in such cases, may require to provide the correct relationship between time=20 stamps for obtaining synchronization by out of band means. The=20 format of such information as well as methods to convey such=20 information are beyond the scope of this specification. SSRC: set as described in RFC 1889 [2].=20 CC and CSRC fields are used as described in RFC 1889 [2]. RTCP SHOULD be used as defined in RFC 1889 [2]. Note that time stamps in RTCP Sender Reports may be used to synchronize multiple MPEG-4 elementary streams and also to synchronize MPEG-4 streams=20 with non-MPEG-4 streams, in case the delivery of these streams uses RTP. =20 van der Meer et al. Expires August 2003 [Page 11] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 3.2 RTP Payload Structure 3.2.1 The AU Header Section When present, the AU Header Section consists of the=20 AU-headers-length field, followed by a number of AU-headers. See=20 figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+ |AU-headers-length|AU-header|AU-header| |AU-header|padding| | | (1) | (2) | | (n) | bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+ Figure 2: The AU Header Section=20 The AU-headers are configured using MIME format parameters and MAY=20 be empty. If the AU-header is configured empty, the=20 AU-headers-length field SHALL NOT be present and consequently the=20 AU Header Section is empty. If the AU-header is not configured=20 empty, then the AU-headers-length is a two octet field that=20 specifies the length in bits of the immediately following=20 AU-headers, excluding the padding bits. Each AU-header is associated with a single Access Unit (fragment)=20 contained in the Access Unit Data Section in the same RTP packet.=20 For each contained Access Unit (fragment) there is exactly one=20 AU-header. Within the AU Header Section, the AU-headers are=20 bit-wise concatenated in the order in which the Access Units are=20 contained in the Access Unit Data Section. Hence, the n-th=20 AU-header refers to the n-th AU (fragment). If the concatenated=20 AU-headers consume a non-integer number of octets, up to 7=20 zero-padding bits MUST be inserted at the end in order to achieve=20 octet-alignment of the AU Header Section. 3.2.1.1 The AU-header Each AU-header may contain the fields given in figure 3. The length in bits of the fields, with the exception of the CTS-flag, the DTS-flag and the RAP-flag fields is defined by MIME format=20 parameters; see section 4.1. If a MIME format parameter has the=20 default value of zero, then the associated field is not present.=20 The number of bits for fields that are present and that represent=20 the value of a parameter MUST be chosen large enough to correctly=20 encode the largest value of that parameter during the session. If present, the fields MUST occur in the mutual order given in=20 figure 3. In the general case a receiver can only discover the size of an AU-header by parsing it since the presence of the CTS-delta=20 and DTS-delta fields is signaled by the value of the CTS-flag and=20 DTS-flag, respectively. van der Meer et al. Expires August 2003 [Page 12] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 +---------------------------------------+ | AU-size | +---------------------------------------+ | AU-Index / AU-Index-delta | +---------------------------------------+ | CTS-flag | +---------------------------------------+ | CTS-delta | +---------------------------------------+ | DTS-flag | +---------------------------------------+ | DTS-delta | +---------------------------------------+ | RAP-flag | +---------------------------------------+ | Stream-state | +---------------------------------------+ Figure 3: The fields in the AU-header. If used, the AU-Index field=20 only occurs in the first AU-header within an AU Header=20 Section; in any other AU-header the AU-Index-delta field=20 occurs instead. AU-size: Indicates the size in octets of the associated Access Unit in the Access Unit Data Section in the same RTP packet. When=20 the AU-size is associated with an AU fragment, the AU size=20 indicates the size of the entire AU and not the size of the=20 fragment. In this case, the size of the fragment is known=20 from the size of the AU data section. This can be exploited=20 to determine whether a packet contains an entire AU or a=20 fragment, which is particularly useful after losing a packet=20 carrying the last fragment of an AU.=20 AU-Index: Indicates the serial number of the associated Access Unit (fragment). For each (in decoding order) consecutive AU or AU fragment, the serial number is incremented with 1. When=20 present, the AU-Index field occurs in the first AU-header in=20 the AU Header Section, but MUST NOT occur in any subsequent=20 (non-first) AU-header in that Section. To encode the serial=20 number in any such non-first AU-header, the AU-Index-delta=20 field is used.=20 AU-Index-delta: The AU-Index-delta field is an unsigned integer=20 that specifies the serial number of the associated AU as the=20 difference with respect to the serial number of the previous=20 Access Unit. Hence, for the n-th (n>1) AU the serial number=20 is found from:=20 AU-Index(n) =3D AU-Index(n-1) + AU-Index-delta(n) + 1 If the AU-Index field is present in the first AU-header in=20 van der Meer et al. Expires August 2003 [Page 13] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 the AU Header Section, then the AU-Index-delta field MUST be=20 present in any subsequent (non-first) AU-header. When the=20 AU-Index-delta is coded with the value 0, it indicates that=20 the Access Units are consecutive in decoding order. An=20 AU-Index-delta value larger than 0 signals that interleaving=20 is applied. CTS-flag: Indicates whether the CTS-delta field is present.=20 A value of 1 indicates that the field is present, a value=20 of 0 that it is not present.=20 The CTS-flag field MUST be present in each AU-header if the=20 length of the CTS-delta field is signaled to be larger than=20 zero. In that case, the CTS-flag field MUST have the value 0 in the first AU-header and MAY have the value 1 in all=20 non-first AU-headers. The CTS-flag field SHOULD be 0 for=20 any non-first fragment of an Access Unit.=20 CTS-delta: Encodes the CTS by specifying the value of CTS as a 2's complement offset (delta) from the time stamp in the RTP=20 header of this RTP packet. The CTS MUST use the same clock=20 rate as the time stamp in the RTP header.=20 DTS-flag: Indicates whether the DTS-delta field is present. A value of 1 indicates that DTS-delta is present, a value of 0 that=20 it is not present.=20 The DTS-flag field MUST be present in each AU-header if the=20 length of the DTS-delta field is signaled to be larger than=20 zero. The DTS-flag field MUST have the same value for all=20 fragments of an Access Unit.=20 DTS-delta: Specifies the value of the DTS as a 2's complement=20 offset (delta) from the CTS. The DTS MUST use the=20 same clock rate as the time stamp in the RTP header. The=20 DTS-delta field MUST have the same value for all fragments of an Access Unit.=20 RAP-flag: Indicates when set to 1 that the associated Access Unit=20 provides a random access point to the content of the stream.=20 If an Access Unit is fragmented, the RAP flag, if present,=20 MUST be set to 0 for each non-first fragment of the AU. Stream-state: Specifies the state of the stream for an AU of an=20 MPEG-4 system stream; each state is identified by a value of a modulo counter. In ISO/IEC 14496-1, MPEG-4 system streams=20 use the AU=5FSequenceNumber to signal stream states. When the=20 stream state changes, the value of stream-state MUST be=20 incremented by one.=20 Note: no relation is required between stream-states of=20 different streams. =20 van der Meer et al. Expires August 2003 [Page 14] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 3.2.2 The Auxiliary Section The Auxiliary Section consists of the auxiliary-data-size field=20 followed by the auxiliary-data field. Receivers MAY (but are not=20 required to) parse the auxiliary-data field; to facilitate skipping of the auxiliary-data field by receivers, the auxiliary-data-size=20 field indicates the length in bits of the auxiliary-data. If the =20 concatenation of the auxiliary-data-size and the auxiliary-data=20 fields consume a non-integer number of octets, up to 7 zero padding bits MUST be inserted immediately after the auxiliary data in order to achieve octet-alignment. See figure 4. =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+ | auxiliary-data-size | auxiliary-data |padding bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+ Figure 4: The fields in the Auxiliary Section=20 The length in bits of the auxiliary-data-size field is configurable by a MIME format parameter; see section 4.1. The default length of=20 zero indicates that the entire Auxiliary Section is absent. auxiliary-data-size: specifies the length in bits of the immediately following auxiliary-data field; auxiliary-data: the auxiliary-data field contains data of a format=20 not defined by this specification. 3.2.3 The Access Unit Data Section The Access Unit Data Section contains an integer number of complete Access Units or a single fragment of one AU. The Access Unit Data=20 Section is never empty. If data of more than one Access Unit is=20 present, then the AUs are concatenated into a contiguous string=20 of octets. See figure 5. The AUs inside the Access Unit Data=20 Section MUST be in decoding order, though not necessarily contiguous in the case of interleaving. The size and number of Access Units SHOULD be adjusted such that=20 the resulting RTP packet is not larger than the path MTU. To handle larger packets, this payload format relies on lower layers for=20 fragmentation, which may result in reduced performance. van der Meer et al. Expires August 2003 [Page 15] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AU(1) | + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |AU(2) | +-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AU(n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AU(n) continued| |-+-+-+-+-+-+-+-+ Figure 5: Access Unit Data Section; each AU is octet-aligned.=20 When multiple Access Units are carried, the size of each AU MUST be made available to the receiver. If the AU size is variable then the size of each AU MUST be indicated in the AU-size field of the=20 corresponding AU-header. However, if the AU size is constant for a=20 stream, this mechanism SHOULD NOT be used, but instead the fixed=20 size SHOULD be signaled by the MIME format parameter=20 "constantSize", see section 4.1.=20 =20 The absence of both AU-size in the AU-header and the constantSize=20 MIME format parameter indicates carriage of a single AU (fragment),=20 i.e. that a single Access Unit (fragment) is transported in each=20 RTP packet for that stream. 3.2.3.1 Fragmentation A packet SHALL carry either one or more complete Access Units, or=20 a single fragment of an Access Unit. Fragments of the same Access=20 Unit have the same time stamp but different RTP sequence numbers.=20 The marker bit in the RTP header is 1 on the last fragment of an=20 Access Unit, and 0 on all other fragments. 3.2.3.2 Interleaving Unless prohibited by the signaled mode, a sender MAY interleave=20 Access Units. Receivers that are capable of receiving modes that=20 support interleaving, MUST be able to decode interleaved Access=20 Units.=20 When a sender interleaves Access Units, it needs to provide=20 sufficient information to enable a receiver to unambiguously=20 reconstruct the original order, even in case of out-of-order=20 packets, packet loss or duplication. The information that senders=20 van der Meer et al. Expires August 2003 [Page 16] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 need to provide depends on whether or not the Access Units have a=20 constant time duration. Access Units have a constant time duration, if: TS(i+1) - TS(i) =3D constant, for any i, where=20 i indicates the index of the AU in original order TS(i) denotes the time stamp of AU(i) The MIME parameter "constantDuration" SHOULD be used to signal that Access Units have a constant time duration, see section 4.1.=20 If the "constantDuration" parameter is present, the receiver can reconstruct the original Access Unit timing based solely on the RTP timestamp and AU-Index-delta. Accordingly, when transmitting Access Units of constant duration, the AU-Index, if present, MUST be set=20 to the value 0. Receivers of constant duration Access Units MUST=20 use the RTP timestamp to determine the index of the first AU in the RTP packet. The AU-Index-delta header and the signaled=20 "constantDuration" are used to reconstruct AU timing. If the "constantDuration" parameter is not present, then Access=20 Units are assumed to have a variable duration, unless the AU-Index=20 is present and coded with the value 0 in each RTP packet. When=20 transmitting Access Units of variable duration, then the=20 "constantDuration" parameter MUST NOT be present, and the=20 transmitter MUST use the AU-Index to encode the index information=20 required for re-ordering, and the receiver MUST use that value to=20 determine the index of each AU in the RTP packet. The number of=20 bits of the AU-Index field MUST be chosen so that valid index=20 information is provided at the applied interleaving scheme, without causing problems due to roll-over of the AU-Index field. In=20 addition, the CTS-delta MUST be coded in the AU header for each=20 non-first AU in the RTP packet, so that receivers can place the AUs correctly in time. When interleaving is applied, a de-interleave buffer is needed in=20 receivers to put the Access Units in their correct logical=20 consecutive decoding order. This requires the computation of the=20 time stamp for each Access Unit. In case of a constant time duration per Access Unit, the time stamp of the i-th access unit in an RTP=20 packet with RTP time stamp T is calculated as follows: Timestamp[0] =3D T Timestamp[i, i > 0] =3D T +(Sum(for k=3D1 to i of (AU-Index-delta[k]=20 + 1))) * access-unit-duration van der Meer et al. Expires August 2003 [Page 17] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 When AU-Index-delta is always 0, this reduces to T + i * (access- unit-duration). This is the non-interleaved case, where the frames=20 are consecutive in decoding order. Note that the AU-Index field=20 (present for the first Access Unit) is indeed not needed in this=20 calculation.=20 3.2.3.3 Constraints for interleaving=20 The size of the packets should be suitably chosen to be appropriate to both the path MTU and the capacity of the receiver's=20 de-interleave buffer. The maximum packet size for a session SHOULD=20 be chosen not to exceed the path MTU. To allow receivers to allocate sufficient resources for=20 de-interleaving, senders MUST provide the information to receivers=20 as specified in this section. AUs enter the decoder in decoding order. The de-interleave buffer=20 is used to re-order a stream of interleaved AUs back into decoding=20 order. When interleaving is applied, the decoding of "early" AUs has to be postponed until all AUs that precede in decoding order are present. Therefore these "early" AUs are stored in the=20 de-interleave buffer. As an example in figure 6 the interleaving=20 pattern from section 2.5 is considered. +--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|.. +--+--+--+--+--+--+--+--+--+--+--+- Storage of "early" AUs 3 3 3 3 3 3 6 6 6 6 6 6 4 4 4=20 7 7 7 12 12 Figure 6: Storage of "early" AUs in the de-interleave buffer per=20 interleaved AU. AU(3) is to be delivered to the decoder after AU(0), AU(1)and=20 AU(2); of these AUs, AU(2) is most late and hence AU(3) needs to be stored until AU(2) is present in the pattern. Similarly, AU(6) is=20 to be stored until AU(5) is present, while AU(4) and AU(7) are to=20 be stored until AU(2) and AU(5) are present, respectively. Note=20 that the fullness of the de-interleave buffer varies in time. In=20 figure 6, the de-interleave buffer contains at most 4, but often=20 less AUs. So as to give a rough indication of the resources needed in the=20 receiver for de-interleaving, the maximum displacement in time of=20 an AU is defined. For any AU in the pattern it can be verified=20 van der Meer et al. Expires August 2003 [Page 18] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 which AUs are not yet present. The maximum displacement in time of an AU is the maximum difference between the time stamp of an AU in the pattern and the time stamp of the earliest AU that is not yet=20 present. In other words, when considering a sequence of interleaved AUs, then: Maximum displacement =3D max{TS(i) - TS(j)}, for any i and any j>i, =20 where i and j indicate the index of the AU in the=20 interleaving pattern and TS denotes the time stamp of the AU As an example in figure 7 the interleaving pattern from section 2.5 is considered. For each AU in the pattern the earliest not yet present AU is indicated. A "-" indicates that all previous AUs=20 are present. If the AU period is constant, the maximum displacement equals 5 AU periods, as found for AU(6) and AU(7).=20 +--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|.. +--+--+--+--+--+--+--+--+--+--+--+- Earliest not yet present AU - 1 1 - 2 2 - - - - 10 Figure 7: The earliest not yet present AU for each AU in the=20 interleaving pattern. When interleaving, senders MUST signal the maximum displacement=20 in time during the session via the MIME format parameter=20 "maxDisplacement"; see section 4.1.=20 An estimate of the size of the de-interleave buffer is found by=20 multiplying the maximum displacement by the maximum bit rate: size(de-interleave buffer) =3D {(maxDisplacement) * Rate(max)} / (RTP clock frequency), where Rate(max) is the maximum bit-rate of the transported stream.=20 Note that receivers can derive Rate(max) from the MIME format=20 parameters streamType, profile-level-id, and config.=20 =20 However, this calculation estimates the size of the de-interleave=20 buffer and the really required size may differ from the calculated value. If this calculation under-estimates the size of the=20 de-interleave buffer, then senders, when interleaving, MUST signal a size of the de-interleave buffer via the MIME format parameter=20 "de-interleaveBufferSize"; see section 4.1. If the calculation=20 van der Meer et al. Expires August 2003 [Page 19] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 over-estimates the size of the de-interleave buffer, then senders, when interleaving, MAY signal a size of the de-interleave buffer=20 via the MIME format parameter "de-interleaveBufferSize".=20 The signaled size of the de-interleave buffer MUST be large enough=20 to contain all "early" AUs at any point in time during the session, that is: minimum de-interleave buffer size =3D max [sum {if TS(i) > TS(j) then=20 AU-size(i) else 0}] for any j=20 and any i /[/]=20 For audio streams, specifies the number of audio channels: 2 for stereo material (see RFC 2327 [5]) and 1 for=20 mono. Provided no additional parameters are needed, this parameter may be omitted for mono material, hence its default value is 1. 3.3.2 The generic mode The generic mode can be used for any MPEG-4 stream. In this mode=20 no mode-specific constraints are applied; hence, in the generic=20 mode the full flexibility of this specification can be exploited.=20 The generic mode is signaled by mode=3Dgeneric.=20 An example is given below for transport of a BIFS-Anim stream. In=20 this example carriage of multiple BIFS-Anim Access Units is allowed in one RTP packet. The AU-header contains the AU-size field, the=20 CTS-flag and, if the CTS flag is set to 1, the CTS-delta field. The number of bits of the AU-size and the CTS-delta fields is 10 and=20 16, respectively. The AU-header also contains the RAP-flag and the Stream-state of 4 bits. This results in an AU-header with a=20 total size of two or four octets per BIFS-Anim AU. The RTP time=20 stamp uses a 1 kHz clock. Note that the media type name is video,=20 because the BIFS-Anim stream is part of an audio-visual=20 presentation. For conventions on media type names see section 4.1. In detail: m=3Dvideo 49230 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/1000 a=3Dfmtp:96 streamtype=3D3; profile-level-id=3D1807; mode=3Dgeneric;=20 objectType=3D2; config=3D0842237F24001FB400094002C0; sizeLength=3D10;=20 CTSDeltaLength=3D16; randomAccessIndication=3D1;=20 streamStateIndication=3D4 Note: The a=3Dfmtp line has been wrapped to fit the page, it comprises a single line in the SDP file. van der Meer et al. Expires August 2003 [Page 22] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 The hexadecimal value of the "config" parameter is the=20 BIFSConfiguration() as defined in ISO/IEC 14496-1. The=20 BIFSConfiguration() specifies that the BIFS stream is a BIFS-Anim=20 stream. For the description of MIME parameters see section 4.1. 3.3.3 Constant bit-rate CELP This mode is signaled by mode=3DCELP-cbr. In this mode one or more=20 complete CELP frames of fixed size can be transported in one RTP=20 packet; interleaving MUST NOT be used with this mode. The RTP=20 payload consists of one or more concatenated CELP frames, each of=20 the same size. CELP frames MUST NOT be fragmented when using this=20 mode. Both the AU Header Section and the Auxiliary Section MUST be=20 empty.=20 The MIME format parameter constantSize MUST be provided to specify=20 the length of each CELP frame. For example: m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/16000/1 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D14; mode=3DCELP-cbr; conf= ig=3D 440E00; constantSize=3D27; constantDuration=3D240 Note: The a=3Dfmtp line has been wrapped to fit the page, it comprises a single line in the SDP file. The hexadecimal value of the "config" parameter is the=20 AudioSpecificConfig()as defined in ISO/IEC 14496-3.=20 AudioSpecificConfig() specifies a mono CELP stream with a sampling=20 rate of 16 kHz at a fixed bitrate of 14.4 kb/s and 6 sub-frames per CELP frame. For the description of MIME parameters see section 4.1. 3.3.4 Variable bit-rate CELP This mode is signaled by mode=3DCELP-vbr. With this mode one or more=20 complete CELP frames of variable size can be transported in one RTP packet with OPTIONAL interleaving. As CELP frames are very small,=20 while the largest possible AU-size in this mode is greater than the maximum CELP frame size, there is no support for fragmentation of=20 CELP frames. Hence CELP frames MUST NOT be fragmented when using=20 this mode.=20 In this mode the RTP payload consists of the AU Header Section,=20 followed by one or more concatenated CELP frames. The Auxiliary=20 Section MUST be empty. For each CELP frame contained in the payload there MUST be a one octet AU-header in the AU Header Section to=20 provide:=20 (a) the size of each CELP frame in the payload and=20 (b) index information for computing the sequence (and hence timing) of each CELP frame. van der Meer et al. Expires August 2003 [Page 23] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Transport of CELP frames requires that the AU-size field is coded=20 with 6 bits. In this mode therefore 6 bits are allocated to the=20 AU-size field, and 2 bits to the AU-Index(-delta) field. Each=20 AU-Index field MUST be coded with the value 0. In the AU Header=20 Section, the concatenated AU-headers are preceded by the 16-bit=20 AU-headers-length field, as specified in section 3.2.1.=20 In addition to the required MIME format parameters, the following=20 parameters MUST be present: sizeLength, indexLength, and=20 indexDeltaLength. CELP frames have fixed time duration per Access=20 Unit; when interleaving in this mode, the applicable duration MUST=20 be signaled by the MIME format parameter constantDuration. In=20 addition, the parameter maxDisplacement MUST be present when=20 interleaving. For example: m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/16000/1 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D14; mode=3DCELP-vbr; conf= ig=3D 440F20; sizeLength=3D6; indexLength=3D2; indexDeltaLength=3D2;=20 constantDuration=3D160; maxDisplacement=3D5 Note: The a=3Dfmtp line has been wrapped to fit the page, it comprises a single line in the SDP file. The hexadecimal value of the "config" parameter is the =20 AudioSpecificConfig()as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono CELP stream with a sampling=20 rate of 16 kHz at a bitrate that varies between 13.9 and 16.2 kb/s and with 4 sub-frames per CELP frame. For the description of MIME=20 parameters see section 4.1. 3.3.5 Low bit-rate AAC This mode is signaled by mode=3DAAC-lbr. This mode supports transport of one or more complete AAC frames of variable size. In this mode=20 the AAC frames are allowed to be interleaved and hence receivers=20 MUST support de-interleaving. The maximum size of an AAC frame in=20 this mode is 63 octets. AAC frames MUST NOT be fragmented when=20 using this mode. Hence, when using this mode, encoders MUST ensure=20 that the size of each AAC frame is at most 63 octets. The payload configuration in this mode is the same as in the=20 variable bit-rate CELP mode as defined in 3.3.4. The RTP payload=20 consists of the AU Header Section, followed by concatenated AAC=20 frames. The Auxiliary Section MUST be empty. For each AAC frame=20 contained in the payload the one octet AU-header MUST provide:=20 (a) the size of each AAC frame in the payload and=20 (b) index information for computing the sequence (and hence timing) of each AAC frame. van der Meer et al. Expires August 2003 [Page 24] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 In the AU-header Section, the concatenated AU-headers MUST be=20 preceded by the 16-bit AU-headers-length field, as specified in=20 section 3.2.1.=20 In addition to the required MIME format parameters, the following=20 parameters MUST be present: sizeLength, indexLength, and=20 indexDeltaLength. AAC frames have fixed time duration per Access=20 Unit; when interleaving in this mode, the applicable duration MUST=20 be signaled by the MIME format parameter constantDuration. In=20 addition, the parameter maxDisplacement MUST be present when=20 interleaving.=20 For example: m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/22050/1 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D14; mode=3DAAC-lbr; confi= g=3D 1388; sizeLength=3D6; indexLength=3D2; indexDeltaLength=3D2;=20 constantDuration=3D1024; maxDisplacement=3D5=20 Note: The a=3Dfmtp line has been wrapped to fit the page, it comprises a single line in the SDP file. The hexadecimal value of the "config" parameter is the=20 AudioSpecificConfig() as defined in ISO/IEC 14496-3.=20 AudioSpecificConfig() specifies a mono AAC stream with a sampling=20 rate of 22.05 kHz. For the description of MIME parameters see=20 section 4.1. =20 3.3.6 High bit-rate AAC This mode is signaled by mode=3DAAC-hbr. This mode supports transport of variable size AAC frames. In one RTP packet either one or more=20 complete AAC frames are carried, or a single fragment of an AAC=20 frame. In this mode the AAC frames are allowed to be interleaved=20 and hence receivers MUST support de-interleaving. The maximum size of an AAC frame in this mode is 8191 octets.=20 In this mode the RTP payload consists of the AU Header Section,=20 followed by either one AAC frame, several concatenated AAC frames=20 or one fragmented AAC frame. The Auxiliary Section MUST be empty.=20 For each AAC frame contained in the payload there MUST be an=20 AU-header in the AU Header Section to provide: (a) the size of each AAC frame in the payload and=20 (b) index information for computing the sequence (and hence timing) of each AAC frame. To code the maximum size of an AAC frame requires 13 bits. Therefore in this configuration 13 bits are allocated to the AU-size, and=20 3 bits to the AU-Index(-delta) field. Thus each AU-header has a size of 2 octets. Each AU-Index field MUST be coded with the value 0. In the AU Header Section, the concatenated AU-headers MUST be preceded van der Meer et al. Expires August 2003 [Page 25] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 by the 16-bit AU-headers-length field, as specified in=20 section 3.2.1. In addition to the required MIME format parameters, the following=20 parameters MUST be present: sizeLength, indexLength, and=20 indexDeltaLength. AAC frames have fixed time duration per Access=20 Unit; when interleaving in this mode, the applicable duration MUST=20 be signaled by the MIME format parameter constantDuration. In=20 addition, the parameter maxDisplacement MUST be present when=20 interleaving.=20 For example: m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/48000/6 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D16; mode=3DAAC-hbr;=20 config=3D11B0; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024=20 Note: The a=3Dfmtp line has been wrapped to fit the page, it comprises a single line in the SDP file. The hexadecimal value of the "config" parameter is the=20 AudioSpecificConfig() as defined in ISO/IEC 14496-3.=20 AudioSpecificConfig() specifies a 5.1 channel AAC stream with a=20 sampling rate of 48 kHz. For the description of MIME parameters see=20 section 4.1. 3.3.7 Additional modes This specification only defines the modes specified in sections=20 3.3.2 up to 3.3.6. Additional modes are expected to be defined in=20 future RFCs. Each additional mode MUST be in full compliance with=20 this specification. Any new mode MUST be defined such that an implementation including all the features of this specification can decode the payload format corresponding to this new mode. For this reason a mode MUST NOT=20 specify new default values for MIME parameters. In particular, MIME parameters that configure the RTP payload MUST be present (unless=20 they have the default value), even if its presence is redundant in=20 case the mode assigns a fixed value to a parameter. A mode may=20 define additionally that some MIME parameters are required instead=20 of optional, that some MIME parameters have fixed values (or=20 ranges), and that there are rules restricting the usage. =20 van der Meer et al. Expires August 2003 [Page 26] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 4. IANA considerations=20 This section describes the MIME types and names associated with=20 this payload format. Section 4.1 registers the MIME types, as per=20 RFC 2048 [3].=20 =20 This format may require additional information about the mapping to be made available to the receiver. This is done using parameters=20 also described in the next section. =20 4.1 MIME type registration=20 =20 MIME media type name: "video" or "audio" or "application"=20 =20 "video" MUST be used for MPEG-4 Visual streams (ISO/IEC 14496-2)=20 or MPEG-4 Systems streams (ISO/IEC 14496-1) that convey information needed for an audio/visual presentation.=20 =20 "audio" MUST be used for MPEG-4 Audio streams (ISO/IEC 14496-3)=20 or MPEG-4 Systems streams that convey information needed for an=20 audio only presentation.=20 "application" MUST be used for MPEG-4 Systems streams (ISO/IEC=20 14496-1) that serve purposes other than audio/visual presentation, e.g. in some cases when MPEG-J (Java) streams are transmitted.=20 =20 Depending on the required payload configuration, MIME format=20 parameters need to be available to the receiver. This is done using the parameters described in the next section. There are required=20 and optional parameters.=20 Optional parameters are of two types: general parameters and=20 configuration parameters. The configuration parameters are used to=20 configure the fields in the AU Header section and in the auxiliary=20 section. The absence of any configuration parameter is equivalent to the associated field set to its default value, which is always zero. The absence of all configuration parameters resolves into a default "basic" configuration with an empty AU-header section and an empty=20 auxiliary section in each RTP packet.=20 =20 MIME subtype name: mpeg4-generic Required parameters: MIME format parameters are not case dependent; however for clarity=20 both upper and lower case are used in the names of the parameters=20 described in this specification.=20 streamType: The integer value that indicates the type of MPEG-4 stream that=20 is carried; its coding corresponds to the values of the=20 streamType as defined in Table 9 (streamType Values) in ISO/IEC=20 14496-1. van der Meer et al. Expires August 2003 [Page 27] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 profile-level-id:=20 A decimal representation of the MPEG-4 Profile Level indication. This parameter MUST be used in the capability exchange or=20 session set-up procedure to indicate the MPEG-4 Profile and Level combination of which the relevant MPEG-4 media codec is capable=20 of.=20 For MPEG-4 Audio streams, this parameter is the decimal value=20 from Table 5 (audioProfileLevelIndication Values) in ISO/IEC=20 14496-1, indicating which MPEG-4 Audio tool subsets are=20 required to decode the audio stream.=20 For MPEG-4 Visual streams, this parameter is the decimal value=20 from Table G-1 (FLC table for profile and level indication) of=20 ISO/IEC 14496-2, indicating which MPEG-4 Visual tool subsets=20 are required to decode the visual stream. For BIFS streams, this parameter is the decimal value that is obtained from (SPLI + 256*GPLI), where: SPLI is the decimal value from Table 4 in ISO/IEC 14496-1 with the applied sceneProfileLevelIndication; GPLI is the decimal value from Table 7 in ISO/IEC 14496-1 with the applied graphicsProfileLevelIndication. For MPEG-J streams, this parameter is the decimal value from=20 table 13 (MPEGJProfileLevelIndication) in ISO/IEC 14496-1,=20 indicating the profile and level of the MPEG-J stream. For OD streams, this parameter is the decimal value from table 3 (ODProfileLevelIndication) in ISO/IEC 14496-1, indicating the profile and level of the OD stream. For IPMP streams, this parameter has either the decimal value 0, indicating an unspecified profile and level, or a value larger than zero, indicating an MPEG-4 IPMP profile and level as=20 defined in a future MPEG-4 specification.=20 For Clock Reference streams and Object Content Info streams, this parameter has the decimal value zero, indicating that profile and level information is conveyed through the OD framework. config:=20 A hexadecimal representation of an octet string that expresses the media payload configuration. Configuration data is mapped=20 onto the hexadecimal octet string in an MSB-first basis. The=20 first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, if necessary to achieve=20 octet-alignment, up to 7 zero-valued padding bits shall follow=20 the configuration data.=20 For MPEG-4 Audio streams, config is the audio object type=20 specific decoder configuration data AudioSpecificConfig() as=20 defined in ISO/IEC 14496-3. For Structured Audio, the=20 AudioSpecificConfig() may be conveyed by other means, not=20 defined by this specification. If the AudioSpecificConfig()=20 is conveyed by other means for Structured Audio, then the=20 config MUST be a quoted empty hexadecimal octet string, as=20 follows: config=3D"".=20 Note that a future mode of using this RTP payload format for=20 Structured Audio may define such other means. van der Meer et al. Expires August 2003 [Page 28] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 For MPEG-4 Visual streams, config is the MPEG-4 Visual configuration information as defined in subclause 6.2.1 Start codes of ISO/IEC 14496-2. The configuration information=20 indicated by this parameter SHALL be the same as the=20 configuration information in the corresponding MPEG-4 Visual=20 stream, except for first-half-vbv-occupancy and=20 latter-half-vbv-occupancy, if it exists, which may vary in=20 the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC 14496-2). For BIFS streams, this is the BIFSConfig() information as defined in ISO/IEC 14496-1. For version 1, BIFSConfig is defined in=20 section 9.3.5.2, and for version 2 in section 9.3.5.3. The=20 MIME format parameter objectType signals the version of=20 BIFSConfig. For IPMP streams, this is either a quoted empty hexadecimal octet string, indicating the absence of any decoder configuration=20 information (config=3D""), or the IPMPConfiguration() as=20 defined in a future MPEG-4 IPMP specification.=20 For Object Content Info (OCI) streams, this is the=20 OCIDecoderConfiguration() information of the OCI stream, as=20 defined in section 8.4.2.4 in ISO/IEC 14496-1. For OD streams, Clock Reference streams and MPEG-J streams, this=20 is a quoted empty hexadecimal octet string (config=3D""), as=20 no information on the decoder configuration is required. mode:=20 The mode in which this specification is used. The following modes can be signaled: mode=3Dgeneric, mode=3DCELP-cbr, mode=3DCELP-vbr, mode=3DAAC-lbr and mode=3DAAC-hbr. Other modes are expected to be defined in future RFCs. See also=20 section 3.3.7 and 4.2 of RFC xxxx. Optional general parameters: objectType: The decimal value from Table 8 in ISO/IEC 14496-1, indicating=20 the value of the objectTypeIndication of the transported stream. For BIFS streams this parameter MUST be present to signal the=20 version of BIFSConfiguration(). Note that objectTypeIndication=20 may signal a non-MPEG-4 stream and that the RTP payload format=20 defined in this document may not be suitable to carry a stream=20 that is not defined by MPEG-4. The objectType parameter SHOULD=20 NOT be set to a value that signals a stream that cannot be=20 carried by this payload format. constantSize: The constant size in octets of each Access Unit for this stream. The constantSize and the sizeLength parameters MUST NOT be simultaneously present. van der Meer et al. Expires August 2003 [Page 29] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 constantDuration: The constant duration of each Access Unit for this stream, measured with the same units as the RTP time stamp. maxDisplacement: The decimal representation of the maximum displacement in time=20 of an interleaved AU, as defined in section 3.2.3.3, expressed=20 in units of the RTP time stamp clock. This parameter MUST be present when interleaving is applied. de-interleaveBufferSize: The decimal representation in number of octets of the size of=20 the de-interleave buffer, described in section 3.2.3.3. When interleaving, this parameter MUST be present if the=20 calculation of the de-interleave buffer size given in 3.2.3.3=20 and based on maxDisplacement and rate(max) under-estimates the=20 size of the de-interleave buffer. If this calculation does not=20 under-estimate the size of the de-interleave buffer, then the=20 de-interleaveBufferSize parameter SHOULD NOT be present. Optional configuration parameters: sizeLength:=20 The number of bits on which the AU-size field is encoded in the=20 AU-header. The sizeLength and the constantSize parameters MUST=20 NOT be simultaneously present. indexLength: The number of bits on which the AU-Index is encoded in the first AU-header. The default value of zero indicates the absence of=20 the AU-Index field in each first AU-header. indexDeltaLength: The number of bits on which the AU-Index-delta field is encoded=20 in any non-first AU-header. The default value of zero indicates the absence of the AU-Index-delta field in each non-first AU-header. CTSDeltaLength: The number of bits on which the CTS-delta field is encoded in=20 the AU-header.=20 DTSDeltaLength: The number of bits on which the DTS-delta field is encoded in=20 the AU-header.=20 randomAccessIndication: A decimal value of zero or one, indicating whether the RAP-flag=20 is present in the AU-header. The decimal value of one indicates presence of the RAP-flag, the default value zero its absence. van der Meer et al. Expires August 2003 [Page 30] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 streamStateIndication: The number of bits on which the Stream-state field is encoded in the AU-header. This parameter MAY be present when transporting=20 MPEG-4 system streams, and SHALL NOT be present for MPEG-4 audio=20 and MPEG-4 video streams. auxiliaryDataSizeLength: The number of bits that is used to encode the auxiliary-data-size field.=20 Applications MAY use more parameters, in addition to those defined=20 above. Each additional parameter MUST be registered with IANA, to=20 ensure that there is no clash of names. Each additional parameter=20 MUST be accompanied by a specification in the form of an RFC, MPEG=20 standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]). Receivers MUST tolerate the presence of such additional parameters, but these=20 parameters SHALL NOT impact the decoding of receivers that comply to=20 this specification.=20 Encoding considerations:=20 This MIME subtype is defined for RTP transport only. System=20 bitstreams MUST be generated according to MPEG-4 Systems=20 specifications (ISO/IEC 14496-1). Video bitstreams MUST be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). Audio=20 bitstreams MUST be generated according to MPEG-4 Audio=20 specifications (ISO/IEC 14496-3). The RTP packets MUST be packetized according to the RTP payload format defined in RFC xxxx.=20 =20 Security considerations:=20 As defined in section 5 of RFC xxxx.=20 =20 Interoperability considerations:=20 MPEG-4 provides a large and rich set of tools for the coding of=20 visual objects. For effective implementation of the standard,=20 subsets of the MPEG-4 tool sets have been provided for use in=20 specific applications. These subsets, called 'Profiles', limit the=20 size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more 'Levels' are set for=20 each Profile. A Profile@Level combination allows:=20 . a codec builder to implement only the subset of the standard he=20 needs, while maintaining interworking with other MPEG-4 devices=20 that implement the same combination, and=20 . checking whether MPEG-4 devices comply with the standard=20 ('conformance testing').=20 =20 A stream SHALL be compliant with the MPEG-4 Profile@Level specified by the parameter "profile-level-id". Interoperability between a=20 sender and a receiver is achieved by specifying the parameter=20 "profile-level-id" in MIME content. In the capability exchange /=20 announcement procedure this parameter may mutually be set to the=20 same value.=20 van der Meer et al. Expires August 2003 [Page 31] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Published specification:=20 The specifications for MPEG-4 streams are presented in ISO/IEC=20 14496-1, 14496-2, and 14496-3. The RTP payload format is described=20 in RFC xxxx.=20 Applications which use this media type:=20 Multimedia streaming and conferencing tools. =20 Additional information: none=20 =20 Magic number(s): none=20 =20 File extension(s):=20 None. A file format with the extension .mp4 has been defined for=20 MPEG-4 content but is not directly correlated with this MIME type=20 for which the sole purpose is RTP transport.=20 =20 Macintosh File Type Code(s): none=20 =20 Person & email address to contact for further information:=20 Authors of RFC xxxx, IETF Audio/Video Transport working group.=20 =20 Intended usage: COMMON=20 =20 Author/Change controller:=20 Authors of RFC xxxx, IETF Audio/Video Transport working group.=20 =20 4.2 Registration of mode definitions with IANA This specification can be used in a number of modes. The mode of operation is signaled using the "mode" MIME parameter, with the initial set of values specified in section 4.1. New modes may be defined at any time, as described in section 3.3.7. These modes MUST be registered with IANA, to ensure that there is no clash of names.=20 A new mode registration MUST be accompanied by a specification in the form of an RFC, MPEG standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]).=20 4.3 Concatenation of parameters=20 =20 Multiple parameters SHOULD be expressed as a MIME media type string, in the form of a semicolon-separated list of parameter=3Dvalue pairs=20 (for parameter usage examples see sections 3.3.2 up to 3.3.6).=20 =20 van der Meer et al. Expires August 2003 [Page 32] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 4.4 Usage of SDP=20 =20 4.4.1 The a=3Dfmtp keyword=20 =20 It is assumed that one typical way to transport the above-described parameters associated with this payload format is via a SDP message [5] for example transported to the client in reply to a RTSP=20 DESCRIBE [8] or via SAP [11]. In that case the (a=3Dfmtp) keyword=20 MUST be used as described in RFC 2327 [5], section 6, the syntax=20 being then:=20 =20 a=3Dfmtp: =3D[; =3D] 5. Security Considerations =20 RTP packets using the payload format defined in this specification=20 are subject to the security considerations discussed in the RTP=20 specification [2]. This implies that confidentiality of the media=20 streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be=20 performed on the compressed data so there is no conflict between the two operations. The packet processing complexity of this payload=20 type (i.e. excluding media data processing) does not exhibit any=20 significant non-uniformity in the receiver side to cause a denial- of-service threat. =20 =20 However, it is possible to inject non-compliant MPEG streams (Audio, Video, and Systems) to overload the receiver/decoder's buffers,=20 which might compromise the functionality of the receiver or even=20 crash it. This is especially true for end-to-end systems like MPEG=20 where the buffer models are precisely defined.=20 =20 MPEG-4 Systems supports stream types including commands that are=20 executed on the terminal like OD commands, BIFS commands, etc. and=20 programmatic content like MPEG-J (Java(TM) Byte Code) and=20 ECMAScript. It is possible to use one or more of the above in a=20 manner non-compliant to MPEG to crash the receiver or make it=20 temporarily unavailable. Senders that transport MPEG-4 content=20 SHOULD ensure that such content is MPEG compliant, as defined in the compliance part of IEC/ISO 14496 [1]. Receivers that support MPEG-4=20 content should prevent malfunctioning of the receiver in case of=20 non MPEG compliant content. Authentication mechanisms can be used to validate the sender and the data to prevent security problems due to non-compliant malignant MPEG-4 streams.=20 In ISO/IEC 14496-1 a security model is defined for MPEG-4 Systems=20 streams carrying MPEG-J access units which comprise Java(TM) classes and objects. MPEG-J defines a set of Java APIs and a secure=20 execution model. MPEG-J content can call this set of APIs and=20 van der Meer et al. Expires August 2003 [Page 33] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 =20 Java(TM) methods from a set of Java packages supported in the=20 receiver within the defined security model. According to this=20 security model, downloaded byte code is forbidden to load libraries, define native methods, start programs, read or write files, or read system properties.=20 Receivers can implement intelligent filters to validate the buffer=20 requirements or parametric (OD, BIFS, etc.) or programmatic (MPEG-J, ECMAScript) commands in the streams. However, this can increase the=20 complexity significantly.=20 6. Acknowledgements=20 =20 This document evolved through several revisions thanks to=20 contributions by people from the ISMA forum, from the IETF AVT=20 Working Group and from the 4-on-IP ad-hoc group within MPEG. The=20 authors wish to thank all involved people, and in particular Andrea Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John=20 Lazaro, Zvi Lifshitz, Young-kwon Lim, Alex MacAulay, Bill May,=20 Colin Perkins, Dorairaj V and Stephan Wenger for their valuable=20 comments and support.=20 7. References 7.1 Normative references [1] ISO/IEC International Standard 14496 (MPEG-4); "Information=20 technology - Coding of audio-visual objects", January 2000 =20 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson RTP, "A=20 Transport Protocol for Real Time Applications", RFC 1889, Internet=20 Engineering Task Force, January 1996. [3] N. Freed, J. Klensin, J. Postel, " Multipurpose Internet Mail=20 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Internet Engineering Task Force, November 1996. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] M. Handley, V. Jacobson, "SDP: Session Description Protocol",=20 RFC 2327, Internet Engineering Task Force, April 1998. [6] T. Narten, H. Alvestrand, " Guidelines for Writing an IANA=20 Considerations Section in RFCs", RFC 2434, October 1998. 7.2 Informative references [7] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar, "RTP payload=20 format for MPEG1/MPEG2 Video", RFC 2250, January 1998. van der Meer et al. Expires August 2003 [Page 34] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 [8] H. Schulzrinne, A. Rao, R. Lanphier, "RTSP: Real-Time Session=20 Protocol", RFC 2326, Internet Engineering Task Force, April 1998. [9] C. Perkins, O. Hodson, "Options for Repair of Streaming Media" RFC 2354, Internet Engineering Task Force, June 1998. [10] H. Schulzrinne, J. Rosenberg, "An RTP Payload Format for=20 Generic Forward Error Correction", RFC 2733, Internet Engineering=20 Task Force, December 1999. [11] M. Handley, C. Perkins, E. Whelan, "SAP: Session Announcement=20 Protocol", RFC 2974, Internet Engineering Task Force, October 2000. [12] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata, "RTP payload format for MPEG-4 Audio/Visual streams", RFC 3016, Internet Engineering Task Force, November 2000. 8. Author Addresses Jan van der Meer Philips Electronics, MP4Net Prof Holstlaan 4 Building WDB-1 5600 JZ Eindhoven Netherlands Email : jan.vandermeer@philips.com David Mackie Apple Computer, Inc. One Infinite Loop, MS:302-2LF Cupertino CA 95014 Email: dmackie@apple.com Viswanathan Swaminathan Sun Microsystems Inc. 901 San Antonio Road, M/S UMPK15-214 Palo Alto, CA 94303 Email: viswanathan.swaminathan@sun.com David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 Email: singer@apple.com =20 Philippe Gentric=20 Philips Electronics, MP4Net=20 51 rue Carnot=20 92156 Suresnes=20 France=20 e-mail: philippe.gentric@philips.com=20 van der Meer et al. Expires August 2003 [Page 35] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Full Copyright Statement Copyright (C) The Internet Society (February 2003). All Rights=20 Reserved.=20 =20 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain=20 it or assist in its implementation may be prepared, copied,=20 published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this=20 paragraph are included on all such copies and derivative works.=20 However, this document itself may not be modified in any way, such=20 as by removing the copyright notice or references to the Internet=20 Society or other Internet organizations, except as needed for the=20 purpose of developing Internet standards in which case the=20 procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages=20 other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on=20 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. van der Meer et al. Expires August 2003 [Page 36] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 APPENDIX: Usage of this payload format Appendix A. Interleave analysis A.1 Introduction In this appendix interleaving issues are discussed. Some general=20 notes are provided on de-interleaving and error concealment, while=20 a number of interleaving patterns are examined, in particular=20 for determining the maximum displacement in time and the size of=20 the de-interleave buffer. In these examples, the maximum=20 displacement is cited in terms of an access unit count, for ease of reading. In actual streams, it is signaled in units of the RTP=20 time stamp clock.=20 A.2 De-interleaving and error concealment This appendix does not describe any details on de-interleaving and=20 error concealment, as the control of the AU decoding and error=20 concealment process has little to do with interleaving. If the=20 next AU to be decoded is present and there is sufficient storage=20 available for the decoded AU, then decode it now. If not, wait.=20 When the decoding deadline is reached (i.e., the time when decoding must begin in order to be completed by the time the AU is to be=20 presented), or if the decoder is some hardware that presents a=20 constant delay between initiation of decoding of an AU and=20 presentation of that AU, then decoding must begin at that deadline=20 time. If the next AU to be decoded is not present when the decoding deadline is reached, then that AU is lost so the receiver must take whatever error concealment measures is deemed appropriate. The=20 play-out delay may need to be adjusted at that point (especially if other AUs have also missed their deadline recently). Or, if it was=20 a momentary delay, and maintaining the latency is important, then=20 the receiver should minimize the glitch and continue processing=20 with the next AU. A.3 Simple Group interleave A.3.1 Introduction An example of regular interleave is when packets are formed into=20 groups. If the 'stride' of the interleave (the distance between=20 interleaved AUs) is N, packet 0 could contain AU(0), AU(N), AU(2N), and so on; packet 1 could contain AU(1), AU(1+N), AU(1+2N), and so=20 on. If there are M access units in a packet, then there are M*N=20 access units in the group. =20 van der Meer et al. Expires August 2003 [Page 37] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 An example with N=3DM=3D3 follows; note that this is the same example=20 as given in section 2.5 and that a fixed time duration per Access Unit is assumed: Packet Time stamp Carried AUs AU-Index, AU-Index-delta P(0) T[0] 0, 3, 6 0, 2, 2 P(1) T[1] 1, 4, 7 0, 2, 2 P(2) T[2] 2, 5, 8 0, 2, 2 P(3) T[9] 9,12,15 0, 2, 2 In this example the AU-Index is present in the first AU-header and=20 coded with the value 0, as required for fixed duration AUs. The=20 position of the first AU of each packet within the group is defined by the RTP time stamp, while the AU-Index-delta field indicates the position of subsequent AUs relative to the first AU in the packet.=20 All AU-Index-delta fields are coded with the value N-1, equal to 2=20 in this example. Hence the RTP time stamp and the AU-Index-delta are used to reconstruct the original order. See also section 3.2.3.2. A.3.2 Determining the de-interleave buffer size For the regular pattern as in this example, figure 6 in section=20 3.2.3.3 shows that the de-interleave buffer stores at most 4 AUs. A de-interleaveBufferSize value may be signaled that is at least=20 equal to the total number of octets of any 4 "early" AUs that are=20 stored at the same time. A.3.3 Determining the maximum displacement For the regular pattern as in this example, figure 7 in section 3.3 shows that the maximum displacement in time equals 5 AU periods.=20 Hence the minimum maxDisplacement value that must be signaled is 5=20 AU periods. In case each AU has the same size, this maxDisplacement value over-estimates the de-interleave buffer size with one AU. However, note that in case of variable AU sizes the total size of=20 any 4 "early" AUs that must be stored at the same time may exceed=20 maxDisplacement times the maximum bitrate, in which case the=20 de-interleaveBufferSize must be signaled. =20 A.4 More subtle group interleave A.4.1 Introduction Another example of forming packets with group interleave is given=20 below. In this example the packets are formed such that the loss of two subsequent RTP packets does not cause the loss of two subsequent AUs. Note that in this example the RTP time stamps of packet 3 and=20 packet 4 are earlier than the RTP time stamps of packets 1 and 2,=20 respectively; a fixed time duration per Access Unit is assumed. van der Meer et al. Expires August 2003 [Page 38] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 Packet Time stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0, 5 0, 4 1 T[2] 2, 7 0, 4 2 T[4] 4, 9 0, 4 3 T[1] 1, 6 0, 4 4 T[3] 3, 8 0, 4 5 T[10] 10, 15 0, 4 and so on .. In this example the AU-Index is present in the first AU-header and=20 coded with the value 0, as required for AUs with a fixed duration.=20 To reconstruct the original order, the RTP time stamp and the=20 AU-Index-delta (coded with the value 4) are used. See also=20 section 3.2.3.2. A.4.2 Determining the de-interleave buffer size From figure 8 it can be to determined that at most 5 "early" AUs=20 are to be stored. If the AUs are of constant size, then this value=20 equals 5 times the AU size. The minimum size of the de-interleave=20 buffer equals the maximum total number of octets of the "early" AUs that are to be stored at the same time. This gives the minimum=20 value of the de-interleaveBufferSize that may be signaled. +--+--+--+--+--+--+--+--+--+--+ Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8| +--+--+--+--+--+--+--+--+--+--+ - - 5 - 5 - 2 7 4 9 7 4 9 5 "Early" AUs 5 6 7 7 9 9 Figure 8: Storage of "early" AUs in the de-interleave buffer per=20 interleaved AU. A.4.3 Determining the maximum displacement From figure 9 it can be seen that the maximum displacement in time=20 equals 8 AU periods. Hence the minimum maxDisplacement value to be=20 signaled is 8 AU periods.=20 +--+--+--+--+--+--+--+--+--+--+ Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8| +--+--+--+--+--+--+--+--+--+--+ Earliest not yet present AU - 1 1 1 1 1 - 3 - -=20 Figure 9: The earliest not yet present AU for each AU in the=20 interleaving pattern. van der Meer et al. Expires August 2003 [Page 39] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 In case each AU has the same size, the found maxDisplacement value=20 over-estimates the de-interleave buffer size with three AUs.=20 However, in case of variable AU sizes the total size of any 5=20 "early" AUs stored at the same time may exceed maxDisplacement=20 times the maximum bitrate, in which case de-interleaveBufferSize must be signaled. =20 A.5 Continuous interleave A.5.1 Introduction In continuous interleave, once the scheme is 'primed', the number=20 of AUs in a packet exceeds the 'stride' (the distance between=20 them). This shortens the buffering needed, smooths the data-flow,=20 and gives slightly larger packets -- and thus lower overhead -- for the same interleave. For example, here is a continuous interleave=20 also over a stride of 3 AUs, but with 4 AUs per packet, for a run=20 of 20 AUs. This shows both how the scheme 'starts up' and how it=20 finishes. Once again, the example assumes fixed time duration per Access Unit. Packet Time-stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0 0 1 T[1] 1 4 0 2 2 T[2] 2 5 8 0 2 2 3 T[3] 3 6 9 12 0 2 2 2 4 T[7] 7 10 13 16 0 2 2 2 5 T[11] 11 14 17 20 0 2 2 2 6 T[15] 15 18 0 2 7 T[19] 19 0 In this example the AU-Index is present in the first AU-header and=20 coded with the value 0, as required for AUs with a fixed duration.=20 To reconstruct the original order, the RTP time stamp and the=20 AU-Index-delta (coded with the value 2) are used. See also 3.2.3.2. Note that this example has RTP time-stamps in increasing order. A.5.2 Determining the de-interleave buffer size For this example the de-interleave buffer size can be derived from=20 figure 10. The maximum number of "early" AUs is three. If the AUs=20 are of constant size, then this value equals 3 times the AU size.=20 Compared to the example in A.2, for constant size AUs the=20 de-interleave buffer size is reduced from 4 to 3 times the AU size, while maintaining the same 'stride'. van der Meer et al. Expires August 2003 [Page 40] =0C RFC xxxx Transport of MPEG-4 Elementary Streams February 2003 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- - - - 4 - - 4 8 - - 8 12 - - 5 9 "Early" AUs 8 12 =20 Figure 10: Storage of "early" AUs in the de-interleave buffer per=20 interleaved AU. A.5.3 Determining the maximum displacement For this example the maximum displacement has a value of 5 AU=20 periods. See figure 11. Compared to the example in A.2, the maximum displacement does not decrease, though in fact less de-interleave=20 buffering is required.=20 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Earliest not yet =20 present AU - - 2 - 3 3 - - 7 7 - - 11 11 =20 Figure 11: The earliest not yet present AU for each AU in the=20 interleaving pattern. van der Meer et al. Expires August 2003 [Page 41] --=_mixed 000B64EDC1256CD9_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 05:40:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00357 for ; Wed, 26 Feb 2003 05:40:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAnnM29668 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 05:49:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAdrp29072; Wed, 26 Feb 2003 05:39:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAWRp28099 for ; Wed, 26 Feb 2003 05:32:27 -0500 Received: from dns1.tilab.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00007; Wed, 26 Feb 2003 05:22:26 -0500 (EST) Received: from iowa.cselt.it (iowa.cselt.it [163.162.4.49]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HAW00J0WVLHUA@dns1.cselt.it>; Wed, 26 Feb 2003 11:24:53 +0100 (MET) Received: from iowa.cselt.it ([163.162.4.49]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 11:27:11 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 11:27:11 +0100 Date: Wed, 26 Feb 2003 11:27:11 +0100 From: Franceschini Guido Subject: RE: [AVT] New draft-ietf-avt-mpeg4-simple-07 To: jan.vandermeer@philips.com, avt@ietf.org Cc: avt-admin@ietf.org Message-id: <3737D9839ED3D3408C73611BDA907A0419ED0A@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C2DD81.9F544291" Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: [AVT] New draft-ietf-avt-mpeg4-simple-07 Thread-Index: AcLdQyA9gY5bsFJuTrGFzCQg3ykaPgAPUOSQ content-class: urn:content-classes:message X-OriginalArrivalTime: 26 Feb 2003 10:27:11.0717 (UTC) FILETIME=[9F8D9150:01C2DD81] 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DD81.9F544291 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jan, =20 unfortunately I have to disagree with the text you modified with respect = to Colin's text. I am fine with supporting early implementations, but the wording used = is, IMHO, not suitable. More specifically you wrote: =20 If the "constantDuration" parameter is not present, then Access=20 Units are assumed to have a variable duration, unless the AU-Index=20 is present and coded with the value 0 in each RTP packet.=20 =20 How can a receiver implement the rule above? Should it observe 1, 10, = 1000 or infinite packets before determining that the "AU-Index is = present and coded with the value 0 in each RTP packet" ? =20 What is the exact legacy that you want to support ? Maybe there is a = different mechanism to support it. For example, a specific mode = definition might IMPLY a specific "constantDuration" value, without = writing this explicitely in the SDP. Best regards Guido Franceschini=20 TILAB - Multimedia Division=20 Via G.Reiss Romoli 274=20 I-10148 Torino, Italy=20 tel + 39 011 228 6137=20 fax + 39 011 228 6299=20 -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Wednesday, February 26, 2003 3:03 AM To: avt@ietf.org Cc: avt-admin@ietf.org Subject: [AVT] New draft-ietf-avt-mpeg4-simple-07 Dear all,=20 This is to let you know that I just submitted = draft-ietf-avt-mpeg4-simple-07 for upload to the IETF. For your = convenience I attached the draft to this email.=20 Compared to -06 there are several editorial improvements. In addition, = all comments provided by Colin are incorporated with one small = difference. Colin suggested the following text on interleaving in = 3.2.3.2 (page 17):=20 If the "constantDuration" parameter is not present, then Access = Units are assumed to have a variable duration. In this case, the = transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of the first AU in the RTP packet. ...=20 I changed this to the following text, in order to accomodate "early = implementations" that do not use the constantDuration parameter when = transmitting constant duration AUs.=20 If the "constantDuration" parameter is not present, then Access=20 Units are assumed to have a variable duration, unless the AU-Index=20 is present and coded with the value 0 in each RTP packet. When=20 transmitting Access Units of variable duration, then the=20 "constantDuration" parameter MUST NOT be present, and the=20 transmitter MUST use the AU-Index to encode the index information=20 required for re-ordering, and the receiver MUST use that value to=20 determine the index of each AU in the RTP packet. ...=20 From my perspective the document is ready now. All known comments are = incorporated (Colin and Steve thanks for your help !) and therefore I = think we are done, unless any further issues are identified.=20 Best regards / Groeten, Jan=20 ----------------------------------------------------------- Jan van der Meer Philips - MP4Net Prof Holstlaan 4 Building WDB-1 P.O. Box 80021 5600 JZ Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C2DD81.9F544291 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jan,
 
unfortunately I have to disagree with the text you = modified with=20 respect to Colin's text.
I am=20 fine with supporting early implementations, but the wording used is, = IMHO, not=20 suitable. More specifically you wrote:
 
   If the "constantDuration" parameter is not = present,=20 then Access
   Units are assumed to have a variable = duration,=20 unless the AU-Index
   is=20 present and coded with the value 0 in each RTP packet. =
 
How=20 can a receiver implement the rule above? Should it observe 1, 10, 1000 = or=20 infinite packets before determining that the "AU-Index is present and = coded with=20 the value 0 in each RTP packet" ?
 
What=20 is the exact legacy that you want to support ? Maybe there is a = different=20 mechanism to support it. For example, a specific mode definition might = IMPLY a=20 specific "constantDuration" value, without writing this explicitely in = the=20 SDP.

Best regards

Guido Franceschini =

TILAB - Multimedia = Division=20
Via G.Reiss Romoli 274
I-10148 Torino, Italy
tel + 39 011 = 228 6137=20
fax + 39 011 228 6299

-----Original Message-----
From: = jan.vandermeer@philips.com=20 [mailto:jan.vandermeer@philips.com]
Sent: Wednesday, = February 26,=20 2003 3:03 AM
To: avt@ietf.org
Cc:=20 avt-admin@ietf.org
Subject: [AVT] New=20 draft-ietf-avt-mpeg4-simple-07


Dear all,

This is to let=20 you know that I just submitted draft-ietf-avt-mpeg4-simple-07 for = upload to=20 the IETF. For your convenience I attached the draft to this = email.=20

Compared to -06 there are = several=20 editorial improvements. In addition, all comments provided by Colin = are=20 incorporated with one small difference. Colin suggested the following = text on=20 interleaving in 3.2.3.2 (page 17):

    If the "constantDuration" parameter is not = present, then=20 Access Units
   are assumed to have a variable duration. = In this=20 case, the transmitter
   MUST use the AU-Index to encode = the=20 index information required for
   re-ordering, and the = receiver=20 MUST use that value to determine the
   index of the = first AU in=20 the RTP packet. ...

I = changed this=20 to the following text, in order to accomodate "early implementations" = that do=20 not use the constantDuration parameter when transmitting constant = duration=20 AUs.

  =  If the=20 "constantDuration" parameter is not present, then Access =
   Units are assumed to have a = variable=20 duration, unless the AU-Index
   is present and coded with the value 0 in each = RTP packet.=20 When
  =  transmitting=20 Access Units of variable duration, then the
   "constantDuration" = parameter MUST NOT=20 be present, and the
 =20  transmitter MUST use the AU-Index to encode the index = information=20
   required = for=20 re-ordering, and the receiver MUST use that value to
   determine the index of each = AU in the=20 RTP packet. ...

From = my=20 perspective the document is ready now. All known comments are = incorporated=20 (Colin and Steve thanks for your help !) and therefore I think we are = done,=20 unless any further issues are identified.

Best regards / Groeten,

Jan =



-----------------------------------------------------------<= BR>Jan=20 van der Meer
Philips - MP4Net
Prof Holstlaan 4
Building = WDB-1
P.O.=20 Box 80021
5600 JZ Eindhoven
The Netherlands
Phone +31 402 735 = 774
Fax +31 402 735 = 545

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
CONFIDENTIALITY NOTICE
This message and its = attachments are addressed solely to the persons
above and may contain = confidential information. If you have received
the message in error, = be informed that any use of the content hereof
is prohibited. Please = return it immediately to the sender and delete
the message. Should = you have any questions, please contact us by
replying to = MailAdmin@tilab.com. Thank = you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C2DD81.9F544291-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 07:30:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02419 for ; Wed, 26 Feb 2003 07:30:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QCePP04639 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 07:40:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCUUp03496; Wed, 26 Feb 2003 07:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCSMp03412 for ; Wed, 26 Feb 2003 07:28:22 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02286 for ; Wed, 26 Feb 2003 07:18:21 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 4F49D1E0AE; Wed, 26 Feb 2003 07:22:17 -0500 (EST) Received: from research.att.com (brow0005.research.att.com [135.207.56.5]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA07734; Wed, 26 Feb 2003 07:22:06 -0500 (EST) Message-ID: <3E5CB17B.2010805@research.att.com> Date: Wed, 26 Feb 2003 07:22:19 -0500 From: Eric Cheung Organization: AT&T Labs Research User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: schulzrinne@cs.columbia.edu, scott.petrack@edial.com Cc: avt@ietf.org, msafawi@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Question on RTP sequence number in RFC2833 and bis-02 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Henning, Scott Want to clarify a fine point. In RFC2833: If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. Q1: For a device conforming to RFC2833, should the RTP sequence number in the 3 packets be incremented, or should they be the same? In RFC2833bis-02, this seems to be clarified: If an event has ended and there has been no new event in the last interval, the event SHOULD be retransmitted three times at the interval used by the source for updates. In all cases, the RTP sequence number MUST be incremented by one in each RTP packet. Q2: Can you confirm that if a device conforms to bis-02, the sequence number in the 3 packets will be monotonically increasing? Q3: In writing this, I realize that I am not sure whether there should be 4 packets (1 original transmission + 3 retransmission) or 3 packets. Can you clarify this? Sorry for the nit-picking, but when testing it seems many devices do many different things when it comes to 2833. Thanks Eric _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 07:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02626 for ; Wed, 26 Feb 2003 07:41:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QCpBO05013 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 07:51:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCn7p04951; Wed, 26 Feb 2003 07:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCmUp04922 for ; Wed, 26 Feb 2003 07:48:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02595 for ; Wed, 26 Feb 2003 07:38:30 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QCgNYf025656; Wed, 26 Feb 2003 13:42:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 13:42:23 +0100 Message-ID: <034BEFD03799D411A59F00508BDF754602BF4176@esealnt448.al.sw.ericsson.se> From: "Magnus Westerlund (EAB)" To: "'Alan Clark '" , "'''Timur Friedman' ' '" Cc: "'avt@ietf.org '" Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Date: Wed, 26 Feb 2003 13:37:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QCmUp04923 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Alan, Comments below. >To my knowledge the necessary signalling is in place for all other types of RTCP reporting. The AVPF defines SDP attribute that allows control of the usage of the formats within that proposal. So I don´t think arguing that it is a general problem would lessen the need for SDP attributes in regards to XR formats. [Alan] I don't recall seeing any explicit means of turning RTCP reports on and off and was only able to locate an expired draft on using SDP to negotiate RTCP bandwidth. It would be helpful if you could provide some references to existing signalling protocols. [Magnus] The draft-ietf-avt-rtcp-bw-05.txt is not expired. It is actually approved and simple stuck in the RFC-editor queue on the RTP draft. This provides possibility to assign the bandwidth to active senders and receivers only. >By supporting SDP you support the basic signalling that are currenlty in use by the most common real-time media applications using RTP/RTCP. SIP uses SDP, RTSP uses SDP. [Alan] How about H.323? [Magnus] H.323 is the concern of ITU. It they are going to use XR format does they not also need to standardize it, so that it can be used? At the same time they the can design the necessary signalling extensions. This is after all the IETF and we are not able to go into other standard bodies turf directly. However we need to concern ourself with consitencies to our own protocols and when necessary also other bodies works. In my opinion we need to address SDP as it is will be useful for both SIP and RTSP. Best Regards Magnus Westerlund _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 10:25:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11120 for ; Wed, 26 Feb 2003 10:25:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QFZKJ17739 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 10:35:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFRpp17204; Wed, 26 Feb 2003 10:27:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFQkp17157 for ; Wed, 26 Feb 2003 10:26:46 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10508 for ; Wed, 26 Feb 2003 10:16:42 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h1QFIWC03031; Wed, 26 Feb 2003 10:18:34 -0500 Message-Id: <200302261518.h1QFIWC03031@chiron.nge.isi.edu> To: Franceschini Guido cc: jan.vandermeer@philips.com, avt@ietf.org Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 In-Reply-To: Your message of "Wed, 26 Feb 2003 11:27:11 +0100." <3737D9839ED3D3408C73611BDA907A0419ED0A@EXC2K05A.cselt.it> Date: Wed, 26 Feb 2003 10:18:32 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Guido, --> Franceschini Guido writes: >Jan, > >unfortunately I have to disagree with the text you modified with respect >to Colin's text. >I am fine with supporting early implementations, but the wording used >is, IMHO, not suitable. More specifically you wrote: > > If the "constantDuration" parameter is not present, then Access > Units are assumed to have a variable duration, unless the AU-Index > is present and coded with the value 0 in each RTP packet. > >How can a receiver implement the rule above? Should it observe 1, 10, >1000 or infinite packets before determining that the "AU-Index is >present and coded with the value 0 in each RTP packet" ? One packet is sufficient. If the Access Units have variable duration, the AU-Index will never be zero, if they have fixed duration it will always be zero. The rest of the paragraph you quoted makes this explicit. >What is the exact legacy that you want to support ? Maybe there is a >different mechanism to support it. For example, a specific mode >definition might IMPLY a specific "constantDuration" value, without >writing this explicitely in the SDP. Not if it wishes to comply with this specification. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 10:37:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12114 for ; Wed, 26 Feb 2003 10:37:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QFkec19579 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 10:46:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFk8p19560; Wed, 26 Feb 2003 10:46:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFjZp19530 for ; Wed, 26 Feb 2003 10:45:35 -0500 Received: from dns1.tilab.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12019 for ; Wed, 26 Feb 2003 10:35:30 -0500 (EST) Received: from iowa.cselt.it (iowa.cselt.it [163.162.4.49]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HAX0034TA3ACX@dns1.cselt.it> for avt@ietf.org; Wed, 26 Feb 2003 16:37:58 +0100 (MET) Received: from iowa.cselt.it ([163.162.4.49]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 16:40:15 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 16:40:15 +0100 Date: Wed, 26 Feb 2003 16:40:15 +0100 From: Franceschini Guido Subject: RE: [AVT] New draft-ietf-avt-mpeg4-simple-07 To: Colin Perkins Cc: jan.vandermeer@philips.com, avt@ietf.org Message-id: <3737D9839ED3D3408C73611BDA907A0419ED0E@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Importance: normal Priority: normal Thread-Topic: [AVT] New draft-ietf-avt-mpeg4-simple-07 Thread-Index: AcLdrAy17F/ml+juSPunQabBWu/ROQAAIKfw content-class: urn:content-classes:message X-OriginalArrivalTime: 26 Feb 2003 15:40:15.0951 (UTC) FILETIME=[5BD435F0:01C2DDAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QFjZp19531 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Colin, your reply makes me very happy. I'd love to see this draft becoming an RFC. So apparently it is already specified that AU-Index will never be 0 when "useful". That is just perfect -I was assuming that 0 was an acceptable coded value for the variable duration case-. I failed however to find such a statement. Could you or Jan point me to it ? Thanks again Guido -----Original Message----- From: Colin Perkins [mailto:csp@isi.edu] Sent: Wednesday, February 26, 2003 4:19 PM To: Franceschini Guido Cc: jan.vandermeer@philips.com; avt@ietf.org Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 Guido, --> Franceschini Guido writes: >Jan, > >unfortunately I have to disagree with the text you modified with respect >to Colin's text. >I am fine with supporting early implementations, but the wording used >is, IMHO, not suitable. More specifically you wrote: > > If the "constantDuration" parameter is not present, then Access > Units are assumed to have a variable duration, unless the AU-Index > is present and coded with the value 0 in each RTP packet. > >How can a receiver implement the rule above? Should it observe 1, 10, >1000 or infinite packets before determining that the "AU-Index is >present and coded with the value 0 in each RTP packet" ? One packet is sufficient. If the Access Units have variable duration, the AU-Index will never be zero, if they have fixed duration it will always be zero. The rest of the paragraph you quoted makes this explicit. >What is the exact legacy that you want to support ? Maybe there is a >different mechanism to support it. For example, a specific mode >definition might IMPLY a specific "constantDuration" value, without >writing this explicitely in the SDP. Not if it wishes to comply with this specification. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 10:48:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12801 for ; Wed, 26 Feb 2003 10:48:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QFwJ320144 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 10:58:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFv7p20125; Wed, 26 Feb 2003 10:57:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFu3p20084 for ; Wed, 26 Feb 2003 10:56:03 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12736 for ; Wed, 26 Feb 2003 10:45:58 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h1QFnpq03764; Wed, 26 Feb 2003 10:49:51 -0500 Message-Id: <200302261549.h1QFnpq03764@chiron.nge.isi.edu> To: Franceschini Guido cc: jan.vandermeer@philips.com, avt@ietf.org Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 In-Reply-To: Your message of "Wed, 26 Feb 2003 16:40:15 +0100." <3737D9839ED3D3408C73611BDA907A0419ED0E@EXC2K05A.cselt.it> Date: Wed, 26 Feb 2003 10:49:51 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Guido, The paragraph you quoted continues with "When transmitting Access Units of variable duration ... the transmitter MUST use the AU-Index to encode the index information required for reordering..." which implies non-zero values to my reading. Colin --> Franceschini Guido writes: >Colin, > >your reply makes me very happy. I'd love to see this draft becoming an RFC. >So apparently it is already specified that AU-Index will never be 0 when >"useful". That is just perfect -I was assuming that 0 was an acceptable >coded value for the variable duration case-. I failed however to find such >a statement. Could you or Jan point me to it ? > >Thanks again >Guido > >-----Original Message----- >From: Colin Perkins [mailto:csp@isi.edu] >Sent: Wednesday, February 26, 2003 4:19 PM >To: Franceschini Guido >Cc: jan.vandermeer@philips.com; avt@ietf.org >Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 > > >Guido, > >--> Franceschini Guido writes: >>Jan, >> >>unfortunately I have to disagree with the text you modified with respect >>to Colin's text. >>I am fine with supporting early implementations, but the wording used >>is, IMHO, not suitable. More specifically you wrote: >> >> If the "constantDuration" parameter is not present, then Access >> Units are assumed to have a variable duration, unless the AU-Index >> is present and coded with the value 0 in each RTP packet. >> >>How can a receiver implement the rule above? Should it observe 1, 10, >>1000 or infinite packets before determining that the "AU-Index is >>present and coded with the value 0 in each RTP packet" ? > >One packet is sufficient. If the Access Units have variable duration, the >AU-Index will never be zero, if they have fixed duration it will always be >zero. The rest of the paragraph you quoted makes this explicit. > >>What is the exact legacy that you want to support ? Maybe there is a >>different mechanism to support it. For example, a specific mode >>definition might IMPLY a specific "constantDuration" value, without >>writing this explicitely in the SDP. > >Not if it wishes to comply with this specification. > >Colin >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > > >==================================================================== >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons >above and may contain confidential information. If you have received >the message in error, be informed that any use of the content hereof >is prohibited. Please return it immediately to the sender and delete >the message. Should you have any questions, please contact us by >replying to MailAdmin@tilab.com. Thank you >==================================================================== >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 15:47:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24541 for ; Wed, 26 Feb 2003 15:47:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QKv4e09485 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 15:57:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKudp09475; Wed, 26 Feb 2003 15:56:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKsZp09376 for ; Wed, 26 Feb 2003 15:54:35 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24453 for ; Wed, 26 Feb 2003 15:44:25 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h1QKmKL06379 for ; Wed, 26 Feb 2003 15:48:20 -0500 Message-Id: <200302262048.h1QKmKL06379@chiron.nge.isi.edu> To: avt@ietf.org Subject: Re: [AVT] Meeting in San Francisco In-Reply-To: Your message of "Mon, 10 Feb 2003 09:42:34 EST." <200302101442.h1AEgYdw004067@purple.nge.isi.edu> Date: Wed, 26 Feb 2003 15:48:20 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Colin Perkins writes: >The AVT working group is scheduled for two slots at the 56th IETF meeting >in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am >on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These >dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL. Note that the latest version of the agenda has AVT scheduled on Wednesday, 19th March at 13:00-15:00 and Thursday, 20th March at 09:00-11:30. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Feb 26 17:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29870 for ; Wed, 26 Feb 2003 17:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QMdWu17892 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 17:39:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMcXp17869; Wed, 26 Feb 2003 17:38:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMb1p17145 for ; Wed, 26 Feb 2003 17:37:01 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29835 for ; Wed, 26 Feb 2003 17:26:48 -0500 (EST) From: jan.vandermeer@philips.com Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl4.philips.com (Postfix) with ESMTP id 9B769A3DE1; Wed, 26 Feb 2003 23:30:42 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id XAA25394; Wed, 26 Feb 2003 23:30:42 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id XAA26552; Wed, 26 Feb 2003 23:30:41 +0100 (MET) To: Franceschini Guido Cc: avt@ietf.org, Colin Perkins Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Feb 2003 23:28:41 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 26/02/2003 23:28:54, Serialize complete at 26/02/2003 23:28:54 Content-Type: multipart/alternative; boundary="=_alternative 007BA2BAC1256CD9_=" 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 007BA2BAC1256CD9_= Content-Type: text/plain; charset="us-ascii" Guido, I agree with Colin to a large extend. We are talking about the case of interleaving where we have a certain interleaving pattern. In case of variable duration, any AU-index value (including zero) only occurs again after the applied interleaving pattern "passed sufficiently". If there are two subsequent RTP packets with the same AU-index value, then this is clearly one of the roll-over problems that the referenced rule states "MUST NOT" occur. But note that the value zero (as any other value) may occur once in a while, but that the AU-index value always differs in subsequent RTP packets in case of variable duration. Which means that the answer to your original question is that you don't need to look further than two subsequent RTP packets. Best regards, Jan Colin Perkins 2003-02-26 04:49 PM To: Franceschini Guido cc: Jan vanderMeer/EHV/CE/PHILIPS@EMEA3 avt@ietf.org Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 Classification: Guido, The paragraph you quoted continues with "When transmitting Access Units of variable duration ... the transmitter MUST use the AU-Index to encode the index information required for reordering..." which implies non-zero values to my reading. Colin --> Franceschini Guido writes: >Colin, > >your reply makes me very happy. I'd love to see this draft becoming an RFC. >So apparently it is already specified that AU-Index will never be 0 when >"useful". That is just perfect -I was assuming that 0 was an acceptable >coded value for the variable duration case-. I failed however to find such >a statement. Could you or Jan point me to it ? > >Thanks again >Guido > >-----Original Message----- >From: Colin Perkins [mailto:csp@isi.edu] >Sent: Wednesday, February 26, 2003 4:19 PM >To: Franceschini Guido >Cc: jan.vandermeer@philips.com; avt@ietf.org >Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07 > > >Guido, > >--> Franceschini Guido writes: >>Jan, >> >>unfortunately I have to disagree with the text you modified with respect >>to Colin's text. >>I am fine with supporting early implementations, but the wording used >>is, IMHO, not suitable. More specifically you wrote: >> >> If the "constantDuration" parameter is not present, then Access >> Units are assumed to have a variable duration, unless the AU-Index >> is present and coded with the value 0 in each RTP packet. >> >>How can a receiver implement the rule above? Should it observe 1, 10, >>1000 or infinite packets before determining that the "AU-Index is >>present and coded with the value 0 in each RTP packet" ? > >One packet is sufficient. If the Access Units have variable duration, the >AU-Index will never be zero, if they have fixed duration it will always be >zero. The rest of the paragraph you quoted makes this explicit. > >>What is the exact legacy that you want to support ? Maybe there is a >>different mechanism to support it. For example, a specific mode >>definition might IMPLY a specific "constantDuration" value, without >>writing this explicitely in the SDP. > >Not if it wishes to comply with this specification. > >Colin >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > > >==================================================================== >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons >above and may contain confidential information. If you have received >the message in error, be informed that any use of the content hereof >is prohibited. Please return it immediately to the sender and delete >the message. Should you have any questions, please contact us by >replying to MailAdmin@tilab.com. Thank you >==================================================================== >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt --=_alternative 007BA2BAC1256CD9_= Content-Type: text/html; charset="us-ascii"
Guido,

I agree with Colin to a large extend. We are talking about the case of interleaving where we have a certain interleaving pattern. In case of variable duration, any AU-index value (including zero) only occurs again after the applied interleaving pattern "passed sufficiently". If there are two subsequent RTP packets with the same AU-index value, then this is clearly one of the roll-over problems that the referenced rule states "MUST NOT" occur.

But note that the value zero (as any other value) may occur once in a while, but that the AU-index value always differs in subsequent RTP packets in case of variable duration. Which means that the answer to your original question is that you don't need to look further than two subsequent RTP packets.

Best regards,

Jan







Colin Perkins <csp@isi.edu>

2003-02-26 04:49 PM

       
        To:        Franceschini Guido <Guido.Franceschini@TILAB.COM>
        cc:        Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
avt@ietf.org
        Subject:        Re: [AVT] New draft-ietf-avt-mpeg4-simple-07

        Classification:        




Guido,

The paragraph you quoted continues with "When transmitting Access Units
of variable duration ... the transmitter MUST use the AU-Index to encode
the index information required for reordering..." which implies non-zero
values to my reading.

Colin



--> Franceschini Guido writes:
>Colin,
>
>your reply makes me very happy. I'd love to see this draft becoming an RFC.
>So apparently it is already specified that AU-Index will never be 0 when
>"useful". That is just perfect -I was assuming that 0 was an acceptable
>coded value for the variable duration case-.  I failed however to find such
>a statement. Could you or Jan point me to it ?
>
>Thanks again
>Guido
>
>-----Original Message-----
>From: Colin Perkins [mailto:csp@isi.edu]
>Sent: Wednesday, February 26, 2003 4:19 PM
>To: Franceschini Guido
>Cc: jan.vandermeer@philips.com; avt@ietf.org
>Subject: Re: [AVT] New draft-ietf-avt-mpeg4-simple-07
>
>
>Guido,
>
>--> Franceschini Guido writes:
>>Jan,
>>
>>unfortunately I have to disagree with the text you modified with respect
>>to Colin's text.
>>I am fine with supporting early implementations, but the wording used
>>is, IMHO, not suitable. More specifically you wrote:
>>
>>   If the "constantDuration" parameter is not present, then Access
>>   Units are assumed to have a variable duration, unless the AU-Index
>>   is present and coded with the value 0 in each RTP packet.
>>
>>How can a receiver implement the rule above? Should it observe 1, 10,
>>1000 or infinite packets before determining that the "AU-Index is
>>present and coded with the value 0 in each RTP packet" ?
>
>One packet is sufficient.  If the Access Units have variable duration, the
>AU-Index will never be zero, if they have fixed duration it will always be
>zero. The rest of the paragraph you quoted makes this explicit.
>
>>What is the exact legacy that you want to support ? Maybe there is a
>>different mechanism to support it. For example, a specific mode
>>definition might IMPLY a specific "constantDuration" value, without
>>writing this explicitely in the SDP.
>
>Not if it wishes to comply with this specification.
>
>Colin
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>====================================================================
>CONFIDENTIALITY NOTICE
>This message and its attachments are addressed solely to the persons
>above and may contain confidential information. If you have received
>the message in error, be informed that any use of the content hereof
>is prohibited. Please return it immediately to the sender and delete
>the message. Should you have any questions, please contact us by
>replying to MailAdmin@tilab.com. Thank you
>====================================================================
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 007BA2BAC1256CD9_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 04:22:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18181 for ; Fri, 28 Feb 2003 04:22:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9Wpu11202 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 04:32:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9WJp11165; Fri, 28 Feb 2003 04:32:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9UQp11093 for ; Fri, 28 Feb 2003 04:30:26 -0500 Received: from node24.neomagic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18135 for ; Fri, 28 Feb 2003 04:19:32 -0500 (EST) Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h1SAGkwl008586 for ; Fri, 28 Feb 2003 02:16:46 -0800 Received: from neomagic.com ([192.168.31.247]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h1SANHCV010696 for ; Fri, 28 Feb 2003 02:23:18 -0800 Message-ID: <3E5F2CE9.7010203@neomagic.com> Date: Fri, 28 Feb 2003 15:03:29 +0530 From: B Prashanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Multicast RTP session. 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi I am new in this list and am working on developing application layer stacks for streaming and telephony application. I had a very fundamental question in this regard. How does RTP handle incoming packets coming from number of sources on a multicast port? Is the 1. Are the packets (coming from different SSRCs) given to the application using the stack in the order of their arrival. OR, 2. Seperate jitter buffers would be needed to be maintained in the RTP stack for each of the SSRCs (senders of RTP data) so that the jitter from each of the senders is removed individually and then the payload be given to the application that is using this stack. Thanks in advance, -- Prashanth _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 07:26:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22876 for ; Fri, 28 Feb 2003 07:26:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCaje22332 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 07:36:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCaHp22273; Fri, 28 Feb 2003 07:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCYJp22182 for ; Fri, 28 Feb 2003 07:34:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22173; Fri, 28 Feb 2003 07:23:20 -0500 (EST) Message-Id: <200302281223.HAA22173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:23:20 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-mpeg4-simple-07.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Transport of MPEG-4 Elementary Streams Author(s) : J. Van der Meer, d. Mackie, V. Swaminathan, D. Singer, P. Gentric Filename : draft-ietf-avt-mpeg4-simple-07.txt Pages : 41 Date : 2003-2-27 The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mpeg4-simple-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-mpeg4-simple-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mpeg4-simple-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mpeg4-simple-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mpeg4-simple-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132454.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 08:39:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27514 for ; Fri, 28 Feb 2003 08:39:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDo4t29100 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 08:50:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDnbp29032; Fri, 28 Feb 2003 08:49:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDmkp28980 for ; Fri, 28 Feb 2003 08:48:46 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27453 for ; Fri, 28 Feb 2003 08:37:45 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HB000G2ITZHWX@panasonic.de> for avt@ietf.org; Fri, 28 Feb 2003 14:40:30 +0100 (MET) Date: Fri, 28 Feb 2003 14:40:31 +0100 From: Jose Rey To: "Avt@Ietf. Org" Cc: Colin Perkins , "Casner@Acm. Org" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [AVT] draft-ietf-avt-rtp-retransmission-06.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, we just submitted the hopefully final revision of the retransmission draft. Since the -05 draft there are only minor editorial changes, as commented on the list. We would like to ask the WG chairs to consider it for WGLC and you all to give it a final check, Until publication, the draft can be reached under: http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtp-retransmission- 06.txt Thanks, Jose Rey Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Langen, Germany - rey@panasonic.de www.pel.panasonic.de - Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 -- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 09:59:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00703 for ; Fri, 28 Feb 2003 09:59:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SFA8V02606 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 10:10:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SF9hp02548; Fri, 28 Feb 2003 10:09:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SF8np02522 for ; Fri, 28 Feb 2003 10:08:49 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00661 for ; Fri, 28 Feb 2003 09:57:47 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h1SF1fpc003597; Fri, 28 Feb 2003 10:01:41 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302281501.h1SF1fpc003597@purple.nge.isi.edu> To: B Prashanth cc: avt@ietf.org Subject: Re: [AVT] Multicast RTP session. In-Reply-To: Your message of "Fri, 28 Feb 2003 15:03:29 +0530." <3E5F2CE9.7010203@neomagic.com> Date: Fri, 28 Feb 2003 10:01:41 -0500 From: Colin Perkins 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, --> B Prashanth writes: >I am new in this list and am working on developing application layer >stacks for streaming and telephony application. I had a very fundamental >question in this regard. How does RTP handle incoming packets coming >from number of sources on a multicast port? Is the >1. Are the packets (coming from different SSRCs) given to the >application using the stack in the order of their arrival. This is a valid approach, if the jitter buffer and playout code is part of the application. The RTP library I wrote as part of the Robust-Audio Tool (http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/) works like this. It gives you a very simple RTP library, leaving a lot to the application. >OR, >2. Seperate jitter buffers would be needed to be maintained in the RTP >stack for each of the SSRCs (senders of RTP data) so that the jitter >from each of the senders is removed individually and then the payload be >given to the application that is using this stack. This is a valid approach, if the playout buffer is managed by the RTP library. The resulting application will be simple, wrapped around a more complex playout framework provided by the RTP library. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 10:14:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01118 for ; Fri, 28 Feb 2003 10:14:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SFOt403362 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 10:24:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFOAp03253; Fri, 28 Feb 2003 10:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFI9p03000 for ; Fri, 28 Feb 2003 10:18:09 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00971 for ; Fri, 28 Feb 2003 10:07:07 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h1SFAtpc003927; Fri, 28 Feb 2003 10:10:55 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302281510.h1SFAtpc003927@purple.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Fri, 28 Feb 2003 10:10:55 -0500 From: Colin Perkins Subject: [AVT] Working group last call: draft-ietf-avt-mpeg4-simple-07.txt 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is to announce a working group last call on the RTP Payload Format for Transport of MPEG-4 Elementary Streams (draft-ietf-avt-mpeg4-simple-07.txt). Please send any final comments on this draft to the mailing list by 7th March 2003. If no substantive technical comments are received by that time, we propose to submit this draft to the IESG for publication as a proposed standard RFC. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 19:56:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18926 for ; Fri, 28 Feb 2003 19:56:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2115BQ08844 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 20:05:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2114mp08775; Fri, 28 Feb 2003 20:04:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2113jp08714 for ; Fri, 28 Feb 2003 20:03:45 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18855 for ; Fri, 28 Feb 2003 19:54:21 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h210o3L22884 for ; Sat, 1 Mar 2003 00:50:03 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h210vtB27932 for ; Sat, 1 Mar 2003 00:57:55 GMT Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003022816585620316 for ; Fri, 28 Feb 2003 16:58:56 -0800 Received: from fmsmsx405.amr.corp.intel.com ([132.233.42.209]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Feb 2003 16:56:19 -0800 content-class: urn:content-classes:message Date: Fri, 28 Feb 2003 16:56:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Thread-Topic: RFC2833: Event Vs. transport mechanism Thread-Index: AcLfjnEyp/2dgq1UTU6jWLoHr0/fig== From: "Prabhu, Raghavendra" To: X-OriginalArrivalTime: 01 Mar 2003 00:56:19.0279 (UTC) FILETIME=[5EBF8DF0:01C2DF8D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2113jp08715 Subject: [AVT] RFC2833: Event Vs. transport mechanism 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I understand that application scenario largely determines how one would want to do things ... but I was wondering if there is a common denominator between these. The question is raised by having a 20ms DTMF tone on the input to a media gateway from PSTN. Let's say detectors these days can take < 20ms to detect, and hence it is possible to start sending rfc2833 packets for even such a short tone (considering the minimum on time in most standards is 40ms). Questions: 1. Is it always required to terminate any RFC2833 packet stream with an End bit ? I think the answer is yes, since otherwise the tone can be played out for longer time than actual. 2. 23ms or less DTMF tones are supposed to be rejected according to Q.24 Annex A(AT&T). So in theory, no RFC2833 packet should have been generated at all unless it is confirmed to be a valid event as defined by Q.24. Is this a correct assessment ?? This statement implies that an event is defined as something that MUST adhere to Q.24 (or) any other standard. I don't recall seeing this being implied anywhere in the rfc2833. 3. If RFC2833 is simply a transport mechanism (where the gateway sends packets without validaitng with reference to any spec.), where the burden of detection is not on the media gateway connected to the incoming PSTN, but on the receiving gateway or IP phone. I don't know if this helps in reliable transport of events -- or anything else of practical use. Thanks, Raghavendra _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Feb 28 20:17:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19327 for ; Fri, 28 Feb 2003 20:17:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h211Qi610276 for avt-archive@odin.ietf.org; Fri, 28 Feb 2003 20:26:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h211QFp10259; Fri, 28 Feb 2003 20:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h211PDp10231 for ; Fri, 28 Feb 2003 20:25:13 -0500 Received: from scandium.dolby.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19317 for ; Fri, 28 Feb 2003 20:15:55 -0500 (EST) Received: from platinum.dolby.net ([172.16.33.28]) by 192.168.16.253 with In terScan Messaging Security Suite; Fri, 28 Feb 2003 17:17:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_Boundary_wqxsIPIkxS4FRVvhHiUH" Date: Fri, 28 Feb 2003 17:17:54 -0800 Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E1334BBB5C@platinum.dolby.net> X-MS-TNEF-Correlator: <5FCCC03CAF7C5C4C8E2F995E3D72E1334BBB5C@platinum.dolby .net> Thread-Topic: question: mapping dynamic RTP formats using SDP Thread-Index: AcLfkGJ0WEnGW1vPT/qmoBrk7l3evQ== From: "Hager, Todd" To: Subject: [AVT] question: mapping dynamic RTP formats using SDP 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: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --=_Boundary_wqxsIPIkxS4FRVvhHiUH Content-Type: message/rfc822 Content-Disposition: attachment; filename=originalmail.eml Received: from platinum.dolby.net ([172.16.33.28]) by 192.168.16.253 with InterScan Messaging Security Suite; Fri, 28 Feb 2003 17:17:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2DF90.62B81230" Subject: question: mapping dynamic RTP formats using SDP Date: Fri, 28 Feb 2003 17:17:54 -0800 Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E1334BBB5C@platinum.dolby.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: <5FCCC03CAF7C5C4C8E2F995E3D72E1334BBB5C@platinum.dolby.net> Thread-Topic: question: mapping dynamic RTP formats using SDP Thread-Index: AcLfkGJ0WEnGW1vPT/qmoBrk7l3evQ== From: "Hager, Todd" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DF90.62B81230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 What is the best method to define a valid encoding name for a new encoding format? =20 Regarding , I'm trying to determine the best method of choosing a value for the payload type for AC-3 in the RTP header. =20 I am proceeding under the assumption that the best course is to randomly choose a value from the dynamic range (96-127) described in (RFC 1890), and use SDP to somehow map this value to the AC-3 encoding type. I have questions regarding the SDP mapping process. =20 =20 Pages 21 and 22 in the SDP specification (RFC 2327) indicate the following mechanism to map a dynamic format ID : =20 m=3D / =20 and=20 =20 a=3Drtpmap: /[/] =20 =20 Therefore, an SDP description ought to be able to incorporate the following two lines: =20 m=3Daudio 49232 RTP/AVP 98 a=3Drtpmap:98 /48000 =20 How does the AVT group suggest I define ? Should I submit a new Internet Draft describing a full profile specifically for this format, or can I simply use the AC-3 RTP Payload document itself as the vehicle that registers a valid AV Profile encoding name? =20 Alternatively, though the current AC-3 RTP Payload draft document does not currrently define an AV RTP Profile encoding name, it does define a MIME type description for AC-3. The SDP spec allows MIME types to describe media encodings, but the wording of the SDP spec (page 22) implies that this is only intended to be used for non-RTP streams.=20 =20 Which is the most appropriate course of action: =20 1) Define a new RTP profile,=20 2) Use the AC-3 RTP payload document to define a valid encoding name for the AC-3 format, or 3) Use the defined MIME type to map a dynamic AV Profile payload type to AC-3? =20 =20 Thanks in advance, Todd Hager=20 Dolby Laboratories ------_=_NextPart_001_01C2DF90.62B81230 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjcBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMAAAAHF1ZXN0aW9uOiBtYXBwaW5n IGR5bmFtaWMgUlRQIGZvcm1hdHMgdXNpbmcgU0RQAEIRAQWAAwAOAAAA0wcCABwAEQARADYABQBV AQEggAMADgAAANMHAgAcABEAEQA2AAUAVQEBCYABACEAAAA5NUUxRkZCQ0Q1OUVENTRBQTA4NTc2 NTgwMkYzMTdBRgBcBwEDkAYAbBgAADIAAAALAAIAAQAAAAMAJgAAAAAAAwA2AAAAAABAADkAMBK4 YpDfwgEeAD0AAQAAAAEAAAAAAAAAAgFHAAEAAAA7AAAAYz1VUzthPSA7cD1kb2xieSB3b3JsZHdp ZGU7bD1QTEFUSU5VTS0wMzAzMDEwMTE3NTRaLTMzNDUwNAAAHgBwAAEAAAAwAAAAcXVlc3Rpb246 IG1hcHBpbmcgZHluYW1pYyBSVFAgZm9ybWF0cyB1c2luZyBTRFAAAgFxAAEAAAAWAAAAAcLfkGJ0 WEnGW1vPT/qmoBrk7l3evQAAHgAaDAEAAAAMAAAASGFnZXIsIFRvZGQAHgAdDgEAAAAwAAAAcXVl c3Rpb246IG1hcHBpbmcgZHluYW1pYyBSVFAgZm9ybWF0cyB1c2luZyBTRFAAAgEJEAEAAAC6EgAA thIAALRgAABMWkZ1N4oTnQMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBz ZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2fkS72Y0EG8RdhHjCO8J97Y7 Gr8OMDUR0gxgYwBQMwsJAWQzNhFgC6U0IFkQAipcDrIBkGcfYDMAIDwhRE9DVFkAUEUgSFRNTCAA UFVCTElDICJALS8vVzNDIiBEJFREITQ0LhFgVHI5AHJ0aQIgB0AiIEVOfCI+EeMf1yCACqMkjDE+ OSCQIUIkfh9wJuBFQSJEJH0xNzcgkFRJuFRMRSR9H2AO8E0HkEpzIEBlJd04NSCQL18p7yaCJX8u LyZGNg7wPOBNRVRBIAWgAjAJ8Fh0PSIF4CFDNiMwMIwuMh7QMsAwIiAj8AkHgD1HJEBFUkFU/E9S JH0rMSzwKG8gQS+/BSAxNRFgPEJPRFlHJH0e4TbvZzk2IJBE3ElWJHAf4wAhIAAAO2VzEWAfuTY0 O088Uh+bOOEoMVNQQU4xgAtgBBBgPTgwNzEOQEDAMdwtMkBwQMAysDM7Pz5vCQ4QNDggkEZPTlRc IGYA0DOQBxMgAJB6/TOQMkGbGDADsgHQAzA8BzxIaR+MRlE5owdAbCz1Jew1OtEvRBJBmUGnPp3+ ORTwLPA/wkqvPE4BwEGn7wqiS1gKgCXsMCgxIoA7G/9LXzkPOh87L05vPU9Tjz9v/0B/QY9Zn0Ov RLQKo0UfRi9/Xf9KD1L/TC9NP2VfWoUmMG5ic3ACgFz3XCf+YQFAV09PT1BfUW9Sf2g//1SfVa9d H1fPc29oj1r/XA+/dY9eL18/YJ9hr3QzVxEAAwVABAAgdGhlIGL/B5AFQEevcaIHgH/gBHB/0Bxv IAEBC4CAAGEgdl0HQGmCEAnwBaBkC4Bn/zNTfEAFsYLQgqAH4INXgH/ncaKEMQDAdD9jD2Qfb+// Zj+Ir2s/bE9tX25vi59wj/9xn3Kvc790z3ofdu93/3kP/5cfey9fj3z/fg+b34fvkN//ig+LH6M/ aR9qL4x/jY+On/+Pr6Vvkc+S35PvlP+WD5tf/5gvmT+aT7PPnG98P57fn+/4UmVnCxGFL0h2po8g IDWn2Tyx2GQjcAGALWbBC2Brcy1hdsIQACCicMKAYzMtt1AuDNAqdL9PZ8BqPrHYLCDISSdtf9By eYOigjN/McCG0IKSf+eBxb3/vwJv87GgEPBvbwCQg7GC0wpQV4Qjf+IKsHkaUGGCEXnicIQUQUMt IIALgH/T+FJUUMjfvvN/8MxABJD+LqD/og+t36Qv0U+pL6o//6tPrF/UP65/vv+wn7Gvsr//uA+0 37Xvtv/fv7kfnX+67/+7/+R/0I/Zf9Kv07/r36cP/6gf1R/WL9c/2E/uD9pv23//3I/dn96v4//g z+Hf4u/8b2/lD7ov53/oj0mCwMaAcJ8OgOZQCYC9v0h2dW7PgeN/0/6xdW1wI8J/0X+Bf3/nGjAT ABEwf6OCQCNxZPkOkGx5ylSCtctCDoF/05MG//gyZHkzYWljCzIJK7AgKPlALTEyN/IpglFzYxMQ gCDIwM1Rb+8vwF+85s3RUAZQgoBsncyldYOQgkALUSBWgyCuZYJADV/4MkMj4GbHcNODURAgIHcj sGgrUBCw/mmG4ObAFsHGoBpAw3/EjzPFmQ9wUkYh4CywOTCWKcZAFNJ1CrFTRM3gdYIxcwuAZYHw hLCG4HD/FW/4I3/gf7HLFIIxf+LNA1uDV8xyLgXhf3B2gABx/8tAgEAj0X/AFxC9dn/iHOL9HdFw Br9IdgZD/sDPv+qf//Zv7L8nv/G/8s/z3/TvKq//9w/4H/kv+j/7TwCf/W/+f///jzYvAa/mD+cf BI867yb//y/vKR8qL0JP75/wryuPLJ//La8uv0R/MN8x7zL/NA81H/86bzc/OE85X1LfO388jz2f /z6vV59Az0yfQu9D/17/Rh//Ry9IP0lPSl9Lb2EvTY9On/9Pr1C/Uc9XH1PvVP9WD2+P/1gvAr9a n1uvE6C+oBdRcpA/FMNycBCvHugcxGOAZWM6aYKAY3+ACVIbozIz/w/SXM9d32mvX/9/P4BPcTf/ WhNxz3Lfc+90/3YPdx9bz/+DX4RvhX+Gj4wfiK+Jv4rPv23GELAjIHyRx8TMwGzMIP8XgCRPazUd cAvQC1AK4MaB/m9iX2NvZHod0srwDqbMwcMYEMhQSUQgOn2/fs//gp+A757fn++eL6H/oE+hX/9t z2XPZt9n76cfpW9rH2wv/4/fbk+wf4xfcX+Oz7KfkO//kf+TD5Qft6+NL7U/tk+73/+mP6xvos+j 38LvwT/CT8Yv/5mfmq+ob6l/qo+rn8hfrb//rs+v38uPsf/Qr7Qfvj+/T//Wv7hfuW+6f7uP14+9 r9lfe9pvm6E9yU8R/5tWBpFhv+TPGh8bJuev5d/UxXAUQHcY/+iv1LYv7R/rX9TFbt8JEAogFFAT 0OzDc++/7i//6c8WCvM/8M/UxRiAC1DKcL/s7/Qf9S/3j/if3PBtCcD+bArg+j/7T9+fxx/QL8Ov /8S/BI8C3wa/y9/M783/zw//Ca/RL/bP00/UX9Vv2r/gT//Yn+K/FS/bz9zf3e/e/xX//+EfF88Y 3x5vCM8O/wVfBm//JX8jzyevHp/KL8s/Cv8MD/8NHw4vKu8QTxFfEm8uHxSP/zM/Fq8gzyHfOU8a 7xv/HQ//Hh8fLyA/O+82nnmyKO8p//9B3yaPSL9Jz0gfCf8uvy/P/zDfMe9MLzQPNR82L08/OE// VF86b0SPRZ9abz6vP79Az/9eb0LvQ/9dD14fTP9OD2ef/0qfaa9n/2kPbO8r/y0PWD//UD9RT1Jf bx9wL1WPVp9Xr/9Yv2cfY59b72YPfX9fH2Avf2E/Yk9+T2RvgB+BL0aHPT10cHCbwZ1M/b/sKmF5 hZZgYUcgdHlwZYxfDwEP/G+M7+ZtZW5jb//ncJaveUWcQY+fkK/vL5LPQ/5+iOBvY2sg+cB095bv l/971luZj5qflF+Vb+95cnlhlsGcoHLzL53Pe9b+XW2vbr+Gn2tPqJ+pr6f//06/c390j3Wfdq+s D3jPed//eu+vH30PtD9/L4lPil+6T/+Db4R/hY++T4eviL+8773//6zfre/Hf6p/yY/H38jvzM// cL9xz7gfsB+xL7I/zv/QD/+1b7Z/t4+4n8b/w3+7z8Xv/91fvv/AD8Efwi/eL8RP3///4Q/mn84f 1y/Kr8u/7a/r///v3/Dv0Q/SH9Mv1D/VT9Zf//Mf2H/Zj9qf9k/cv/tv3t//6P/qDwF/4x/kL+U/ 5k8CT0fobwQfBS8gVGikUGX0Zm8PgCzz//UP9hpG8QAgU0RQIGRlc0JjCBBwdGlvEvBvDHVnoNCP UG8gYmX5i7BibBSwFHGin/0ColD5oiBycA+wnJGPUA9gB6CUb2yPEHeiUnR3FID+bKJQE2CMTPIP +x/un++v/xsvGX8dX/bP99/47/n/HY///B/9L/4/IJ8AXyW/An8Mn/8NryvPBr8HzwjfCe8snwwP /y5vL38eXx9vJZ8b/x0PPB//Om8+TxAPER/2LyGfIq8jv/8kz0GPJu8n/zh/Kh9Mv0Hf/y1PN29O 3zxPMY8ynzOvU+8PNc9Rf1KPTTptPWF1K6JAFIA0QBAzQCBSVJBQL0FWEzA5OD9P/0BfWD8872Bf YW9fvyBfRR//Ri9HP0hPY89Kb0t/TI9m3/9Or2v/UM9a71v/cg9VD1Yf/1cvdg9ZT1pfdK+K34vl XsAPFU9tX6A/jipBQzNfEEVOQ09usE5HX/BOQU1Fgc+ln5kWd4D/fiBpYWSfZa96r2I/ie9kX/+J T2Z/Z49on2mvar+NX2zf/23vfm9wD5hvlY9zP31fmo//m593f3iPeZ+fn3u/nS+eP/+fT44vjz+o z4vPqt+pL6o//64fpQ+mH6cvqD+gP6FPol//o2+xX7Jvs3+0j7ofr1+wb/+r76z/wS+/f8NfxG9C 30Pv/5C/kc+S35Pvxp+WD5cfmC//yc+aT87vnG+8f72P1P+2n3+3r7i/uc/Vz7vv15/Yr0h7F+AT QG8YsBdTXoDbAGdachQQcNvAFCBnGLB018dvyH/JikkTQWYYkYBvf9Bvgo+Dn4Svhb+Gz89APyft D+W/yYpTaBQQbGQj53HkMGJtaRRQYSDTGKDi4EluFzByGKAUUNpEFxBmFFATVGIYAugf2+ki84Bm 8rDbsHDj4OfAoxTx8NBlY2nnwGPboNxseReR38AXYGnjMA+h6YAAdCwUAHLvr/C/yYpH+DAS8PLx aW1w+GF15nMXROvwLTP1f+kTXkHQIFBheRfQYfLQ4wDQY3VtZfPwIPNQ/YDObIcg4AAXU3Zl+ODf 4L8XQhcg+c/638mKD4Bn+PDX9AHjMPOAdtugafLQXoD7/j/pE1D3VAKPA5/JigCg5xbAXaAYEW5h AJDvnMV//86Pwg/DHw5/DM8Qr8o/y0//zF/NbxDfz4/Qn9GvE+/Tz/8ZD9Xv4A/hHx8f2i/bP9xP /91fH+/ffyG/Is8RrxK/GO//D08QXy9vLb8xnwiPCZ/Jn/8U7xX/Fw8YHzTfGj8bTyvP/x1vQA8v nyTfJeAmf0LfQ+3/Jh8nISefKK8g/ysfQo9HT78xG04/KN8p70zfQE5BQbD79BH5YGkBwPhg+YAB gPKg7GdoAXMAcHIFYACx/fN3/5oGvz5iZPSEAGbjA27+b/NgV9JYAvhh56X8sQaB//+TCB82Dzcf C0z5gFlvPmJ/81HjA+ekXm9ffzd684BNtkns4AFweffQ9MVwVqCOb/zA+JL98i4gVAGR/FNE/7D3 wn+g+FDi0OMw32djYj8+Ymey4zFv9Mb3oC8AkAuQ84ALVnP5gGJ1+/NgAYJ3+aALk/dgAXNpp9Yo PlDkYCBUAClq72M0/f0haeMj+WD4xPjxaJD4Yfvn0PQAbueg8tBsoW0x/XHn8tD4klvwbi3/knEf PmL35IAFYAvwczKfM69RDzA/73k/ek94n3x8LlGvS79UH/9VL3X/Pl9+H3xveq97v4f//4kPih84 DzkfOi87P40fPV//hY8/f0CPQZ9Q708/RM9F3/+ZL0f/SQ+cf1IvUz+Cf5h//4X/hw+kv4v/ps+n 36jvqf//ZL9lz5bPjs+P35DvrD+tT/+UH5Uvlj+XT6QvnR+af5uP/7svna+ev5/PoN+iP6NPuKt+ VwHhV3D48QGChH+2km32b+SAaiBw90H3QCXQ9AB/xCDyoAXQ96BvcSVwaHI6/6Uvpj/CP6svzM/N 387vjT//sI+xn7Kvs7/QL7Xftu+3///TT7of2G+8P71Pvl/fD8B//8GP4l+hb8RvxX/ln8vf16// 0M/R3+yv7b/uz+/fri+vP//Tn9Sv1b/Wz/If2O/Z/9sP/9wf3S/qD+L/4F/hbwEP44+/5J8EX8Nv 6B/pL/6GMXDw3kRc9cff/BNdIHdYk8mh/14iYh3rj/o/8H/xjxIPEx//FC/13/bv9//5DxRf+y/8 P//9T/5f/28AfwU/Ap8DryM//wXPBt8mjwj/Cg8LHyC2cOH+VcqBx6+FRlhXHkBZBFsX62yjDPV2 JUBpdSBhS2iz926yWFNowW3KAGIfHjRo0P8PzxDfKf8VzzivOb86zxc//xhPGV8abxt/PA8dnx6v H7//Py8h30RPI/8lDyYfSu8oP78pT04/K28sf0l/SGIzLu+/Wd1c83UgZ2hsoTVwcGcx/GR5YdHH MF1yXfUxV1kW+1b/MJY/Nz84T1FvPT9fP/9gT2FfPq8/v0DPQd9C72Kf/0UPRh9HL2W/SU9q30tv TH//TY9xf0+vUL90z+b/U59Ur/94D15Pah9jP2RPfx+AL4E//4JP87/0z2YPZx9oL2k/hI//a19s b21/bo9vn3x/dW9yz/9z35N/df93D5bPeS96P3tP/5LPfW9+f58Pg2+hH6Ivoz//pE+F74b/kR+J H4oviz+mj/+NX45vj3+Qj5Gfnn+Xb5TP/5XftX+X/5kPmh+bL5yPnZ/BsvpUaGFua8eAWHD/XB+w wzGwMzAzoA+Qn2+gf/+8f6VvxT/GT8dfZT+qz6vf/6zvrf/In7AfsS+yP8u/tF//0N+2f7ePuJ/X f7q/u8/az7+9777/1g/BEzPAWKBI1cD+ZZxgwf/SX8Sf0G/Jj8qf/+cf6C/pP8wPzR/OL88/6W// 0V/kr9N/1I/Vn9av22/Yz//Z3/hP2//dD/uf3y/gP+FPwfXGRG9sYnnjf/NTOExhYjSANYA0gGll /nPk3+Xv/w/q3wfPCN8J73/sT+1f7m/vf/CPCy/2djXB+VEvQk9EWfpw8luEMjcSEUhUTUwVPQsx APNEfRgwAAAeADUQAQAAADwAAAA8NUZDQ0MwM0NBRjdDNUM0QzhFMkY5OTVFM0Q3MkUxMzM0QkJC NUNAcGxhdGludW0uZG9sYnkubmV0PgADAIAQ/////wsA8hABAAAAHwDzEAEAAABsAAAAcQB1AGUA cwB0AGkAbwBuACUAMwBBACAAbQBhAHAAcABpAG4AZwAgAGQAeQBuAGEAbQBpAGMAIABSAFQAUAAg AGYAbwByAG0AYQB0AHMAIAB1AHMAaQBuAGcAIABTAEQAUAAuAEUATQBMAAAACwD2EAAAAABAAAcw 2K+1YpDfwgFAAAgwiHS6YpDfwgEDAN4/n04AAAMA8T8JBAAAHgD4PwEAAAAMAAAASGFnZXIsIFRv ZGQAAgH5PwEAAABKAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPURPTEJZIFdPUkxE V0lERS9PVT1TRi9DTj1SRUNJUElFTlRTL0NOPVRISAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1p bmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAA AwAZQAAAAAADABpAAAAAAB4AMEABAAAABAAAAFRISAAeADFAAQAAAAQAAABUSEgAHgA4QAEAAAAE AAAAVEhIAB4AOUABAAAAAgAAAC4AAAADAAJZAAAWAAMACVkCAAAACwBmgQggBgAAAAAAwAAAAAAA AEYAAAAADoUAAAAAAAADAH6BCCAGAAAAAADAAAAAAAAARgAAAABShQAAoJgBAB4Af4EIIAYAAAAA AMAAAAAAAABGAAAAAFSFAAABAAAABQAAADEwLjAAAAAAAwDCgQggBgAAAAAAwAAAAAAAAEYAAAAA AYUAAAAAAAALAMeBCCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA0YEIIAYAAAAAAMAAAAAA AABGAAAAABCFAAAAAAAAAwDYgQggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAEiCCCAGAAAA AADAAAAAAAAARgAAAAAGhQAAAAAAAAsASYIIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAAAAAAAHgBK ggggBgAAAAAAwAAAAAAAAEYAAAAAg4UAAAEAAAATAAAAODA3MTUyMjIxLTI4MDIyMDAzAAALACkA AAAAAAsAIwAAAAAAAwAGEAnOu2EDAAcQFgYAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABI SUFMTCxXSEFUSVNUSEVCRVNUTUVUSE9EVE9ERUZJTkVBVkFMSURFTkNPRElOR05BTUVGT1JBTkVX RU5DT0RJTkdGT1JNQVQ/UkVHQVJESU5HPERSQUZULUZMQUtTLUFWVC1SAAAAAAIBfwABAAAAPAAA ADw1RkNDQzAzQ0FGN0M1QzRDOEUyRjk5NUUzRDcyRTEzMzRCQkI1Q0BwbGF0aW51bS5kb2xieS5u ZXQ+AI0v ------_=_NextPart_001_01C2DF90.62B81230-- --=_Boundary_wqxsIPIkxS4FRVvhHiUH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. --=_Boundary_wqxsIPIkxS4FRVvhHiUH-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt