From daemon@optimus.ietf.org Fri Feb 1 03:14:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01400 for ; Fri, 1 Feb 2002 03:14:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00036 for avt-archive@odin.ietf.org; Fri, 1 Feb 2002 03:14:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29918; Fri, 1 Feb 2002 03:10:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29887 for ; Fri, 1 Feb 2002 03:10:05 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00468 for ; Fri, 1 Feb 2002 03:09:58 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g1189sw11525 for ; Fri, 1 Feb 2002 13:39:54 +0530 (IST) Received: from dorai (pcz-dorai.sasken.com [10.1.36.99]) by sunms2.sasken.com (8.9.3/8.9.3) with SMTP id NAA09000 for ; Fri, 1 Feb 2002 13:39:54 +0530 (IST) Message-ID: <017801c1aaf7$e02db360$6324010a@sasi.com> From: "Dorairaj V" To: Date: Fri, 1 Feb 2002 13:40:13 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0175_01C1AB25.F9D52680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [AVT] comments on draft-ietf-avt-mpeg4-simple00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0175_01C1AB25.F9D52680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , In the document draft-ietf-avt-mpeg4-simple00.txt Section 3.2.1.1 :=20 1) AU-Index : There is a statement which says " To encode the serial number in any=20 such non-first AU-header, the AU-Index-delta field is used.=20 When each AU-Index field is coded with the value 0, the serial=20 number of the AU (fragment) is not specified and in that case=20 receivers MAY ignore the AU-Index field. " Section 3.3.6 on High-bit-rate AAC says contains the following statement = "Each AU-Index field MUST be coded with the value 0" . which implies = that receivers MAY ignore the AU-Index field . In the above case it is not clear as to what is the utiliy of "AU-Index" = field for High-bit rate AAC . If AU-Index field has to be 0 , then the better option would be to have = "AUIndexLength" =3D 0 instead of having "AU-Index" field as 0 . 2) Section 3.2.1.1 :=20 AU-Index-delta : "If the AU-Index field is present in the first AU-header in=20 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 time" If interleaving is not used then instead of using IndexDeltaLength > 0 = and then setting the IndexDeltaLength field to 0 , it is better to have = IndexDeltaLength =3D 0 . I dont see any utility in having IndexDeltaLength > 0 when you dont have = any intention of using interleaving . 3)=20 It would be clear if the different media which are convered under the = term "mpeg-generic" (Used in a=3Drtpmap:96 , mpeg-generic ... )are = mentioned . Do AAC-LC , MPEG4 CELP fall under mpeg-generic .=20 With regards Dorai ------=_NextPart_000_0175_01C1AB25.F9D52680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
 
In the document=20 draft-ietf-avt-mpeg4-simple00.txt
 
Section 3.2.1.1 :
 
1) AU-Index :
There is a statement which says " To = encode the=20 serial number in any =
         such=20 non-first AU-header, the AU-Index-delta field is used.=20
         When each AU-Index = field is=20 coded with the value 0, the serial=20
         number of the AU = (fragment)=20 is not specified and in that case=20
         receivers MAY = ignore the=20 AU-Index field. "
 
Section 3.3.6 on High-bit-rate AAC says = contains=20 the following statement
"Each AU-Index field MUST be coded with = the value=20 0" . which implies that receivers MAY ignore the AU-Index field = .
 
In the above case it is not clear as to = what is the=20 utiliy of "AU-Index" field for High-bit rate AAC .
If AU-Index field has to be 0 , then = the better=20 option would be to have "AUIndexLength" =3D 0 instead of having = "AU-Index" field=20 as 0 .
 
2) Section 3.2.1.1 :
AU-Index-delta :
"If the AU-Index field is present in = the first=20 AU-header in
         the AU = Header=20 Section, then the AU-Index-delta field MUST be=20
         present in any = subsequent=20 (non-first) AU-header. When the=20
         AU-Index-delta is = coded=20 with the value 0, it indicates that=20
         the Access Units = are=20 consecutive in time"
 
If interleaving is not used then = instead of using=20 IndexDeltaLength > 0 and then setting  the IndexDeltaLength = field to 0 ,=20 it is better to have IndexDeltaLength =3D 0 .
I dont see any utility in having = IndexDeltaLength=20 > 0 when you dont have any intention of using interleaving = .
 
3)
It would be clear if the different = media which are=20 convered under the term "mpeg-generic" (Used in a=3Drtpmap:96 , = mpeg-generic ...=20 )are mentioned . Do AAC-LC , MPEG4 CELP  fall under mpeg-generic .=20
 
 
 
With regards
Dorai
 
 
 
------=_NextPart_000_0175_01C1AB25.F9D52680-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Fri Feb 1 08:10:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20782 for ; Fri, 1 Feb 2002 08:10:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13208 for avt-archive@odin.ietf.org; Fri, 1 Feb 2002 08:10:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13168; Fri, 1 Feb 2002 08:10:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13140 for ; Fri, 1 Feb 2002 08:10:16 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20755 for ; Fri, 1 Feb 2002 08:10:10 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA04403; Fri, 1 Feb 2002 14:10:10 +0100 (MET) Received: from mchh150e.mch.pn.siemens.de ([139.21.130.150]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA07267; Fri, 1 Feb 2002 14:10:12 +0100 (MET) Received: by mchh150e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 14:10:18 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Elisabetta Carrara (ERA)'" , "'avt@ietf.org'" Cc: Euchner Martin ICN M SR 3 Subject: RE: [AVT] SRTP: (In)security of encrypted SID Frames - A new Secu rity Threa t? Date: Fri, 1 Feb 2002 14:10:11 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Elisabetta, yes, you are absolutely correct. I was thinking more of block ciphers than of stream ciphers. Thus, in this regard, stream ciphers have a security advantage over block ciphers. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | 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: Elisabetta Carrara (ERA) [mailto:Elisabetta.Carrara@era.ericsson.se] Sent: Thursday, January 31, 2002 11:17 AM To: 'avt@ietf.org' Cc: Euchner Martin ICN M SR 3 Subject: RE: [AVT] SRTP: (In)security of encrypted SID Frames - A new Secu rity Threa t? Hi Martin! The attack model considered when designing stream ciphers *is* that large amounts of plaintext are known. A cipher whose security would depend on plaintext entropy would be completely unacceptable. In SRTP we use AES in counter mode (or f8 mode). Both of these modes are provably secure under the assumption that AES is a "pseudo random permutation" (which is widely believed). The proof of security implies the following: even if an attacker has a large amount of known plaintext (and thus, knows the output of the corresponding keystream segments), it will in no way help him to deduce *any* non-trivial information about an unknown plaintext portion. If they did, there would be a fundamental design flaw in AES, which would probably render all use of AES insecure. Thus, your concern is a general stream cipher issue. The alternative, using a block cipher would be completely unacceptable from wireless (bit-error) point of view. Moreover, except for the fact that a block cipher can (marginally) conceal the length (up to block boundaries), there is really nothing that suggests that AES is more or less secure when runs as a block cipher, or as a stream cipher. Section 10.3 does consider the issue. We can expand it, and also add something like: "Due to the way a stream cipher combines plaintext with its output, (secure) stream ciphers are designed to resist known plaintext attacks." thanks, cheers, /Mats & Elisabetta > -----Original Message----- > From: Euchner Martin ICN M SR 3 [mailto:Martin.Euchner@icn.siemens.de] > Sent: den 31 januari 2002 09:22 > To: 'avt@ietf.org'; Euchner Martin ICN M SR 3 > Subject: [AVT] SRTP: (In)security of encrypted SID Frames - A new > Security Threa t? > > > Dear SRTP and security experts, > > > This text raises a security concern upon the RTP payload > voice encryption as > accomplished by SRTP for example. The conclusion is to > further investigate > analysis of this security issue but also to consider this issue in the > security consideration section of SRTP. > > Background > Certain voice codecs and voice compression algorithms provide > the capability > of silence detection and silence suppression (see e.g. > G.723.1, G.729AB, > G.728 and also new G.711 Appendix II). Instead of > transmitting the sampled > silence signal itself, these schemes rather transmit silence > parameters as > SID frames. The purpose of this mechanism is to reduce > bandwidth on the wire > and generate comfort noise at the peer side when there isn't > any significant > input signal at the source. > > Basically, SID frames provide an indication of detected > silence and the > duration of this event. SID frames usually provide compact > parameters as > input to a noise generator on the recipient's end instead of > the actual > sampled silence. Typically, SID frames are much shorter than > encoded voice > payload; SID frames may even be of a short fixed length, as > opposed to some > codecs in which voice frames are of variable length. > > So far, multimedia security schemes such as SRTP encrypt all > voice payload > regardless of its semantics and contents. Doing this is > straightforward. > Thus, at present, SRTP does not distinguish between actual > encoded voice > payload data and SID frames. All application layer plaintext > content is > encrypted as ciphertext in the same manner. > > Thesis > However, there are doubts on whether this security technique > would not be > subject to the following security weakness: > > While the purpose of encryption is to conceal the contents of the > transmitted data, the characteristics of SID frames would > allow an attacker > intercepting ciphertext to deduce that encrypted SID frames were > transmitted. Thus, by traffic analysis, an attacker could distinguish > between encrypted SID frames and actual encrypted voide/video etc. > > It is presumed and appears likely that SID frame patterns > provide much less > entropy than any other regular voice data. This would be due > to the fact > that the SID frame provides only very few parameters that > would not change > dramatically from one SID frame to another. As such plaintext > SID frame > content could probably be guessed with much higher > probability than varying > voice content. > > Assuming this to hold true however, would permit cryptoanalysts and > attackers specifically, to efficiently run known-plaintext > attacks assuming > available ciphertext material by interception and guessed SID > plaintexts. > While brute-force attacks on arbitrary ciphertext would be > always possible > in theory, it is believed that brute-force attacks or known plaintext > attacks are infeasible in practice when assuming high entropy > plaintext and > strong encryption ciphers. > > Although SID frames would be encrypted, the presence of a SID > frame could be > deduced as the ciphertext would be of shorter length > typically. As a result > of a successful known-plaintext attack, the attacker would obtain the > session encryption key and thereby would be able to decrypt > any encrypted > voice payload. This attack appears feasible when done > off-line but depending > of the efficiency of the known-plaintext attack, an online > attack might be > feasible as well. This would break the entire security scheme. > > Conclusion > While the RTP payload encryption method as specified by SRTP > has not been > proven broken yet, we believe that this issue as pointed out > above should be > taken seriously. While any detailed analysis is not yet > available, we see > enough motivation by the raised concern above, to further > cryptanalyze the > ramifications of SID frame encryption. We encourage security > experts to > think about the problem and attempt to prove or disprove the > thesis. It is > to be noted, that a similar security concern might persist > for encrypted > video frames as well for particular video codecs, where the > video payload > headers were mostly constant or vary only moderately. > > If the security issue would turn out to be true, we seek appropriate > technical countermeasures how to improve the multimedia > payload encryption > method. One possibility could be not to encrypt SID frames but rather > transmit SID frames in plaintext. This would be acceptable > and valid as the > content of a SID frame itself would not leak any confidential > information to > an outsider. Doing this however, would make it necessary to > in-band signal > within the RTP packet that certain payload was not encrypted > and thereby let > the recipient selectively by-pass the decryption function. An > appropriate > signalling means should be defined then. > > In any way, it is proposed to address this security matter in > the security > consideration section of SRTP. > > > I appreciate any comments and feedback on this matter and > would particularly > like to know whether this issue has already been researched > anywhere so far. > > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 47713 > | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de > | 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 > -------------------------------------------------------------- > --------- > > > _______________________________________________ > 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 daemon@optimus.ietf.org Fri Feb 1 15:08:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10722 for ; Fri, 1 Feb 2002 15:08:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07155 for avt-archive@odin.ietf.org; Fri, 1 Feb 2002 15:08:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06994; Fri, 1 Feb 2002 15:04:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06966 for ; Fri, 1 Feb 2002 15:04:16 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10602 for ; Fri, 1 Feb 2002 15:04:10 -0500 (EST) Received: from RKUMAR-W2K.cisco.com ([171.69.184.196] (may be forged)) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA28236; Fri, 1 Feb 2002 12:03:35 -0800 (PST) Message-Id: <4.3.2.7.2.20020201115514.07baea58@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 12:01:57 -0800 To: Jonathan Rosenberg From: Rajesh Kumar Subject: Re: [AVT] Address/port to which separate FEC stream is directed Cc: avt@ietf.org, smarch@cisco.com In-Reply-To: <3C5A179B.5E0B3AB@dynamicsoft.com> References: <4.3.2.7.2.20020131154955.01e903d0@mira-sjc5-8.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org I agree with the justification for the requirement. However, it is necessary to mandate that the separate FEC stream constitute a separate session with its unique port? It it possible to work around the timestamp problem, and use share the session (IP address and RTP port) with the media packets. There are applications in which the port number range exhaustion is a problem. So my question is: Can separate media/FEC sessions be interpreted as a "required option" (i.e. something which must be supported if the other side asks for it) and not as a hard-and-fast requirement in all cases? I am hoping that such leeway is permitted by rfc2733. Rajesh At 11:20 PM 1/31/2002 -0500, you wrote: >Rajesh Kumar wrote: > > > > Jonathan, Henning > > > > rfc2733 seems to mandate that a separate FEC stream, when produced, must > > be > > sent to a different port or IP address. Isn't is possible to send the > > FEC > > packets to the same port/address as the media packets? Even if this is > > do, you cannot omit the parameters , ,
> type> > > and , right? > >Well, my recollection is fuzzy here, but I recall that we decided that a >separate RTP session was better. One reason that I remember was rtp >header compression/rohc, since the timestamp predictors would be wrong >every time a FEC packet was emitted. I suspect there are other reasons >too, but that is the one I remember. > >Anyway, rfc2733 does explicitly say that the FEC stream is sent as a >separate RTP session. Its in section 3: > > The FEC packets are not sent in the same RTP stream as the media > packets. They can be sent as a separate stream, or as a secondary > codec in the redundant codec payload format [5]. > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Fri Feb 1 15:33:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11343 for ; Fri, 1 Feb 2002 15:33:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08552 for avt-archive@odin.ietf.org; Fri, 1 Feb 2002 15:33:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08049; Fri, 1 Feb 2002 15:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08018 for ; Fri, 1 Feb 2002 15:29:32 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11256 for ; Fri, 1 Feb 2002 15:29:26 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g11KTLb12049; Fri, 1 Feb 2002 15:29:21 -0500 Message-Id: <200202012029.g11KTLb12049@chiron.nge.isi.edu> To: Rajesh Kumar cc: Jonathan Rosenberg , avt@ietf.org, smarch@cisco.com Subject: Re: [AVT] Address/port to which separate FEC stream is directed In-Reply-To: Your message of "Fri, 01 Feb 2002 12:01:57 PST." <4.3.2.7.2.20020201115514.07baea58@mira-sjc5-8.cisco.com> Date: Fri, 01 Feb 2002 15:29:21 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org You can use RFC 2198 redundancy to piggyback the FEC onto the original packets. Colin --> Rajesh Kumar writes: >I agree with the justification for the requirement. However, it is >necessary to mandate that the separate FEC stream constitute a separate >session with its unique port? It it possible to work around the timestamp >problem, and use share the session (IP address and RTP port) with the media >packets. There are applications in which the port number range exhaustion >is a problem. > >So my question is: Can separate media/FEC sessions be interpreted as a >"required option" (i.e. something which must be supported if the other side >asks for it) and not as a hard-and-fast requirement in all cases? I am >hoping that such leeway is permitted by rfc2733. > >Rajesh > >At 11:20 PM 1/31/2002 -0500, you wrote: > > >>Rajesh Kumar wrote: >> > >> > Jonathan, Henning >> > >> > rfc2733 seems to mandate that a separate FEC stream, when produced, must >> > be >> > sent to a different port or IP address. Isn't is possible to send the >> > FEC >> > packets to the same port/address as the media packets? Even if this is >> > do, you cannot omit the parameters , ,
> > type> >> > and , right? >> >>Well, my recollection is fuzzy here, but I recall that we decided that a >>separate RTP session was better. One reason that I remember was rtp >>header compression/rohc, since the timestamp predictors would be wrong >>every time a FEC packet was emitted. I suspect there are other reasons >>too, but that is the one I remember. >> >>Anyway, rfc2733 does explicitly say that the FEC stream is sent as a >>separate RTP session. Its in section 3: >> >> The FEC packets are not sent in the same RTP stream as the media >> packets. They can be sent as a separate stream, or as a secondary >> codec in the redundant codec payload format [5]. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PH: (973) 952-5000 >>http://www.dynamicsoft.com > > >_______________________________________________ >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 daemon@optimus.ietf.org Mon Feb 4 10:31:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25720 for ; Mon, 4 Feb 2002 10:31:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09603 for avt-archive@odin.ietf.org; Mon, 4 Feb 2002 10:31:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08880; Mon, 4 Feb 2002 10:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08830 for ; Mon, 4 Feb 2002 10:22:56 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25465; Mon, 4 Feb 2002 10:22:49 -0500 (EST) From: jan.vandermeer@philips.com Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA15915; Mon, 4 Feb 2002 16:21:40 +0100 (CET) (envelope-from jan.vandermeer@philips.com) Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl4.philips.com via mwrap (4.0a) id xma015842; Mon, 4 Feb 02 16:21:40 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA09400; Mon, 4 Feb 2002 16:22:22 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.213]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA18241; Mon, 4 Feb 2002 16:22:19 +0100 (MET) Subject: Re: [AVT] comments on draft-ietf-avt-mpeg4-simple00.txt To: "Dorairaj V" Cc: avt@ietf.org, avt-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 4 Feb 2002 16:19:07 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 04/02/2002 16:22:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Dear Dorai, Thanks for your comments. Please find my reply below: Comment 1); You suggest that if AU-Index field has to be 0, then the better option would be to have "AUIndexLength" = 0 instead of having "AU-Index" field as 0. From conceptual point of view your suggestion makes sense. However, the solution in the draft was selected to simplify parsing of the AU header. If the AU-index field is absent for the first AU, and if the AU-index-delta field is present for any subsequent AU, then the number of bits in the AU-header is not the same for each AU. This complicates parsing and therefore the current solution was chosen. I agree that this choice needs some explanation in the draft. Comment 2); Again you are right from conceptual perspective. This was chosen for simplicity reason, and also this choice may need explanation in the draft. For AAC and CELP it was decided to use one or two bytes per AU-header, independent of the usage of interleaving. It means that the AU-index-delta field is also present if no interleaving is applied, and the consequence of that is is that the value of AU-index-delta needs to be coded with the value 0. On the other hand this constraint allows applications to swith off interleaving for a short period, and concatenate subsequent frames in one RTP packet, but I am not sure how useful that feature is. Comment 3); The draft can be used to transport any MPEG-4 stream under the term "mpeg-generic"; in principle, the draft can even be used to transport future, not yet defined MPEG-4 streams. So a list of media can be provided, but that will be only a list of examples, not an exhaustive list. But AAC and CELP are certainly in that list. In due time I will incorporate your suggestions in a new release of the draft. Thanks again for your comments; if you have further questions, please let me know. Kind regards, Jan Jan van der Meer Philips Digital Networks - MP4Net Prof Holstlaan 4 Building WDB-1 P.O. Box 80002 5600 JB Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 "Dorairaj V" .com> cc: (bcc: Jan vanderMeer/EHV/BE/PHILIPS) Sent by: Subject: [AVT] comments on draft-ietf-avt-mpeg4-simple00.txt avt-admin@iet f.org Classification: 2002-02-01 09:10 AM Hi , In the document draft-ietf-avt-mpeg4-simple00.txt Section 3.2.1.1 : 1) AU-Index : There is a statement which says " To encode the serial number in any such non-first AU-header, the AU-Index-delta field is used. When each AU-Index field is coded with the value 0, the serial number of the AU (fragment) is not specified and in that case receivers MAY ignore the AU-Index field. " Section 3.3.6 on High-bit-rate AAC says contains the following statement "Each AU-Index field MUST be coded with the value 0" . which implies that receivers MAY ignore the AU-Index field . In the above case it is not clear as to what is the utiliy of "AU-Index" field for High-bit rate AAC . If AU-Index field has to be 0 , then the better option would be to have "AUIndexLength" = 0 instead of having "AU-Index" field as 0 . 2) Section 3.2.1.1 : AU-Index-delta : "If the AU-Index field is present in the first AU-header in the AU Header Section, then the AU-Index-delta field MUST be present in any subsequent (non-first) AU-header. When the AU-Index-delta is coded with the value 0, it indicates that the Access Units are consecutive in time" If interleaving is not used then instead of using IndexDeltaLength > 0 and then setting the IndexDeltaLength field to 0 , it is better to have IndexDeltaLength = 0 . I dont see any utility in having IndexDeltaLength > 0 when you dont have any intention of using interleaving . 3) It would be clear if the different media which are convered under the term "mpeg-generic" (Used in a=rtpmap:96 , mpeg-generic ... )are mentioned . Do AAC-LC , MPEG4 CELP fall under mpeg-generic . With regards Dorai _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Mon Feb 4 11:31:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27794 for ; Mon, 4 Feb 2002 11:31:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13071 for avt-archive@odin.ietf.org; Mon, 4 Feb 2002 11:31:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12062; Mon, 4 Feb 2002 11:17:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12016 for ; Mon, 4 Feb 2002 11:17:24 -0500 (EST) Received: from gw-nl5.philips.com (gw-nl5.philips.com [212.153.235.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27364; Mon, 4 Feb 2002 11:17:20 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id RAA15263; Mon, 4 Feb 2002 17:17:17 +0100 (MET) (envelope-from philippe.gentric@philips.com) Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl5.philips.com via mwrap (4.0a) id xma015261; Mon, 4 Feb 02 17:17:18 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA05539; Mon, 4 Feb 2002 17:17:17 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA10489; Mon, 4 Feb 2002 17:17:16 +0100 (MET) To: Dave Singer Cc: avt@ietf.org, avt-admin@ietf.org, Franceschini Guido Subject: RE: [AVT] one question about the MPEG-4 generic RTP payload format(multiSL) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 4 Feb 2002 17:13:19 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 04/02/2002 17:35:38, Serialize complete at 04/02/2002 17:35:38 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0059E0ECC1256B56_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multipart message in MIME format. --=_alternative 0059E0ECC1256B56_= Content-Type: text/plain; charset="us-ascii" OK, I propose to change: " According to RFC1889 [5, Section 5.1] timestamps are recommended to start at a random value for security reasons. However then, a receiver is not in the general case able to reconstruct the original MPEG-4 Time Stamps (CTS, DTS, OCR) which can be of use for applications where streams from multiple sources are to be synchronized (for example one stream from local storage, another from a streaming server). Therefore the usage of such a random offset SHOULD be avoided. " into " Since, according to RFC1889 [5, Section 5.1], timestamps are recommended to start at a random value, a receiver is not in the general case able to reconstruct the original MPEG-4 Time Stamps (CTS, DTS, OCR) which can be of use for applications where streams from multiple sources are to be synchronized (for example one stream from local storage, another from a streaming server). Therefore such applications require the transport out of band of the random offset, which is not in the scope of this specification." Regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com Dave Singer 02/01/2002 00:49 To: Philippe Gentric/LIM/CE/PHILIPS@EMEA1 Franceschini Guido cc: avt@ietf.org avt-admin@ietf.org Subject: RE: [AVT] one question about the MPEG-4 generic RTP payload format(multiSL) Classification: I'm with Philippe the packaging spec that allows both RTP and other delivery means should specify how the time-lines are aligned. Only one solution is using the same bit-values; the kind of RTP-NTP mapping that RTSP does is another. Yet a third is simply knowing that the two pieces of content have a simultaneous start, and driving them from the same clock. There are many. Such a spec should also discuss how to manage buffers when the two sources are not synchronized (basically, you have to run at the speed of the slowest source and buffer the faster ones). It's a bigger question than a mere "should not" in this spec. -- David Singer Apple Computer/QuickTime --=_alternative 0059E0ECC1256B56_= Content-Type: text/html; charset="us-ascii"
OK,
I propose to change:

"  According to RFC1889 [5, Section 5.1] timestamps are recommended to
   start at a random value for security reasons. However then, a
   receiver is not in the general case able to reconstruct the original
   MPEG-4 Time Stamps (CTS, DTS, OCR) which can be of use for
   applications where streams from multiple sources are to be
   synchronized (for example one stream from local storage, another
   from a streaming server). Therefore the usage of such a random
   offset SHOULD be avoided. "

into

" Since, according to RFC1889 [5, Section 5.1], timestamps are recommended to
   start at a random value, a  receiver is not in the general case able to reconstruct the original
   MPEG-4 Time Stamps (CTS, DTS, OCR) which can be of use for
   applications where streams from multiple sources are to be
   synchronized (for example one stream from local storage, another
   from a streaming server). Therefore such applications require
the transport out of band of the random offset, which is not in the scope
of this specification."


Regards,




Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric@philips.com
http://www.mpeg-4.philips.com


Dave Singer <singer@apple.com>

02/01/2002 00:49

       
        To:        Philippe Gentric/LIM/CE/PHILIPS@EMEA1
Franceschini Guido <Guido.Franceschini@tilab.com>
        cc:        avt@ietf.org
avt-admin@ietf.org
        Subject:        RE: [AVT] one question about the MPEG-4 generic RTP payload format(multiSL)

        Classification:        




I'm with Philippe

the packaging spec that allows both RTP and other delivery means
should specify how the time-lines are aligned.  Only one solution is
using the same bit-values;  the kind of RTP-NTP mapping that RTSP
does is another.  Yet a third is simply knowing that the two pieces
of content have a simultaneous start, and driving them from the same
clock.  There are many.  Such a spec should also discuss how to
manage buffers when the two sources are not synchronized (basically,
you have to run at the speed of the slowest source and buffer the
faster ones).  It's a bigger question than a mere "should not" in
this spec.
--
David Singer
Apple Computer/QuickTime

--=_alternative 0059E0ECC1256B56_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Mon Feb 4 20:45:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09831 for ; Mon, 4 Feb 2002 20:45:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14313 for avt-archive@odin.ietf.org; Mon, 4 Feb 2002 20:45:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14132; Mon, 4 Feb 2002 20:38:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14100 for ; Mon, 4 Feb 2002 20:38:10 -0500 (EST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09750 for ; Mon, 4 Feb 2002 20:38:07 -0500 (EST) Received: from VAIOStW2.cs.tu-berlin.de (root@kuerbis.cs.tu-berlin.de [130.149.25.60]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id CAA22878 for ; Tue, 5 Feb 2002 02:35:55 +0100 (MET) Message-Id: <5.1.0.14.2.20020205022255.02b4bdc0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Feb 2002 02:35:07 +0100 To: avt@ietf.org From: Stephan Wenger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Comments on the MPEG4-Simple packetization Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Folks, Recent communication with the authors of the draft encouraged me to make these comments available to AVT, in order to show that the draft receives proof-reading. Please consider this as a review in the sense the chairs requested. These comments are relative to draft-ietf-avt-mpeg4-simple.txt Editorial: 1. Proof-Reading of the References. I found one problem, reference [5] is never used although it should be in section 2.11, but there may be more. 2. Headers/Footers do not comply with the normal I-D format. Please fix. Page numbers ARE helpful. 3. Structure of Section 2: This section contains a lot of different information in an order that I do not feel to be natural. I would suggest: 2.1 What does the draft do: a) Transport a single ES in the form of an AU, a multitude of AUs, or a single AU fragment in one RTP packet, potentially with interleaving. Short intro, no details yet. b) Relies on "Modes", to be defined (references to later sections), explain clearly that modes are essential (has also to go into the Introduction -- this is something other RTP payloads do not have c) Has a relationship with multisl and 3016 (reference to later details) 2.2 Payload specification a) Section 2.9 as an overview b) section 2.2, 2.3, 2.4, 2.5 2.3 Mapping of MPEG header information a) section 2.6 b) section 2.7 c) section 2.8 Technical comments 1. non-random timestamp: (Note: based on recent reflector activity, this comment and the related concern seems to be void. Great. Anyway, I copy here what I wrote to the authors) Personally, I don't like the concept as it is, and I believe that more intelligent ways out of the problem should be searched, both for the multisl and for the simple drafts. But, regardless of my opinion, the non-random timestamp does open a security hole. It has to be discussed in the "Security Considerations" Section that this hole exists, and that it is not problematic for the intended applications of the draft, or you are in for trouble latest at the IESG last call. (This needs also to be fixed in the multisl draft). 2. The restriction to a single AU fragment per RTP packet prevents Slice- Interleaving which has been shown to be an extremely efficient error resilience tool in the H.263 research (and, hence, was included in the H.263 test model and in RFC2429). It would also facilitate gateway design in such cases in which large changes of the MTU size can happen, e.g. in wireline/wireless gateways. I'm unsure whether the inclusion of a multitude of AU fragments per RTP packet produces a large set of new problems, but you should consider it (or write a very good reason into the draft why this was not included, otherwise there will be questions during last call). 3. Timestamp-Issue re B-frames: (Note: based on private discussions with one of the author I continue to believe that the presence of the DTS has indeed little to do with the possibility of decoding B-frames. I continue to believe the field is redundant, and the mechanism for the DTS reconstruction based on the regular Timestamp and the in-band information of the video stream is sufficient. However, it may be convenient to have a DTS as generated by the system layer. If this is the case, then it should be mentioned in the draft instead of the reason given. Anyway, here my original comment) Another thing I don't understand (and which should go into the draft, because if I don't understand it, there may be others, too). My understanding is that the MPEG-4 video bit stream is self-contained, including the timing information for B-frame reproduction. The reason for the DTS lies deep into the SL-Layer design, but it is, as far as I understand, neither necessary for the correct media reproduction, nor for the internal works of the payload spec and RTP. Hence, it looks to me that the DTS is really only there because it is also present in the multisl draft (which may need it for synchronization reasons or something I don't know). It may be acceptable to just state that the field is present for no other reason but to keep bit-by-bit synchronicity with the MultiSL draft. Or, if there is a technical reason, state it. I don't feel the given rationale compelling -- in particular I believe that the MPEG-4 video bit stream IS self contained even with respect to B frames. 4. The Mode concept: See above in the editorial section regarding the prominent placements of the Mode Concept description. My technical problem (which may be an editorial as well) lies in the fact that you discuss provisions regarding the carrying of video (e.g. presence of DTS) outside a mode discussion, but in the mainstream document. Is this a half though-through mode? Then call it like this and put it into an appendix (or work it out completely and put it into the Mode section itself). Or is it a collection of constraints people who design a mode for video have to keep in mind? Then call it like this and move it to an appropriate place. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 04:27:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15029 for ; Wed, 6 Feb 2002 04:27:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18142 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 04:27:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17990; Wed, 6 Feb 2002 04:25:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17963 for ; Wed, 6 Feb 2002 04:25:17 -0500 (EST) Received: from gateway.ncoretech.com (IDENT:root@[164.164.42.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14990 for ; Wed, 6 Feb 2002 04:25:11 -0500 (EST) Received: from ncoretech.com (IDENT:root@mail.ncoretech.com [192.168.1.3]) by gateway.ncoretech.com (8.10.0/8.10.0) with ESMTP id g169P8Y01010 for ; Wed, 6 Feb 2002 14:55:08 +0530 Received: (from root@localhost) by ncoretech.com (8.10.0/8.10.0) id g169P8G11125 for avt@ietf.org.VIRCHECK; Wed, 6 Feb 2002 14:55:08 +0530 Received: from ncoretech.com (ws186.ncoretech.com [192.168.1.186]) by ncoretech.com (8.10.0/8.10.0) with ESMTP id g169P6K10944; Wed, 6 Feb 2002 14:55:06 +0530 Message-ID: <3C60F8CE.EDF33440@ncoretech.com> Date: Wed, 06 Feb 2002 15:05:10 +0530 From: angai X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: rtp@vovida.org, avt@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses on Wed Feb 6 14:55:07 IST 2002 Content-Transfer-Encoding: 7bit Subject: [AVT] RFC 2833 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Hi all , 1.Whether there are any opensource application(like hearme , openh323 ) which supports rfc2833 ? 2.Whether Rtp for dtmf should be used during call setup ?If that is the case how dynamic payload can be used for it ? Thanking you , Angai _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 08:43:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19656 for ; Wed, 6 Feb 2002 08:43:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02186 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 08:43:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02140; Wed, 6 Feb 2002 08:42:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02108 for ; Wed, 6 Feb 2002 08:42:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19525; Wed, 6 Feb 2002 08:42:27 -0500 (EST) Message-Id: <200202061342.IAA19525@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, 06 Feb 2002 08:42:27 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-evrc-smv-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 : An RTP Payload Format for EVRC and SMV Vocoders Author(s) : A. Li Filename : draft-ietf-avt-evrc-smv-00.txt Pages : 19 Date : 05-Feb-02 This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-evrc-smv-00.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-evrc-smv-00.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-evrc-smv-00.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: <20020205140657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-evrc-smv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-evrc-smv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020205140657.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 09:40:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21218 for ; Wed, 6 Feb 2002 09:40:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05000 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 09:40:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04951; Wed, 6 Feb 2002 09:39:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04921 for ; Wed, 6 Feb 2002 09:39:54 -0500 (EST) Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21200 for ; Wed, 6 Feb 2002 09:39:49 -0500 (EST) Received: from purple.nge.isi.edu (csp@localhost) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g18EdmC01626; Fri, 8 Feb 2002 09:39:48 -0500 Message-Id: <200202081439.g18EdmC01626@purple.nge.isi.edu> To: "jean" cc: 4on2andIP-sys@advent.ee.columbia.edu, avt@ietf.org In-Reply-To: Your message of "Wed, 06 Feb 2002 12:30:21 +0100." <06d901c1af01$aaa28410$0a00a8c0@transix> Date: Fri, 08 Feb 2002 09:39:48 -0500 From: Colin Perkins Subject: [AVT] Re: SDP pbs Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --> "jean" writes: >RE: [AVT] MPEG-4 over IP draft: a=mpeg-iod (fwd)Dear all, > >( repost of a 2 weeks old msg) > > >I'm having some pbs with the SDP attributes defined in part 14496 - 8 >(that also appears in MultiSL and SingleSL drafts i believe). > >According to RFC2327 (section 6, sub-section Attributes), the formatting >of attributes for SDP is >a= >or >a=: > >and for both "mpeg4-iod" and "mpeg4-esid" (maybe some others but i >wouldn't swear) we have: > >a= > >And this is a bit annoying for generic SDP parsers. Is the SDP syntax >that flexible (hope not ;), or is this a typo, some obscur design issue >or something that just happened to be like that ? It's not legal SDP. Sounds like a typo in the mpeg draft. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 16:30:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02834 for ; Wed, 6 Feb 2002 16:30:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27830 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 16:30:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27586; Wed, 6 Feb 2002 16:29:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20416 for ; Wed, 6 Feb 2002 05:08:52 -0500 (EST) Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15573 for ; Wed, 6 Feb 2002 05:08:48 -0500 (EST) From: YDAMBIELLE@aol.com Received: from YDAMBIELLE@aol.com by imo-r01.mx.aol.com (mail_out_v31_r1.26.) id l.13d.8ea619f (4116) for ; Wed, 6 Feb 2002 05:08:19 -0500 (EST) Message-ID: <13d.8ea619f.29925a93@aol.com> Date: Wed, 6 Feb 2002 05:08:19 EST To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Language: en X-Mailer: AOL 5.0 for Windows sub 100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA20417 Subject: [AVT] Mulplexing the datas with FLEXMUX + TCRTP Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit Hello, I'm a french engineer studient and I'm doing a paper about MPEG-4 and the multimedia. While I was preparing my paper, I've discovered that using FLEXMUX + TCRTP could be more interesting that using FLEXMUX alone or TCRTP alone. With FLEXMUX or TRCTP, I can send less packets on the network by multiplexing theim. In both case I can choose the number of packets I want to multiplex. According to the MPEG-4 standard, I use the synchronization layer. If I only use FLEXMUX, I can choose the number of SL-PDU packets I want to to multiplex and also witch one will be in the multiplexed packet. I can choose to insert SL-PDU A and not SL-PDU B in the multiplexed solution...But whatever I do, I will always have a 40 bytes header for each paquets due to the [IP/UDP/RTP] encapsulation. For reducing the overheads, I can increase the size of the payload by inserting more SL-PDU packets, but in case of lost, it could be a big problem for the receiver. If I only use TCRTP, I can multiplex a number of [IP/UDP/RTP] packets. But I can't witch SL-PDU packets will be multiplexed. With the CRTP compression algorithm, I will reduce the 40 bytes header of the [IP/UDP/RTP] packet to 2 bytes. Whatever the size of my TCRTP packet is, I will always have a 24 bytes header (20 bytes for the IP header + 1 bytes for the TYPE + 1 byte for the LEN + 2 bytes for the [IP/UDP/RTP] compression of each packets). For reducing the overheads, I have increase the size of the payloads by multiplexing more [IP/UDP/RTP] packets. But in case of lost, I will have the same problem as using FLEXMUX alone because in both case, I have used the synchronization layer. At egal size of payload, we have less overhead with TCRTP than with FLEXMUX. If I use FLEXMUX + TCRTP : with FLEXMUX I control the number of SL-PDU packets multiplexed and also witch packet will be multiplexed. Then, with CRTP, I reduce the [IP/UDP/RTP] header of each paquets multiplexed before. Finally, the overhead will always be more reduced. For some algorithm, like AAC, multiplexing 5 packets give me a 2,3 per cent overhead… witch is very few. In that case, I think that we don't really need to use TCRTP. So, using TCRTP depend on a certain value of overhead, calculated just before choosing to use it or not. I would like to know your opinion about my method and if it could be interresting for the community to continue to write a paper about that. I'm waiting for your anwsers. Best regards, Yannick DAMBIELLE PS: I apologize for my poor english. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 16:30:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02858 for ; Wed, 6 Feb 2002 16:30:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27884 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 16:30:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27616; Wed, 6 Feb 2002 16:29:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25362 for ; Wed, 6 Feb 2002 06:30:56 -0500 (EST) Received: from mailserv2.iuinc.com (mailserv2.iuinc.com [206.245.164.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17202 for ; Wed, 6 Feb 2002 06:30:53 -0500 (EST) Received: (qmail 28285 invoked from network); 6 Feb 2002 11:30:48 -0000 Received: from dyn-212-129-28-118.ppp.libertysurf.fr (HELO transix) (212.129.28.118) by mailserv2.iuinc.com with SMTP; 6 Feb 2002 11:30:48 -0000 Message-ID: <06d901c1af01$aaa28410$0a00a8c0@transix> From: "jean" To: <4on2andIP-sys@advent.ee.columbia.edu>, References: Date: Wed, 6 Feb 2002 12:30:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D6_01C1AF0A.0B248100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [AVT] SDP pbs Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_06D6_01C1AF0A.0B248100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] MPEG-4 over IP draft: a=3Dmpeg-iod (fwd)Dear all, ( repost of a 2 weeks old msg) I'm having some pbs with the SDP attributes defined in part 14496 - 8 = (that also appears in MultiSL and SingleSL drafts i believe). According to RFC2327 (section 6, sub-section Attributes), the formatting = of attributes for SDP is a=3D or a=3D: and for both "mpeg4-iod" and "mpeg4-esid" (maybe some others but i = wouldn't swear) we have: a=3D And this is a bit annoying for generic SDP parsers. Is the SDP syntax = that flexible (hope not ;), or is this a typo, some obscur design issue = or something that just happened to be like that ? regards, Jean =20 ------=_NextPart_000_06D6_01C1AF0A.0B248100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] MPEG-4 over IP draft: a=3Dmpeg-iod = (fwd)
Dear all,
( repost of a 2 weeks old = msg)
 

I'm having some pbs with the SDP = attributes=20 defined in part 14496 - 8 (that also appears in MultiSL and SingleSL = drafts i=20 believe).

According to RFC2327 (section 6, sub-section = Attributes), the=20 formatting of attributes for SDP=20 is
a=3D<attribute>
or
a=3D<attribute>:<value><= BR>
and=20 for both "mpeg4-iod" and "mpeg4-esid" (maybe some others but i wouldn't = swear)=20 we have:

a=3D<attribute> <value>

And this is a = bit=20 annoying for generic SDP parsers. Is the SDP syntax that flexible (hope = not ;),=20 or is this a typo, some obscur design issue or something that just = happened=20 to be like that ?
 
regards,

Jean



   =20
------=_NextPart_000_06D6_01C1AF0A.0B248100-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 6 16:41:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03260 for ; Wed, 6 Feb 2002 16:41:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28602 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 16:41:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28580; Wed, 6 Feb 2002 16:41:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28546 for ; Wed, 6 Feb 2002 16:41:29 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03241 for ; Wed, 6 Feb 2002 16:41:24 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g16LeuP03636; Wed, 6 Feb 2002 13:40:56 -0800 (PST) Received: from tmima-w2k.cisco.com (sjc-vpn1-619.cisco.com [10.21.98.107]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABQ51820; Wed, 6 Feb 2002 13:40:30 -0800 (PST) Message-Id: <4.3.2.7.2.20020206032714.048f0410@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 23:39:39 +0200 To: "Lars-Erik Jonsson (EPL)" , avt@ietf.org From: Tmima Koren Subject: Re: [AVT] Another review of enhanced CRTP In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Hi Lars-Erik Thank you very much for reviewing the draft At 08:22 PM 1/30/2002 +0100, Lars-Erik Jonsson (EPL) wrote: >Hi all, > >I was asked to review the ECRTP draft, and have some minor inputs >that might be useful to take into account. Overall, I think the >document is fine, and with one exception, all my comments are of >a pure editorial nature. I am especially satisfied with the way >the "IP-ID versus Twice" issue was resolved. > >1) Let's start with the only technical comment, which is just a > suggestion. Why not let the HDRCKSUM (section 2.2) cover also > the IP ID for IPv4, in addition to the IP-pseudo header, the > UDP header, and the first 12 octets of UDP data (e.g. RTP). By > including the IP ID, the concerns about using Twice (section > 2.3, 5th paragraph) would only apply to IPv4 with enabled > UDP checksum (if the HDRCKSUM is enabled). > > This is just a suggestion, and a question whether you have > considered that option. Let us know your opinions. I prefer to have the same 'twice' scheme for UDP checksum and HDRCKSUM >2) In section 2, first bullet, I think it would be good to > clarify "RTP values". Are you addressing all RTP fields, or > just a subset, and in that case, which fields are addressed. > Please clarify that. I'll specify the RTP fields >3) In section 2.2, second paragraph, it could be useful to > indicate that a disabled (set to zero) UDP checksum is a case > only possible for IPv4. Yes, I'll add that >4) In section 3, should there be a reference to the updated > RFC2509? What is the status of that document anyway? I'll add the reference. rfc2509bis is on its way to PS >5) Finally some formatting comments: >5a) There are no page beaks (form feed) in the document >5b) I am missing headers, footers, and especially page numbers >5c) The expiration date is missing at the last page >5d) The indentation is only "correct" in sections 3, 6, and 7 I'll fix the formatting Thanks again for your thorough review Tmima >Otherwise I think the document is fine and fully support the idea >of submitting it (with correction) for PS. > >Cheers, >/Lars-Erik > >_______________________________________________ >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 daemon@optimus.ietf.org Wed Feb 6 22:55:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10778 for ; Wed, 6 Feb 2002 22:55:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA16303 for avt-archive@odin.ietf.org; Wed, 6 Feb 2002 22:55:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16268; Wed, 6 Feb 2002 22:54:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13687 for ; Wed, 6 Feb 2002 21:57:12 -0500 (EST) Received: from mail.techway.co.kr (mail.techway.co.kr [211.172.232.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08963 for ; Wed, 6 Feb 2002 21:57:07 -0500 (EST) Received: (qmail 4060 invoked from network); 7 Feb 2002 03:11:47 -0000 Received: from unknown (HELO Young) (211.235.239.20) by mail.techway.co.kr with SMTP; 7 Feb 2002 03:11:47 -0000 Message-ID: <008c01c1af83$1518adc0$14efebd3@Young> Reply-To: "Lim, Young-Kwon" From: "Lim, Young-Kwon" To: "jean" , "Colin Perkins" Cc: <4on2andIP-sys@advent.ee.columbia.edu>, References: <200202081439.g18EdmC01626@purple.nge.isi.edu> Date: Thu, 7 Feb 2002 11:56:47 +0900 Organization: net&tv Co., Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: SDP pbs Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Jean, Thank you for identifying it. Seems an editorial error. Sincerely, Young. ----- Original Message ----- From: "Colin Perkins" To: "jean" Cc: <4on2andIP-sys@advent.ee.columbia.edu>; Sent: Friday, February 08, 2002 11:39 PM Subject: Re: SDP pbs > --> "jean" writes: > >RE: [AVT] MPEG-4 over IP draft: a=mpeg-iod (fwd)Dear all, > > > >( repost of a 2 weeks old msg) > > > > > >I'm having some pbs with the SDP attributes defined in part 14496 - 8 > >(that also appears in MultiSL and SingleSL drafts i believe). > > > >According to RFC2327 (section 6, sub-section Attributes), the formatting > >of attributes for SDP is > >a= > >or > >a=: > > > >and for both "mpeg4-iod" and "mpeg4-esid" (maybe some others but i > >wouldn't swear) we have: > > > >a= > > > >And this is a bit annoying for generic SDP parsers. Is the SDP syntax > >that flexible (hope not ;), or is this a typo, some obscur design issue > >or something that just happened to be like that ? > > It's not legal SDP. Sounds like a typo in the mpeg draft. > > Colin > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 12 07:02:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08543 for ; Tue, 12 Feb 2002 07:02:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA17166 for avt-archive@odin.ietf.org; Tue, 12 Feb 2002 07:02:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17151; Tue, 12 Feb 2002 07:01:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17122 for ; Tue, 12 Feb 2002 07:01:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08353; Tue, 12 Feb 2002 07:01:25 -0500 (EST) Message-Id: <200202121201.HAA08353@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, 12 Feb 2002 07:01:25 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 : The MIDI Wire Protocol Packetization (MWPP) Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-00.txt Pages : 21 Date : 11-Feb-02 This memo describes the MIDI Wire Protocol Packetization (MWPP). MWPP is a resilient RTP packetization for the MIDI wire protocol. MWPP defines a multicast-compatible recovery journal format, to support the graceful recovery from lost packets during a MIDI session. MWPP is compatible with the MPEG-4 generic RTP payload format, to support MPEG 4 Audio codecs that accept MIDI control input. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-00.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-mwpp-midi-rtp-00.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-mwpp-midi-rtp-00.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: <20020211152120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mwpp-midi-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152120.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 12 09:07:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11987 for ; Tue, 12 Feb 2002 09:07:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22581 for avt-archive@odin.ietf.org; Tue, 12 Feb 2002 09:07:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22555; Tue, 12 Feb 2002 09:06:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22528 for ; Tue, 12 Feb 2002 09:06:30 -0500 (EST) Received: from lumumba.luc.ac.be (root@lumumba.luc.ac.be [193.190.9.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11977 for ; Tue, 12 Feb 2002 09:06:26 -0500 (EST) Received: from localhost (jori@localhost) by lumumba.luc.ac.be (8.11.4/8.11.4) with ESMTP id g1CE66r20519 for ; Tue, 12 Feb 2002 15:06:06 +0100 Date: Tue, 12 Feb 2002 15:06:06 +0100 (CET) From: Jori Liesenborgs To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] jvoiplib v1.2.0 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Hi, Just wanted to let you know that a new version of my VoIP library, jvoiplib, is available. Improvements were made in the soundcard IO modules and several bugs were fixed. For more info, check out http://lumumba.luc.ac.be/jori/jvoiplib/ Bye, Jori _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 12 13:32:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21451 for ; Tue, 12 Feb 2002 13:32:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07696 for avt-archive@odin.ietf.org; Tue, 12 Feb 2002 13:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07214; Tue, 12 Feb 2002 13:30:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07157 for ; Tue, 12 Feb 2002 13:30:00 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.45.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21364 for ; Tue, 12 Feb 2002 13:29:58 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id KAA27467 for avt@ietf.org; Tue, 12 Feb 2002 10:28:54 -0800 Date: Tue, 12 Feb 2002 10:28:54 -0800 From: John Lazzaro Message-Id: <200202121828.KAA27467@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] MWPP notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org > Internet-Drafts@ietf.org writes: > > Title : The MIDI Wire Protocol Packetization (MWPP) > Filename : draft-ietf-avt-mwpp-midi-rtp-00.txt > > http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-00.txt This version has large sections rewritten compared to the version I talked about in Salt Lake, in response to both IETF feedback and feedback from MIDI developers ... too many changes to list here, see Section 0 of the memo for a list of what's new and what's left to do ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 12 15:27:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25148 for ; Tue, 12 Feb 2002 15:27:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12298 for avt-archive@odin.ietf.org; Tue, 12 Feb 2002 15:27:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12283; Tue, 12 Feb 2002 15:27:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12252 for ; Tue, 12 Feb 2002 15:27:15 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25133 for ; Tue, 12 Feb 2002 15:27:12 -0500 (EST) From: David.Leon@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CKT7Q07658 for ; Tue, 12 Feb 2002 14:29:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Feb 2002 14:27:13 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 14:26:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Feb 2002 14:26:55 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD16FA1B@daebe008.NOE.Nokia.com> Thread-Topic: clarification on RTCP minimum interval in AV profile Thread-Index: AcG0A6DDcfgTSRmxEdat1gAGKfW1ag== To: X-OriginalArrivalTime: 12 Feb 2002 20:26:55.0640 (UTC) FILETIME=[9D153980:01C1B403] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA12253 Subject: [AVT] clarification on RTCP minimum interval in AV profile Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit Hello, In the revised AV profile (draft-ietf-avt-profile-new-12.txt) section 2, it is described how the RTCP interval should be computed. RTCP report interval: The suggested constants are to be used for the RTCP report interval calculation. Sessions operating under this profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the session bandwidth. The RTCP traffic bandwidth MAY be divided into two separate session parameters for those participants which are active data senders and those which are not. Following the recommendation in the RTP specification [2] that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. For a particular session, the RTCP bandwidth for non-data-senders MAY be set to zero when operating on unidirectional links or for sessions that don't require feedback on the quality of reception. The RTCP bandwidth for data senders SHOULD be kept non-zero so that sender reports can still be sent for inter-media synchronization and to identify the source by CNAME. The means by which the one or two session parameters for RTCP bandwidth are specified is beyond the scope of this memo. I find it confusing that there is no mention of the minimum interval described in RTP. Or should it be understood from the sentence 'The suggested constants are to be used for the RTCP report interval calculation' that the recommended value for the fixed minimum interval given in RTP must be used in this profile? Thanks, David. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 13 13:01:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15624 for ; Wed, 13 Feb 2002 13:01:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20429 for avt-archive@odin.ietf.org; Wed, 13 Feb 2002 13:02:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19877; Wed, 13 Feb 2002 12:56:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19848 for ; Wed, 13 Feb 2002 12:56:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15512 for ; Wed, 13 Feb 2002 12:56:46 -0500 (EST) Received: from neserve0.corp.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQmcbf00372 for ; Wed, 13 Feb 2002 17:56:47 GMT Received: by neserve0.corp.us.uu.net id QQmcbf14984 for avt@ietf.org; Wed, 13 Feb 2002 12:56:42 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: To: avt@ietf.org Date: Wed, 13 Feb 2002 12:56:42 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] possibly off topic: how to detect a break in syndicated programming material Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Hi there, I don't know whether this is off topic or not, probably is, but perhaps somebody that reads this will be able to get me some answers. I am looking for a method of determining when a break is coming and how long that break will be. Sometimes, I can hear bleeding from a video signal if the audio channels were poorly taken and can detect a fade to black, or if the network has a little quirk that distinguishes its programming from local inserts, but that doesn't even help because the networks run their own spots, thus making it difficult to determine the wanted program material from the advertisements or promotionals. Is it possible there is a hidden bit of information coded in the extra bandwidth on an audio or video carrier? Any suggestions would be greatly appreciated. Next time you watch a program, ask yourself how you instinctively know where the break is. Once the start is located, it is probably simple to guestomate the length--most shows are predictible. _J _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Thu Feb 14 05:24:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14655 for ; Thu, 14 Feb 2002 05:24:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20562 for avt-archive@odin.ietf.org; Thu, 14 Feb 2002 05:24:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20542; Thu, 14 Feb 2002 05:24:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20511 for ; Thu, 14 Feb 2002 05:24:09 -0500 (EST) Received: from rd.grame.fr (rd.grame.fr [194.5.49.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14647 for ; Thu, 14 Feb 2002 05:24:02 -0500 (EST) Received: from [194.5.49.3] (macdom.grame.fr [194.5.49.3]) by rd.grame.fr (8.11.3/8.9.3) with ESMTP id g1EGkPI19529; Thu, 14 Feb 2002 11:46:26 -0500 X-Sender: fober@pop.grame.fr Message-Id: In-Reply-To: <200202121828.KAA27467@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Light F3.1.1l Date: Thu, 14 Feb 2002 11:24:02 +0100 To: avt@ietf.org From: Dominique Fober Subject: Re: [AVT] MWPP notes ... Cc: John Lazzaro Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA20512 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit >> Internet-Drafts@ietf.org writes: >> >> Title : The MIDI Wire Protocol Packetization (MWPP) >> Filename : draft-ietf-avt-mwpp-midi-rtp-00.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-00.txt > >This version has large sections rewritten compared to the version I >talked about in Salt Lake, in response to both IETF feedback and >feedback from MIDI developers ... too many changes to list here, see >Section 0 of the memo for a list of what's new and what's left to do ... > >------------------------------------------------------------------------- >John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley >lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro >------------------------------------------------------------------------- Hi, Some questions and comments about draft-ietf-avt-mwpp-midi-rtp-00.txt. >6. Session Description Protocol for RTP Transport >... >The binary parameter codes the presence (1) or absence (0) of the >recovery journal section in MWPP packets. Isn't it redundant with the G bit of the recovery kournal ? Moreover, the policy concerning recovery may change during a session as mentionned section 5. >9. Congestion Control >... >MWPP implementations SHOULD sense the MIDI wire procotol stream for >command patterns that result in excessive packet rates, and filter these >streams as part of MWPP to reduce the packet rate. In particular, control change and pitch bend commands may raise the congestion problem. Such flow is generaly made up of continuous variations. Filtering is one solution but it would usefull to provide a policy in appendix (normative or not ?): raw filtering of one message type ? or filtering part of a set of messages so as to keep the global shape of the variation ? >Appendix A.3. Chapter N: MIDI NoteOff and NoteOn >... >The 4-bit fields LOW and HIGH determine the number of bitfield bytes >that follow the note logs. A bitfield byte codes NoteOff information for >eight consecutive MIDI note numbers, with the MSB representing the >lowest note number. The MSB of the first bitfield byte codes the note >number 16*LOW; the MSB of the last bitfield byte codes the note number >16*HIGH. Why 16*LOW and 16*HIGH ? as 8*LOW and 8*HIGH is enough and may save one byte. For example: coding a note off 8 in the first case would be: LOW=0 HIGH=0 bitfield: 0x00 0x70 (2 bytes are necessary) while in the second case: LOW=1 HIGH=1 bitfield: 0x70 (1 bytes only) The midi pitch range (0-127) is covered by the fact that HIGH is related to the last bitfield MSB. Therefore, coding a note off 127 would be: LOW=15 HIGH=15 bitfield: 0x01 >Appendix A.6. Chapter C: MIDI Control Change When you talk about controlers, could you add the control number to their name ? (less ambiguity to the reader: the Sustain pedal is commonly named Sustenuto on/off (#66) for example). I can't understand the purpose of the VALUE/COUNT field for some controlers: it's sometimes used like a serial number, is it to improve reliability ? but isn't it redundant with the Checkpoint Packet Seqnum ? >Appendix C. References You can add to reference 8: "Proceedings of the International Conference on WEB Delivering of Music 2001, pages 147-154" And some more general comments: Support of system common and real-time messages would provide a nearly complete MIDI support. Great work ! ---------------------------------------------- Dominique Fober ---------------------------------------------- GRAME - Centre National de Creation Musicale - 9 rue du Garet 69001 Lyon France tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01 http://www.grame.fr _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Thu Feb 14 16:47:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10801 for ; Thu, 14 Feb 2002 16:47:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29117 for avt-archive@odin.ietf.org; Thu, 14 Feb 2002 16:47:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29090; Thu, 14 Feb 2002 16:46:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29054 for ; Thu, 14 Feb 2002 16:46:18 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.45.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10790 for ; Thu, 14 Feb 2002 16:46:14 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id NAA31994; Thu, 14 Feb 2002 13:45:03 -0800 Date: Thu, 14 Feb 2002 13:45:03 -0800 From: John Lazzaro Message-Id: <200202142145.NAA31994@snap.CS.Berkeley.EDU> To: avt@ietf.org, fober@grame.fr Subject: Re: [AVT] MWPP notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org > Dominique Fober writes > > Hi, Hi Dominique! [...] >Appendix C. References > > You can add to reference 8: "Proceedings of the International > Conference on WEB Delivering of Music 2001, pages 147-154" Done. [...] >Appendix A.6. Chapter C: MIDI Control Change > > When you talk about controlers, could you add the control number > to their name ? (less ambiguity to the reader: the Sustain pedal > is commonly named Sustenuto on/off (#66) for example). Sounds good, I'll do that in the next document update. [...] > I can't understand the purpose of the VALUE/COUNT field for some > controlers: it's sometimes used like a serial number, The Sustenuto pedal is a good example. Imagine the pedal is down. Two packets are sent in succession, the first lifts the pedal, the second depresses it again. Both packets are lost, as is a third unrelated packet, but the next packet (with the recovery journal) arrives OK. The loss is detected, and we examine the recovery journal. If we coded the "value" of the pedal, we wouldn't see a change in state: it was down before and its down now too. And because the "unrelated packet" was lost too, the S bits don't clue us in that a change occurred. We wouldn't know to release and re-depress the pedal, and depending on the patch, we could have a sustained sonic cloud that lasted a long time. This is the sort of problem the "count" semantics addresses -- it points to changes that can't be detected by "current state" alone. Note that as the I-D is written today, thought has only gone into the Controller numbers that Structured Audio used explicitly -- a very small subset. Part of the remaining work is going through the controllers number by number, uncovering these problems, and figuring out what reasonable steps can be taken in the recovery journal coding scheme to help out. [...] >>Appendix A.3. Chapter N: MIDI NoteOff and NoteOn > > [...] > > > Why 16*LOW and 16*HIGH ? as 8*LOW and 8*HIGH is enough and > may save one byte. [...] I'll take a close look at this and get back to you; the Chapter N coding evolved over a few months, and the motivations for the decisions were complicated -- maybe changing the encoding as you suggest is the right way to go, but maybe there's a subtle issue somewhere ... I'll take a look at it. [...] > Isn't redundant with the G bit of the recovery journal ? The SDP flag and the recovery-journal G bit serve different purposes, so I think both are needed. The is useful if you're setting up a TCP stream, or if you're setting up a UDP stream where you know the recovery journal mechanism won't be used (possible example: drum machine triggers). You can use the parameter to say "this stream only has MIDI command sections." No bandwidth is used to send recovery journals, and no sender effort is used to encode them. In contrast, the "G" bit is meant to handle two situations: [1] The sender is trying its best to maintain the guarantee, but something happens that makes it impossible to do so -- limited CPU cycles, limited RAM, the MTU packet-size ceiling, etc. Accidents happen in soft-real-time systems. When the G bit goes from 1 to 0, it tells the receiver that there's been an accident, and from now on more paranoia is needed. [2] In some circumstances, you won't have an RTCP channel, and so its impossible to maintain the guarantee at all -- but the application is going to forge ahead, and do its best to recover from lost packets. In this case, its still very valuable to have the recovery journal sent in each packet, even if there's no guarantee. For example: [a] Receivers can keep a history of the N most recent recovery journals received. When a packet loss is detected, it can check the "checkpoint packet seqnum" of the recovery journal sent before and after the loss. If the checkpoint packet hasn't changed, there's no problem. If the checkpoint packet _has_ changed, there may be a problem, but the receiver has many tools to help figure out if the problem is real: the receiver knows its own history, and it has the trace of N packets to examine. [b] If a receiver _does_ detect that there's been a potential failure in the guarantee, it may choose to take safety measures on its side, as a one time measure -- premature ending NoteOn's that it believes may have had a lost NoteOff, for example. Once this one-time measure is taken, future journals can be considered reliable again in many cases (until the next loss occurs). [...] > [on Congestion Control] > > In particular, control change and pitch bend commands may raise the > congestion problem. Such flow is generaly made up of continuous > variations. Filtering is one solution but it would usefull to provide > a policy in appendix (normative or not ?): raw filtering of one > message type ? or filtering part of a set of messages so as to keep > the global shape of the variation ? It sounds like addition SDP parameters to specify filtering policy for a MIDI command type is what you want: once a parameter is defined, it can be used for simple communication (the sender declaring via the SDP what the policy will be for filtering) or more complicated negotiations (senders and receivers exchange preferences, etc). The actual use of SDP to do these sorts of negotiation is being standardized generally, so the main issue for MWPP is parameter definition. That said, this might be the sort of feature that works best defined in a separate Internet Draft, instead of being mixed into the brief SDP descriptions in the main MWPP document. Keeping the MWPP memo to a reasonable size is going to be a challenge, as System Exclusive support gets added, and so figuring out how to factor out features into their own documents is a good idea ... [...] > Support of system common and real-time messages would provide a nearly > complete MIDI support. > > Great work ! Thanks -- I'm closing in on updating the MIDI command section so that it can encode any legal MIDI stream -- things like really long SysEx message, System Realtime commands embedded in other commands, SysEx commands where the timing of bytes encode information, etc. Once this is done, I'll release a new I-D version for comments, and then start looking at the recovery journal implications for MIDI System commands ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Fri Feb 15 07:03:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02675 for ; Fri, 15 Feb 2002 07:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15660 for avt-archive@odin.ietf.org; Fri, 15 Feb 2002 07:03:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15515; Fri, 15 Feb 2002 07:02:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15490 for ; Fri, 15 Feb 2002 07:02:37 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02530; Fri, 15 Feb 2002 07:02:35 -0500 (EST) Message-Id: <200202151202.HAA02530@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, 15 Feb 2002 07:02:35 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-amr-12.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 and file storage format for AMR and AMR-WB audio Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie Filename : draft-ietf-avt-rtp-amr-12.txt Pages : 41 Date : 14-Feb-02 This document specifies a real-time transport protocol (RTP) payload format to be used for AMR and AMR-WB encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-12.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-amr-12.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-amr-12.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: <20020214105810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020214105810.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Sun Feb 17 19:38:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13559 for ; Sun, 17 Feb 2002 19:38:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07844 for avt-archive@odin.ietf.org; Sun, 17 Feb 2002 19:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07142; Sun, 17 Feb 2002 19:25:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07115 for ; Sun, 17 Feb 2002 19:25:49 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13441; Sun, 17 Feb 2002 19:25:38 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id g1I0P9p21204; Sun, 17 Feb 2002 16:25:09 -0800 (PST) (envelope-from casner@acm.org) Date: Sun, 17 Feb 2002 16:25:22 -0800 (PST) From: Stephen Casner To: ietf@ietf.org cc: iesg@ietf.org, AVT WG Subject: Re: [AVT] Last Call: RTP: A Transport Protocol for Real-Time Applications to Draft Standard In-Reply-To: <200201221944.OAA07636@ietf.org> Message-ID: <20020217160949.U7589-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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a Last Call comment on: > o RTP Profile for Audio and Video Conferences with Minimal Control > > > This document is intended to replace RFC1890, currently a Proposed > Standard. It was recently discovered that RFC1890 contains an ambiguity that remains in draft-ietf-avt-profile-new-12.txt. The table in Section 4.1 of the draft that specifies the convention for the ordering of audio channels contains two possible orderings for four channels: channels description channel 1 2 3 4 5 6 __________________________________________________ 2 stereo l r 3 l r c 4 quadrophonic Fl Fr Rl Rr 4 l c r S 5 Fl Fr Fc Sl Sr 6 l lc c r rc S This is ambiguous because the ordering is selected implicity by the number of channels. It must be that nobody has used 4-channel audio with RTP since the issue has not arisen before. We propose to just eliminate the "quadrophonic" order for the revision of the profile and add the following note: Note: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as "quadrophonic" has been eliminated to remove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has. The channel-order parameter specified in RFC3190 could be used to define a quadrophonic convention in the future if needed. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Sun Feb 17 21:40:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15671 for ; Sun, 17 Feb 2002 21:40:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA12484 for avt-archive@odin.ietf.org; Sun, 17 Feb 2002 21:40:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11846; Sun, 17 Feb 2002 21:30:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11794 for ; Sun, 17 Feb 2002 21:30:01 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.45.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14606 for ; Sun, 17 Feb 2002 21:29:55 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id SAA12513; Sun, 17 Feb 2002 18:28:31 -0800 Date: Sun, 17 Feb 2002 18:28:31 -0800 From: John Lazzaro Message-Id: <200202180228.SAA12513@snap.CS.Berkeley.EDU> To: avt@ietf.org, fober@grame.fr Subject: Re: [AVT] MWPP notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org > John Lazzaro writes: > >> Dominique Fober writes >> >> Why 16*LOW and 16*HIGH ? as 8*LOW and 8*HIGH is enough and >> may save one byte. [...] > > I'll take a close look at this and get back to you; > You are correct; 8*LOW and 8*HIGH is what's actually used in the sfront MWPP prototype code, I made an error writing up the I-D. Thanks for catching this ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Mon Feb 18 15:10:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16393 for ; Mon, 18 Feb 2002 15:10:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09179 for avt-archive@odin.ietf.org; Mon, 18 Feb 2002 15:10:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09133; Mon, 18 Feb 2002 15:09:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13221 for ; Sat, 16 Feb 2002 13:14:19 -0500 (EST) Received: from hotmail.com (oe41.law6.hotmail.com [216.32.240.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15037 for ; Sat, 16 Feb 2002 13:14:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Feb 2002 10:13:47 -0800 X-Originating-IP: [143.209.230.171] From: "Adetya Gupta" To: "RTP" Date: Sat, 16 Feb 2002 23:35:28 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C1B742.9E0A8A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 16 Feb 2002 18:13:47.0975 (UTC) FILETIME=[ADB74570:01C1B715] Subject: [AVT] urgent Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C1B742.9E0A8A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I have a problem, hoping that some of u may help. When i loop back the packets from DSP, the voice is fine, but if i loop back it through RTP, the quality degrades, voice is not smooth, and is not in continuous flow. I can also hear some click click noices. Plz help. I thank u all for going through my mail. regards Adetya ------=_NextPart_000_0047_01C1B742.9E0A8A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
       =20     I have a problem, hoping that some of u may=20 help.
When i loop back the packets from DSP, = the voice is=20 fine,
but if i loop back it through RTP, the = quality=20 degrades,
voice is not smooth, and is not in = continuous=20 flow.
I can also hear some click click=20 noices.
 
Plz help.
 
I thank u all for going through my=20 mail.
 
regards
Adetya
 
------=_NextPart_000_0047_01C1B742.9E0A8A60-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Mon Feb 18 19:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24276 for ; Mon, 18 Feb 2002 19:13:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA21816 for avt-archive@odin.ietf.org; Mon, 18 Feb 2002 19:13:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21762; Mon, 18 Feb 2002 19:11:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21732 for ; Mon, 18 Feb 2002 19:11:54 -0500 (EST) Received: from urdvg136.cms.usa.net (urdvg136.cms.usa.net [204.68.25.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24251 for ; Mon, 18 Feb 2002 19:11:50 -0500 (EST) Received: (qmail 2168 invoked from network); 19 Feb 2002 00:13:32 -0000 Received: from umdvg008.cms.usa.net (165.212.10.8) by outbound.postoffice.net with SMTP; 19 Feb 2002 00:13:32 -0000 Received: (qmail 10310 invoked by uid 60001); 19 Feb 2002 00:11:29 -0000 Message-ID: <20020219001129.10309.qmail@umdvg008.cms.usa.net> Received: from 210.81.76.41 [210.81.76.41] by umdvg008.cms.usa.net (USANET web-mailer 34FM.0700.28.01B); Tue, 19 Feb 2002 00:11:29 +0000 Date: 19 Feb 2002 08:11:29 SGT From: Dunman Teo To: avt@ietf.org X-Mailer: USANET web-mailer (34FM.0700.28.01B) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA21733 Subject: [AVT] Payload Type for MPEG-4 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit Hi all, I am a newbie to RTP hence I hope I am not asking too much stupid questions. :p Can anyone help me by telling me the value of the Payload Type field in the RTP header for MPEG-4 Video? I know there is one for MPEG-2 video but there does not seem to be one for MPEG-4. I also read somewhere on the internet that it depends on the features of MPEG-4 that we use. Is that correct? If that is the case, is there a document on the complete list of Payload Types? Thank you! Regards, Dunman ____________________________________________________________________ Get free e-mail and a permanent address at http://www.amexmail.com/?A=1 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Mon Feb 18 20:53:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26551 for ; Mon, 18 Feb 2002 20:53:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA26181 for avt-archive@odin.ietf.org; Mon, 18 Feb 2002 20:53:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26085; Mon, 18 Feb 2002 20:51:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26057 for ; Mon, 18 Feb 2002 20:51:02 -0500 (EST) Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26469 for ; Mon, 18 Feb 2002 20:50:56 -0500 (EST) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1J1oAC01305; Mon, 18 Feb 2002 20:50:10 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200202190150.g1J1oAC01305@purple.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Mon, 18 Feb 2002 20:50:10 -0500 From: Colin Perkins Subject: [AVT] AVT meeting in Minneapolis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Folks, The AVT working group is scheduled for two slots at the 53rd IETF meeting in Minneapolis. On the tentative agenda, these are 9:00 to 11:30am on Wednesday 20th March and 1:00 to 3:00pm on Thursday 21st 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 4th March. You are reminded that the cut-off date for -00 Internet Draft submissions is Friday, February 22nd, 5:00pm EST. Unless you have prior approval from the working group chairs, -00 submissions should have filenames with the format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts received after February 22nd will not be accepted. All other Internet-Draft submissions must be made by Friday, March 1st, at 5:00pm EST. Drafts which do not make the cutoff date will not be discussed at the meeting. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Mon Feb 18 21:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26943 for ; Mon, 18 Feb 2002 21:20:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27442 for avt-archive@odin.ietf.org; Mon, 18 Feb 2002 21:20:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27427; Mon, 18 Feb 2002 21:19:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27397 for ; Mon, 18 Feb 2002 21:19:57 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26933 for ; Mon, 18 Feb 2002 21:19:52 -0500 (EST) Received: from [165.247.88.216] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1257333; Mon, 18 Feb 2002 21:19:13 -0500 From: "Marshall Eubanks" Subject: Re: [AVT] Payload Type for MPEG-4 To: Dunman Teo , avt@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 18 Feb 2002 21:19:13 -0500 Message-ID: In-Reply-To: <20020219001129.10309.qmail@umdvg008.cms.usa.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit On 19 Feb 2002 08:11:29 SGT Dunman Teo wrote: > Hi all, > > I am a newbie to RTP hence I hope I am not asking too > much stupid questions. > :p > > Can anyone help me by telling me the value of the Payload > Type field in the > RTP header for MPEG-4 Video? I know there is one for > MPEG-2 video but there > does not seem to be one for MPEG-4. I also read somewhere > on the internet that > it depends on the features of MPEG-4 that we use. Is that > correct? If that is > the case, is there a document on the complete list of > Payload Types? > Hello; New audio / video profiles are not going to get a static Payload Type. For more information about dynamic payload types and the reasoning here, read Section 3.1 in http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-12.txt This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. RFC 3016 makes it clear that this is true for MPEG-4 in Sections 3.1 and 4.2 : It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen by means of an out of band signaling protocol (e.g., H.245, SIP, etc). In the dynamic assignment of RTP payload types for scalable streams, a different value SHOULD be assigned to each layer. The assigned values SHOULD be in order of enhance layer dependency, where the base layer has the smallest value. Regards Marshall Eubanks tme@multicasttech.com > > Thank you! > > Regards, > Dunman > > ____________________________________________________________________ > Get free e-mail and a permanent address at > http://www.amexmail.com/?A=1 > > _______________________________________________ > 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 daemon@ns.ietf.org Tue Feb 19 01:28:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02934 for ; Tue, 19 Feb 2002 01:28:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA15561 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 01:28:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15535; Tue, 19 Feb 2002 01:27:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15510 for ; Tue, 19 Feb 2002 01:27:23 -0500 (EST) Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.67.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02926 for ; Tue, 19 Feb 2002 01:27:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id g1J6RLr11521; Tue, 19 Feb 2002 01:27:21 -0500 (EST) Date: Tue, 19 Feb 2002 01:27:21 -0500 (EST) From: HAINING LIU To: <4on2andIP-sys@advent.ee.columbia.edu> cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Arguments on SL Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Hello, Can anyone point out the benefits SL bring to us comparing with the current solution of no sl layer in Mpeg-4 application (i.e. mp4 file streaming)? It seems that a design w/o sl layer still works fine, especially a system over IP networks. Certainly we have to build SL layer to be compliant with MPEG-4 systems standard, but that will also bring us complexity when mapping over RTP. Any strong arguments or useful pointers is highly appreciated. Regards, Haining _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Tue Feb 19 01:36:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03130 for ; Tue, 19 Feb 2002 01:36:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16242 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 01:36:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16107; Tue, 19 Feb 2002 01:34:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24352 for ; Mon, 18 Feb 2002 20:07:23 -0500 (EST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25503 for ; Mon, 18 Feb 2002 20:07:19 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id SAA18173 for ; Mon, 18 Feb 2002 18:07:21 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id SAA19501 for ; Mon, 18 Feb 2002 18:07:20 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g1J17I922310; Mon, 18 Feb 2002 19:07:19 -0600 (CST) Received: from email.mot.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id TAA13432; Mon, 18 Feb 2002 19:12:14 -0600 (CST) Message-ID: <3C71A5FD.18F44E01@email.mot.com> Date: Mon, 18 Feb 2002 19:10:21 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: AVT List CC: David Pearce Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] DSR draft revised Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Hi, all, The revised DSR over RTP draft has been submitted. The new version (v01) incorporates all the feedback and comments made so far during the WG last call. There is _no_ technical change made in this revision. However, thanks to the careful review and commenting by John Lazzaro, Priscilla Walther, and others, quite some editorial changes are made and I hope these changes will greatly improve the readability of the document. Here is a list of some of the editorial changes made: 1. Added a list of acronyms to improve readability. 2. The payload diagram is made more clear by showing the RTP header. 3. More sub-section headers are added to make the discussion more structured. 4. A new section is added to explain the usage of RTP header fields, per John's suggestion. 5. Missing text for "Encoding considerations" is added in section 6. 6. References are grouped into normative and informative. 7. A reference to ROHC hc is added as informative. The new version should appear on the IETF web-site soon. regards, -Qiaobing Xie Motorola _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@ns.ietf.org Tue Feb 19 02:48:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11949 for ; Tue, 19 Feb 2002 02:48:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18697 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 02:48:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18675; Tue, 19 Feb 2002 02:47:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18631 for ; Tue, 19 Feb 2002 02:47:26 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11940; Tue, 19 Feb 2002 02:47:23 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id IAA19914; Tue, 19 Feb 2002 08:46:17 +0100 (CET) (envelope-from philippe.gentric@philips.com) Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl4.philips.com via mwrap (4.0a) id xma019775; Tue, 19 Feb 02 08:46:18 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA13088; Tue, 19 Feb 2002 08:46:58 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA12530; Tue, 19 Feb 2002 08:46:57 +0100 (MET) To: Dunman Teo Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] Payload Type for MPEG-4 X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 19 Feb 2002 08:43:03 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 19/02/2002 09:05:36, Serialize complete at 19/02/2002 09:05:36 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 002AAC79C1256B65_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multipart message in MIME format. --=_alternative 002AAC79C1256B65_= Content-Type: text/plain; charset="us-ascii" There is no fixed payload type number for MPEG-4 video. You should use a payload type chosen in the dynamic ra nge i.e. your SDP looks like: m=video 1034 RTP/AVP 97 a=rtpmap:97 mpeg4-generic a=fmtp:97 StreamType=4 see draft-ietf-avt-mpeg4-multiSL-03.txt for details Regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com Dunman Teo Sent by: avt-admin@ietf.org 02/19/2002 08:11 To: avt@ietf.org cc: (bcc: Philippe Gentric/LIM/CE/PHILIPS) Subject: [AVT] Payload Type for MPEG-4 Classification: Hi all, I am a newbie to RTP hence I hope I am not asking too much stupid questions. :p Can anyone help me by telling me the value of the Payload Type field in the RTP header for MPEG-4 Video? I know there is one for MPEG-2 video but there does not seem to be one for MPEG-4. I also read somewhere on the internet that it depends on the features of MPEG-4 that we use. Is that correct? If that is the case, is there a document on the complete list of Payload Types? Thank you! Regards, Dunman ____________________________________________________________________ Get free e-mail and a permanent address at http://www.amexmail.com/?A=1 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 002AAC79C1256B65_= Content-Type: text/html; charset="us-ascii"
There is no fixed payload type number for MPEG-4 video.

You should use a payload type chosen in the dynamic ra        nge i.e.
your SDP looks like:

m=video 1034 RTP/AVP 97
a=rtpmap:97 mpeg4-generic
a=fmtp:97 StreamType=4

see
draft-ietf-avt-mpeg4-multiSL-03.txt
for details

Regards,


Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric@philips.com
http://www.mpeg-4.philips.com


Dunman Teo <sgdetail@usa.net>
Sent by: avt-admin@ietf.org

02/19/2002 08:11

       
        To:        avt@ietf.org
        cc:        (bcc: Philippe Gentric/LIM/CE/PHILIPS)
        Subject:        [AVT] Payload Type for MPEG-4

        Classification:        




Hi all,

I am a newbie to RTP hence I hope I am not asking too much stupid questions.
:p

Can anyone help me by telling me the value of the Payload Type field in the
RTP header for MPEG-4 Video? I know there is one for MPEG-2 video but there
does not seem to be one for MPEG-4. I also read somewhere on the internet that
it depends on the features of MPEG-4 that we use. Is that correct? If that is
the case, is there a document on the complete list of Payload Types?


Thank you!

Regards,
Dunman

____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1

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

--=_alternative 002AAC79C1256B65_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 19 04:59:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13414 for ; Tue, 19 Feb 2002 04:59:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24206 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 04:59:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24173; Tue, 19 Feb 2002 04:59:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24143 for ; Tue, 19 Feb 2002 04:59:00 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13405 for ; Tue, 19 Feb 2002 04:58:57 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4FARCF>; Tue, 19 Feb 2002 10:57:38 +0100 Message-ID: From: ROUX Catherine FTRD/DMI/REN To: "'HAINING LIU'" Cc: "'avt@ietf.org'" Subject: RE: [AVT] Arguments on SL Date: Tue, 19 Feb 2002 10:57:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-41c6deb8-246b-11d6-b1e5-00508b69ab48" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-41c6deb8-246b-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B92B.E37EE100" ------_=_NextPart_001_01C1B92B.E37EE100 Content-Type: text/plain Using Synchronisation Layer becomes necessary when the sampling is not made at constant rate. because in this case you have to transmit the timeStamp to Display at the good time. -----Message d'origine----- De : HAINING LIU [mailto:hainingl@gradient.cis.upenn.edu] Envoye : mardi 19 fevrier 2002 07:27 A : 4on2andIP-sys@advent.ee.columbia.edu Cc : avt@ietf.org Objet : [AVT] Arguments on SL Hello, Can anyone point out the benefits SL bring to us comparing with the current solution of no sl layer in Mpeg-4 application (i.e. mp4 file streaming)? It seems that a design w/o sl layer still works fine, especially a system over IP networks. Certainly we have to build SL layer to be compliant with MPEG-4 systems standard, but that will also bring us complexity when mapping over RTP. Any strong arguments or useful pointers is highly appreciated. Regards, Haining _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C1B92B.E37EE100 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AVT] Arguments on SL

Using Synchronisation Layer becomes necessary when = the
sampling is not made at constant rate.
because in this case you have to transmit the = timeStamp to
Display at the good time.





-----Message d'origine-----
De : HAINING LIU [mailto:hainingl@gradient= .cis.upenn.edu]
Envoye : mardi 19 fevrier 2002 07:27
A : 4on2andIP-sys@advent.ee.columbia.edu
Cc : avt@ietf.org
Objet : [AVT] Arguments on SL


Hello,

Can anyone point out the benefits SL bring to us = comparing with the
current solution of no sl layer in Mpeg-4 = application (i.e. mp4 file
streaming)? It seems that a design w/o sl layer = still works fine,
especially a system over IP networks.

Certainly we have to build SL layer to be compliant = with MPEG-4 systems
standard, but that will also bring us complexity = when mapping over
RTP. Any strong arguments or useful pointers is = highly appreciated.

Regards,

Haining


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

------_=_NextPart_001_01C1B92B.E37EE100-- ------=_NextPartTM-000-41c6deb8-246b-11d6-b1e5-00508b69ab48-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 19 07:02:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14989 for ; Tue, 19 Feb 2002 07:02:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00887 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 07:02:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00567; Tue, 19 Feb 2002 07:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00529 for ; Tue, 19 Feb 2002 07:00:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14738; Tue, 19 Feb 2002 07:00:38 -0500 (EST) Message-Id: <200202191200.HAA14738@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, 19 Feb 2002 07:00:38 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-ulp-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 : An RTP Payload Format for Generic FEC with Uneven Level Protection Author(s) : A. Li et al. Filename : draft-ietf-avt-ulp-04.txt Pages : 30 Date : 18-Feb-02 This document specifies a payload format for generic forward error correction to achieve uneven level protection (ULP) for media data encapsulated in RTP. It is an extension of the forward error correction scheme specified in RFC 2733 [1], and it is based on the same exclusive-or (parity) operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-04.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-ulp-04.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-ulp-04.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: <20020218133941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ulp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ulp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020218133941.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 19 07:11:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15569 for ; Tue, 19 Feb 2002 07:11:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01281 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 07:11:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01244; Tue, 19 Feb 2002 07:11:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01195 for ; Tue, 19 Feb 2002 07:11:06 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15502; Tue, 19 Feb 2002 07:11:04 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA09269; Tue, 19 Feb 2002 13:09:52 +0100 (CET) (envelope-from philippe.gentric@philips.com) Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a) id xma008950; Tue, 19 Feb 02 13:09:52 +0100 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 NAA12096; Tue, 19 Feb 2002 13:10:30 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA22337; Tue, 19 Feb 2002 13:10:23 +0100 (MET) To: ROUX Catherine FTRD/DMI/REN Cc: "'avt@ietf.org'" , avt-admin@ietf.org, "'HAINING LIU'" Subject: RE: [AVT] Arguments on SL X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 19 Feb 2002 12:52:08 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 19/02/2002 13:29:04, Serialize complete at 19/02/2002 13:29:04 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00417A17C1256B65_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org This is a multipart message in MIME format. --=_alternative 00417A17C1256B65_= Content-Type: text/plain; charset="us-ascii" Catherine, I have to disagree because RTP alone can do that ... SL becomes "necessary" as soon as you do more than audio + video specifically if you use MPEG-4 system stuff regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com ROUX Catherine FTRD/DMI/REN Sent by: avt-admin@ietf.org 02/19/2002 10:57 To: "'HAINING LIU'" cc: "'avt@ietf.org'" (bcc: Philippe Gentric/LIM/CE/PHILIPS) Subject: RE: [AVT] Arguments on SL Classification: Using Synchronisation Layer becomes necessary when the sampling is not made at constant rate. because in this case you have to transmit the timeStamp to Display at the good time. -----Message d'origine----- De : HAINING LIU [mailto:hainingl@gradient.cis.upenn.edu] Envoye : mardi 19 fevrier 2002 07:27 A : 4on2andIP-sys@advent.ee.columbia.edu Cc : avt@ietf.org Objet : [AVT] Arguments on SL Hello, Can anyone point out the benefits SL bring to us comparing with the current solution of no sl layer in Mpeg-4 application (i.e. mp4 file streaming)? It seems that a design w/o sl layer still works fine, especially a system over IP networks. Certainly we have to build SL layer to be compliant with MPEG-4 systems standard, but that will also bring us complexity when mapping over RTP. Any strong arguments or useful pointers is highly appreciated. Regards, Haining _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 00417A17C1256B65_= Content-Type: text/html; charset="us-ascii"
Catherine,

I have to disagree because RTP alone can do that ...

SL becomes "necessary" as soon as you do more than audio + video
specifically if you use MPEG-4 system stuff

regards,

Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric@philips.com
http://www.mpeg-4.philips.com


ROUX Catherine FTRD/DMI/REN <catherine.roux@rd.francetelecom.com>
Sent by: avt-admin@ietf.org

02/19/2002 10:57

       
        To:        "'HAINING LIU'" <hainingl@gradient.cis.upenn.edu>
        cc:        "'avt@ietf.org'" <avt@ietf.org>
(bcc: Philippe Gentric/LIM/CE/PHILIPS)
        Subject:        RE: [AVT] Arguments on SL

        Classification:        




Using Synchronisation Layer becomes necessary when the
sampling is not made at constant rate.
because in this case you have to transmit the timeStamp to
Display at the good time.




-----Message d'origine-----
De : HAINING LIU [mailto:hainingl@gradient.cis.upenn.edu]
Envoye : mardi 19 fevrier 2002 07:27
A : 4on2andIP-sys@advent.ee.columbia.edu
Cc : avt@ietf.org
Objet : [AVT] Arguments on SL

Hello,

Can anyone point out the benefits SL bring to us comparing with the
current solution of no sl layer in Mpeg-4 application (i.e. mp4 file
streaming)? It seems that a design w/o sl layer still works fine,
especially a system over IP networks.

Certainly we have to build SL layer to be compliant with MPEG-4 systems
standard, but that will also bring us complexity when mapping over
RTP. Any strong arguments or useful pointers is highly appreciated.

Regards,

Haining

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

--=_alternative 00417A17C1256B65_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 19 14:00:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01543 for ; Tue, 19 Feb 2002 14:00:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27032 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 14:00:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26873; Tue, 19 Feb 2002 13:59:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26843 for ; Tue, 19 Feb 2002 13:59:12 -0500 (EST) Received: from paris.packetizer.org (system@rdu26-244-205.nc.rr.com [66.26.244.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01510 for ; Tue, 19 Feb 2002 13:59:10 -0500 (EST) Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id g1JJ0AY30660 for ; Tue, 19 Feb 2002 14:00:11 -0500 Message-ID: <00d401c1b977$90daa6e0$745f6640@cisco.com> From: "Paul E. Jones" To: Date: Tue, 19 Feb 2002 13:59:31 -0500 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] Comments on draft-ietf-avt-rtp-new-11.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Folks, I noted that in the latest RTP draft has changed the hard requirement for odd/even RTP/RTCP port pairs to "SHOULD". I understand there are a number of good reasons for this, but I'm concerned about backward compatibility implications. What I would like to propose is that we do relax the requirement, but require that even/odd ports MUST be used unless otherwise negotiated out-of-band between the session applications. What I would expect is that SIP or H.323 applications will have to negotiate the fact that the ports used will not be paired as they are today. Of course, this does not close the door to incompatibility problems, but I think it will be more helpful than simply trying to use various ports and failing to get media through without any feedback as to why. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 19 20:27:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09856 for ; Tue, 19 Feb 2002 20:27:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA13716 for avt-archive@odin.ietf.org; Tue, 19 Feb 2002 20:27:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13596; Tue, 19 Feb 2002 20:26:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13569 for ; Tue, 19 Feb 2002 20:26:19 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09813 for ; Tue, 19 Feb 2002 20:26:16 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id g1K1OLp72898; Tue, 19 Feb 2002 17:24:21 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 19 Feb 2002 17:27:36 -0800 (PST) From: Stephen Casner To: "Paul E. Jones" cc: Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt In-Reply-To: <00d401c1b977$90daa6e0$745f6640@cisco.com> Message-ID: <20020219165658.Q55408-100000@ash.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org On Tue, 19 Feb 2002, Paul E. Jones wrote: > I noted that in the latest RTP draft has changed the hard requirement for > odd/even RTP/RTCP port pairs to "SHOULD". I understand there are a number > of good reasons for this, but I'm concerned about backward compatibility > implications. Since RFC 1889 did not use RFC 2119 keywords, it is not clear that the draft revision has made a change in the requirement level. Nevertheless, it is good to be concerned about proper interpretation. The reason for the SHOULD is that RTP is a framework that might be used in a various ways, possibly including some application using preassigned, static port numbers. > What I would like to propose is that we do relax the requirement, but > require that even/odd ports MUST be used unless otherwise negotiated > out-of-band between the session applications. What I would expect is that > SIP or H.323 applications will have to negotiate the fact that the ports > used will not be paired as they are today. Of course, this does not close > the door to incompatibility problems, but I think it will be more helpful > than simply trying to use various ports and failing to get media through > without any feedback as to why. Is there really a problem? The revised text says that ports MAY be selected without the even/odd constraint if both the RTP and RTCP port numbers are specified explicitly. In applications where only one port is specified and the other is implicitly derived from the first, then the implementation must be assuming some rule for their relationship. I can't see any motivation for an implementation to make up some different rule rather than using the one the draft says SHOULD be used. The real backwards compatibility problems that I see have to do with entities that may process RTP and/or RTCP packets without being party to the session establishment protocol. Examples would be a third-party RTCP monitor and an RTP header compression box. These entities won't be able to rely on RTCP being on an odd port. However, we agreed to accept this backwards incompatibility liability because NAT boxes forced us to accept port translations we could not control. By the way, I am happy to see that you are reading the draft and thinking carefully about the changes. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 20 07:15:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28073 for ; Wed, 20 Feb 2002 07:15:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19857 for avt-archive@odin.ietf.org; Wed, 20 Feb 2002 07:15:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19664; Wed, 20 Feb 2002 07:06:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19633 for ; Wed, 20 Feb 2002 07:05:58 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27485; Wed, 20 Feb 2002 07:05:55 -0500 (EST) Message-Id: <200202201205.HAA27485@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, 20 Feb 2002 07:05:55 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-dsr-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 Distributed Speech Recognition Author(s) : Q. Xie et al. Filename : draft-ietf-avt-dsr-01.txt Pages : Date : 19-Feb-02 This document specifies an RTP payload format for encapsulating front-end signal processing feature streams for distributed speech recognition (DSR) systems. The ETSI Standard ES 201 108 front-end is defined as the default codec in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dsr-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-dsr-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-dsr-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: <20020219134930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dsr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dsr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020219134930.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 20 12:44:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10743 for ; Wed, 20 Feb 2002 12:44:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10121 for avt-archive@odin.ietf.org; Wed, 20 Feb 2002 12:44:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10046; Wed, 20 Feb 2002 12:44:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10007 for ; Wed, 20 Feb 2002 12:44:02 -0500 (EST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10674 for ; Wed, 20 Feb 2002 12:43:59 -0500 (EST) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVbn66RWQA6fNS16o5oD+ccKSDP8dOffCMz+HZF0UcUi7k4Wc14nJiw1 Received: from sense-sea-focal-dynamic-7-12.oz.net ([216.39.135.140] helo=erols.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.33 #10) id 16dame-0005wd-00 for avt@ietf.org; Wed, 20 Feb 2002 12:44:01 -0500 Message-ID: <3C73DC30.F376F5EB@erols.com> Date: Wed, 20 Feb 2002 09:26:09 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] slow motion; trick play Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Greetings, Has anyone here done work on "trick play" modes over RTP? I think the main issue is that the "natural" timeline of the material (NPT - Normal Playing Time - in some contexts) is advancing at a different rate from the RTP clock. Some applications would be fast-forward and slow-motion controls for interactive video servers. Cheers, Chuck Harrison _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 20 17:15:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22015 for ; Wed, 20 Feb 2002 17:15:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24979 for avt-archive@odin.ietf.org; Wed, 20 Feb 2002 17:15:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24957; Wed, 20 Feb 2002 17:15:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24926 for ; Wed, 20 Feb 2002 17:15:23 -0500 (EST) Received: from paris.packetizer.org (system@rdu26-244-205.nc.rr.com [66.26.244.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22009 for ; Wed, 20 Feb 2002 17:15:18 -0500 (EST) Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id g1KMGRY01678; Wed, 20 Feb 2002 17:16:27 -0500 Message-ID: <036001c1ba5c$24d7e210$745f6640@cisco.com> From: "Paul E. Jones" To: "Stephen Casner" Cc: References: <20020219165658.Q55408-100000@ash.packetdesign.com> Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt Date: Wed, 20 Feb 2002 17:15:45 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Steve, As you pointed out, the real concern are the boxes in the middle. Most endpoints (note "most") can properly handle RTP/RTCP ports with no specific association. However, I have seen some implementations (NATs, proxies, and real endpoints) wherein there was an assumed association. H.323 actually does allow one to signal separate RTP and RTCP port numbers, but some implementations just ignore the RTCP port number field, assuming that the odd/even rule exists. RFC 2327 (SDP) states quite clearly that the m= line contains the RTP port and that the RTCP port is assumed. I know this is subject to change, as well, but we also have the compatibility problems. I certainly do not object to making such as change, as it would align with H.323. Nonetheless, I think the "capability" of supporting something other than even/odd ports should be advertised so that entities can properly inform users or network operators of such issues. In the RTP draft, I'd be quite happy with removing the odd/even requirement (SHOULD is fine), so long as there is also a statement that says that when RTP is used without even/odd port paring, that the session applications MUST negotiate the usage of non-even/odd ports. Paul ----- Original Message ----- From: "Stephen Casner" To: "Paul E. Jones" Cc: Sent: Tuesday, February 19, 2002 8:27 PM Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt > On Tue, 19 Feb 2002, Paul E. Jones wrote: > > > I noted that in the latest RTP draft has changed the hard requirement for > > odd/even RTP/RTCP port pairs to "SHOULD". I understand there are a number > > of good reasons for this, but I'm concerned about backward compatibility > > implications. > > Since RFC 1889 did not use RFC 2119 keywords, it is not clear that the > draft revision has made a change in the requirement level. > Nevertheless, it is good to be concerned about proper interpretation. > The reason for the SHOULD is that RTP is a framework that might be > used in a various ways, possibly including some application using > preassigned, static port numbers. > > > What I would like to propose is that we do relax the requirement, but > > require that even/odd ports MUST be used unless otherwise negotiated > > out-of-band between the session applications. What I would expect is that > > SIP or H.323 applications will have to negotiate the fact that the ports > > used will not be paired as they are today. Of course, this does not close > > the door to incompatibility problems, but I think it will be more helpful > > than simply trying to use various ports and failing to get media through > > without any feedback as to why. > > Is there really a problem? The revised text says that ports MAY be > selected without the even/odd constraint if both the RTP and RTCP port > numbers are specified explicitly. In applications where only one port > is specified and the other is implicitly derived from the first, then > the implementation must be assuming some rule for their relationship. > I can't see any motivation for an implementation to make up some > different rule rather than using the one the draft says SHOULD be > used. > > The real backwards compatibility problems that I see have to do with > entities that may process RTP and/or RTCP packets without being party > to the session establishment protocol. Examples would be a > third-party RTCP monitor and an RTP header compression box. These > entities won't be able to rely on RTCP being on an odd port. However, > we agreed to accept this backwards incompatibility liability because > NAT boxes forced us to accept port translations we could not control. > > By the way, I am happy to see that you are reading the draft and > thinking carefully about the changes. > -- Steve > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Wed Feb 20 22:01:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27595 for ; Wed, 20 Feb 2002 22:01:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08477 for avt-archive@odin.ietf.org; Wed, 20 Feb 2002 22:01:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08454; Wed, 20 Feb 2002 22:00:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08424 for ; Wed, 20 Feb 2002 22:00:50 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27581 for ; Wed, 20 Feb 2002 22:00:45 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id g1L300p02091; Wed, 20 Feb 2002 19:00:00 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 20 Feb 2002 19:03:17 -0800 (PST) From: Stephen Casner To: "Paul E. Jones" cc: Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt In-Reply-To: <036001c1ba5c$24d7e210$745f6640@cisco.com> Message-ID: <20020220183954.C57094-100000@ash.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Paul, > As you pointed out, the real concern are the boxes in the middle. Most > endpoints (note "most") can properly handle RTP/RTCP ports with no specific > association. Perhaps not even most. Those that use SDP per RFC 2327 for signaling do not have a way to express the RTCP port number separately. > However, I have seen some implementations (NATs, proxies, and > real endpoints) wherein there was an assumed association. H.323 actually > does allow one to signal separate RTP and RTCP port numbers, but some > implementations just ignore the RTCP port number field, assuming that the > odd/even rule exists. That sounds like an implementation bug -- not following the H.323 spec. If those implementations want to uphold the even/odd requirement in RFC 1889, then they should refuse the connection when the RTCP port number field does not comply. > RFC 2327 (SDP) states quite clearly that the m= line contains the RTP port > and that the RTCP port is assumed. I know this is subject to change, as > well, but we also have the compatibility problems. Proposals to extend SDP in this regard have been made. > I certainly do not > object to making such as change, as it would align with H.323. Nonetheless, > I think the "capability" of supporting something other than even/odd ports > should be advertised so that entities can properly inform users or network > operators of such issues. Here's where we run into trouble. "Advertised" to whom and with what protocol? An RTP header compressor box in the middle is not party to any signaling protocol. > In the RTP draft, I'd be quite happy with removing the odd/even requirement > (SHOULD is fine), so long as there is also a statement that says that when > RTP is used without even/odd port paring, that the session applications MUST > negotiate the usage of non-even/odd ports. The existing statement is something like the contrapositive of that statement: For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. We could follow that with a restatement in the same direction as yours: Applications using RTP and RTCP destination port numbers that are not an even/odd port pair MUST specify both port numbers via explicit, separate parameters (using a signaling protocol or other means). However, that seems like stating the obvious: if the RTCP port number can't be inferred from the RTP port number, then you have to tell the program what RTCP port number to use. Do we need to say this? Note that my restatement differs from your statement in a subtle way: the RTP spec can't specify what a "session application" will do nor make any assumption that a signaling protocol will be used. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Thu Feb 21 07:00:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13983 for ; Thu, 21 Feb 2002 07:00:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15332 for avt-archive@odin.ietf.org; Thu, 21 Feb 2002 07:00:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14916; Thu, 21 Feb 2002 06:59:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14891 for ; Thu, 21 Feb 2002 06:59:45 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13727; Thu, 21 Feb 2002 06:59:42 -0500 (EST) Message-Id: <200202211159.GAA13727@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: Thu, 21 Feb 2002 06:59:42 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 : The MIDI Wire Protocol Packetization (MWPP) Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-01.txt Pages : 24 Date : 20-Feb-02 This memo describes the MIDI Wire Protocol Packetization (MWPP). MWPP is a resilient RTP packetization for the MIDI wire protocol. MWPP defines a multicast-compatible recovery journal format, to support the graceful recovery from lost packets during a MIDI session. MWPP is compatible with the MPEG-4 generic RTP payload format, to support MPEG 4 Audio codecs that accept MIDI control input. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-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-mwpp-midi-rtp-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-mwpp-midi-rtp-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: <20020220134640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mwpp-midi-rtp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020220134640.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Thu Feb 21 14:17:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00316 for ; Thu, 21 Feb 2002 14:17:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21153 for avt-archive@odin.ietf.org; Thu, 21 Feb 2002 14:17:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21019; Thu, 21 Feb 2002 14:13:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20990 for ; Thu, 21 Feb 2002 14:13:40 -0500 (EST) Received: from paris.packetizer.org (system@rdu26-244-205.nc.rr.com [66.26.244.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00194 for ; Thu, 21 Feb 2002 14:13:36 -0500 (EST) Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id g1LJEkY04772; Thu, 21 Feb 2002 14:14:47 -0500 Message-ID: <012001c1bb0b$ecc76750$745f6640@cisco.com> From: "Paul E. Jones" To: "Stephen Casner" Cc: References: <20020220183954.C57094-100000@ash.packetdesign.com> Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt Date: Thu, 21 Feb 2002 14:14:02 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 7bit Steve, When I mentioned "most" endpoints, I was limiting that to H.323... sorry: I should have been more explicit. H.323 allows RTP and RTCP ports numbers to be signaled, but the text also requires that the ports be even/odd paired: there was no deviation made from RFC 1889. As such, some implementation simply ignore the extra fields and some applications do not include them. Of course, there have always been questions as to whether those fields were needed in the first place... indeed, according to RFC 1889, they were not. > The existing statement is something like the contrapositive of that > statement: > > For applications in which the RTP and RTCP destination port numbers > are specified via explicit, separate parameters (using a signaling > protocol or other means), the application MAY disregard the > restrictions that the port numbers be even/odd and consecutive > although the use of an even/odd port pair is still encouraged. I have a hard time with this, since the text preceeding this in the draft now includes the word SHOULD. To say that an endpoint SHOULD use even/odd pair means that it is not required to do so. This part of the paragraph is perfectly fine to me if we remove the SHOULD text from the ealier part of the paragraph. > We could follow that with a restatement in the same direction as > yours: > > Applications using RTP and RTCP destination port numbers that are > not an even/odd port pair MUST specify both port numbers via > explicit, separate parameters (using a signaling protocol or other > means). > > However, that seems like stating the obvious: if the RTCP port number > can't be inferred from the RTP port number, then you have to tell the > program what RTCP port number to use. Do we need to say this? I agree with you: I have no objections to this text, but I'm not sure that it adds any value. What I would prefer to have is something like this: --------- RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even destination port number and the corresponding RTCP stream uses the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application MUST replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams. --------- I have simply removed the SHOULD text, which retains backward compatibility, but opens the door for external signaling to use other port numbers. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Thu Feb 21 15:36:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02891 for ; Thu, 21 Feb 2002 15:36:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24622 for avt-archive@odin.ietf.org; Thu, 21 Feb 2002 15:36:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24497; Thu, 21 Feb 2002 15:32:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24461 for ; Thu, 21 Feb 2002 15:32:06 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.45.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02707 for ; Thu, 21 Feb 2002 15:31:59 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id MAA19338 for avt@ietf.org; Thu, 21 Feb 2002 12:30:06 -0800 Date: Thu, 21 Feb 2002 12:30:06 -0800 From: John Lazzaro Message-Id: <200202212030.MAA19338@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] MWPP-01.txt notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org > From: Internet-Drafts@ietf.org > Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-01.txt A quick synopsis of the changes: o The MIDI command section now encodes all legal MIDI commands, including all MIDI Systems commands. o The MIDI command section header has new features to support the efficient streaming of pre-generated MIDI performances. o A new SDP parameter (pwe) indicates that a stream is suitable for use in pseudo-wire emulation. o Changes in response to Dominique Fober's AVT postings. Basically, at this point, for applications where the recovery journal isn't needed (TCP transport) MWPP is done -- if you see any MIDI functionality which is unencodable in the MIDI Command Section of MWPP, its a bug we need to fix. Major remaining work items include: o A redesign of Chapter C of the recovery journal, to handle the semantics of all 128 controllers of the MIDI Control Change command. Will probably include the creation of a new recovery journal chapter for Registered/Non-Registered Parameter Numbers, since the Chapter C format is unsuitable for resiliency for this feature. o Resiliency guidelines for MIDI Systems. A significant subset is amenable to recovery journal techniques, the rest requires the hooks for an "other means" resiliency, which for unicast could be as simple as a separate TCP MWPP link dedicated to the bulk transport aspects of MIDI Systems which are unsuitable for UDP streaming. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Sun Feb 24 12:32:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13851 for ; Sun, 24 Feb 2002 12:32:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19664 for avt-archive@odin.ietf.org; Sun, 24 Feb 2002 12:32:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19151; Sun, 24 Feb 2002 12:28:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19123 for ; Sun, 24 Feb 2002 12:28:27 -0500 (EST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13773 for ; Sun, 24 Feb 2002 12:28:18 -0500 (EST) Received: from VAIOStW2.cs.tu-berlin.de (root@kuerbis.cs.tu-berlin.de [130.149.25.60]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id SAA23157; Sun, 24 Feb 2002 18:27:54 +0100 (MET) Message-Id: <5.1.0.14.2.20020224181045.02ad9c80@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 18:27:09 +0100 To: avt@ietf.org From: Stephan Wenger Cc: thomas Stockhammer , miska.hannuksela@nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] New I-D on JVT/H.26L packetization Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Folks, My new draft for an RTP packetization scheme for JVT video (aka H.26L, aka forthcoming MPEG-4 Part 10) is now available from the I-D archives as ftp://ftp.ietf.org/internet-drafts/draft-wenger-avt-rtp-jvt-00.txt. This draft is under development by Tom, Miska, and myself since quite some time. It is submitted by the authors, and not on behalf of the whole JVT group, as there are people in this group who would prefer to see an approach that is more aligned with other payload specifications, particularly with the MPEG-4 multisl draft. While we have had more than 10 turnaround between us authors, this is still a true -00 draft, with a lot of known (and undoubtly many unknown) problems. Any help on spotting and solving such problems is, as usual, appreciated. Also, the video coding standard, and particularly the Network Adpatation Layer is not yet set in stone, and we hope to receive valuable input at the AVT meeting to make the video coding itself more network friendly. One of the key problems of the development (and the review) of this draft is that JVT doesn't have a complete, accurate, and up-to-date description of the video syntax, or, more precisely, the syntax of the Network Adaptation Layer. A document describing this syntax and the rationales behind it is currently in preparation, and I will advise you on this mailing list as soon as it is available. For now, the references in the draft will have to suffice. Best regards Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Sun Feb 24 16:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16299 for ; Sun, 24 Feb 2002 16:43:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28733 for avt-archive@odin.ietf.org; Sun, 24 Feb 2002 16:43:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28707; Sun, 24 Feb 2002 16:43:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28678 for ; Sun, 24 Feb 2002 16:43:16 -0500 (EST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16292 for ; Sun, 24 Feb 2002 16:43:13 -0500 (EST) Received: from VAIOStW2.cs.tu-berlin.de (root@kuerbis.cs.tu-berlin.de [130.149.25.60]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id WAA20680 for ; Sun, 24 Feb 2002 22:38:38 +0100 (MET) Message-Id: <5.1.0.14.2.20020224223545.02b23378@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 22:38:34 +0100 To: avt@ietf.org From: Stephan Wenger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] JVT packetization, first bug :-) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Thanks to Marshall Eubanks I'm unhappy to report the first bug. The URL for the reference [2], JVT working draft, is woring. Hereis the correct reference URL: ftp://standard.pictel.com/video-site/h26L/jwd1r1.doc Sorry for any inconvenience. Best regards Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Mon Feb 25 16:58:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01470 for ; Mon, 25 Feb 2002 16:58:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20321 for avt-archive@odin.ietf.org; Mon, 25 Feb 2002 16:58:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20259; Mon, 25 Feb 2002 16:57:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20229 for ; Mon, 25 Feb 2002 16:57:21 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01431 for ; Mon, 25 Feb 2002 16:57:17 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1PLvIS24853; Mon, 25 Feb 2002 16:57:18 -0500 Message-Id: <200202252157.g1PLvIS24853@chiron.nge.isi.edu> To: avt@ietf.org, casner@acm.org Subject: Re: [AVT] AVT meeting in Minneapolis In-Reply-To: Your message of "Mon, 18 Feb 2002 20:50:10 EST." <200202190150.g1J1oAC01305@purple.nge.isi.edu> Date: Mon, 25 Feb 2002 16:57:18 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org A reminder that updates to existing Internet drafts are due this Friday, March 1st, at 5:00pm EST. Drafts which do not make the cutoff date will not be discussed at the meeting. Those wanting agenda time should contact the working group chairs as soon as possible. Note that the draft IETF agenda now has AVT meeting at 3:30-5:30pm on Monday and 3:30-5:30pm on Wednesday. Colin --> Colin Perkins writes: >Folks, > >The AVT working group is scheduled for two slots at the 53rd IETF meeting >in Minneapolis. On the tentative agenda, these are 9:00 to 11:30am on >Wednesday 20th March and 1:00 to 3:00pm on Thursday 21st 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 4th March. > >You are reminded that the cut-off date for -00 Internet Draft submissions >is Friday, February 22nd, 5:00pm EST. Unless you have prior approval from >the working group chairs, -00 submissions should have filenames with the >format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts >received after February 22nd will not be accepted. > >All other Internet-Draft submissions must be made by Friday, March 1st, at >5:00pm EST. Drafts which do not make the cutoff date will not be discussed >at the meeting. > >Colin > >_______________________________________________ >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 daemon@optimus.ietf.org Tue Feb 26 07:08:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24866 for ; Tue, 26 Feb 2002 07:08:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08794 for avt-archive@odin.ietf.org; Tue, 26 Feb 2002 07:08:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08264; Tue, 26 Feb 2002 07:01:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08227 for ; Tue, 26 Feb 2002 07:01:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23729; Tue, 26 Feb 2002 07:01:25 -0500 (EST) Message-Id: <200202261201.HAA23729@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, 26 Feb 2002 07:01:24 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-mpeg4-multisl-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org --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 MPEG-4 Streams Author(s) : C. Perkins et al. Filename : draft-ietf-avt-mpeg4-multisl-04.txt Pages : 56 Date : 25-Feb-02 This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mpeg4-multisl-04.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-multisl-04.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-multisl-04.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: <20020225142327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mpeg4-multisl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mpeg4-multisl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225142327.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From daemon@optimus.ietf.org Tue Feb 26 08:39:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28740 for ; Tue, 26 Feb 2002 08:39:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12916 for avt-archive@odin.ietf.org; Tue, 26 Feb 2002 08:39:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12729; Tue, 26 Feb 2002 08:32:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12686 for ; Tue, 26 Feb 2002 08:32:18 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28445 for ; Tue, 26 Feb 2002 08:32:12 -0500 (EST) From: Eva.Kunstelj@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QDWNZ29168 for ; Tue, 26 Feb 2002 15:32:23 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 15:32:14 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 15:32:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 26 Feb 2002 15:32:13 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB702C379@esebe019.NOE.Nokia.com> Thread-Topic: Comments on draft-ietf-avt-srtp-02.txt Thread-Index: AcG+yeSNmG1ZjrL7SM27mvcc20n87Q== To: Cc: X-OriginalArrivalTime: 26 Feb 2002 13:32:14.0095 (UTC) FILETIME=[004F41F0:01C1BECA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA12688 Subject: [AVT] Comments on draft-ietf-avt-srtp-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit Hi, some questions and comments on draft-ietf-avt-srtp-02.txt: (1) In section 3.1: "Each SRTP session requires the sender and receiver to maintain cryptographic state information. This information is called the cryptographic context." I guess that means that each of them (sender & receiver) needs to maintain one? (2) In section 3.2: "4. Encrypt the Encrypted Portion of the packet (see Section 4, for the defined ciphers), using the encryption keys found in Step 3." Encrypt the Encrypted Portion of the packet: Is it not so, that this portion first has to be encrypted, and after that it can be named 'Encrypted Portion'? Anyway this name 'Encrypted Portion' is used for the SRTP packet, and not RTP packet? Before a packet is entering transformation, is it not basically still RTP packet? Can we say that we are encrypting the 'Encrypted Portion' of the packet even though our packet is in this case still RTP packet and therefore doesn't have the encrypted portion yet? Same also for the authentication under Step 5. (3) In section 4.3.1: "PRF_m^n(k_master,