From avt-bounces@ietf.org Mon Oct 01 04:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGNp-0002ln-1q; Mon, 01 Oct 2007 04:12:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGNn-0001kv-2S for avt@ietf.org; Mon, 01 Oct 2007 04:12:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGNj-00032w-AD for avt@ietf.org; Mon, 01 Oct 2007 04:11:59 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 112DF200DD for ; Mon, 1 Oct 2007 10:11:15 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-fd-4700aba2edef Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EACCB20571 for ; Mon, 1 Oct 2007 10:11:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 10:11:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 10:11:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Offer/answer questions on RFC 4585 Thread-Index: Acf6nevN92RI54DBTDShiT2WcHTWpQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 01 Oct 2007 08:11:14.0470 (UTC) FILETIME=[A29CF460:01C80402] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.8 (+) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [AVT] Offer/answer questions on RFC 4585 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0607608417==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0607608417== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80402.A2A8DEB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80402.A2A8DEB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a couple of questions on RFC 4585, regarding the usage with = offer/answer. =20 My FIRST question is: are there any TECHNICAL reasons (I know it's = probably not allowed by RFC 3264) why a user receiving an AVPF offer, = but doesn't support it, can't reply with AVP answer (instead of = rejecting the stream)? My understanding is that if you offer AVPF you = still have to be able to do AVP, so... =20 (The receiver of course needs to understand the "AVPF" string in the = SDP) =20 =20 My SECOND question is on example 3 in chapter 4.4. The RFC shows two = m=3Dvideo lines (one AVPF and one AVP) with the SAME port number = (51372), and says that an appropriate grouping mechanism should be used = to group the AVPF and AVP alternatives. =20 However, I believe that even if you use some grouping mechanism, you are = still not allowed to use the same port number in two m=3D lines. There = has been much discussion about this on the MMUSIC list, but as far as I = know that rule hasn't been changed. I assume this would be only an = editorial bug? =20 Regards, =20 Christer ------_=_NextPart_001_01C80402.A2A8DEB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Hi,
=0A=
 
=0A=
I have a couple of questions on RFC = 4585, regarding the usage with offer/answer.
=0A=
 
=0A=
My FIRST question is: are there = any TECHNICAL reasons (I know it's probably not allowed by RFC 3264) why = a user receiving an AVPF offer, but doesn't support it, can't reply with = AVP answer (instead of rejecting the stream)? My understanding is that = if you offer AVPF you still have to be able to do AVP, so...
=0A=
 
=0A=
(The receiver of course needs to = understand the "AVPF" string in the SDP)
=0A=
 
=0A=
 
=0A=
=0A=
My SECOND question is on example 3 = in chapter 4.4. The RFC shows two m=3Dvideo lines (one AVPF and one = AVP) with the SAME port number (51372), and says that = an appropriate grouping mechanism should be used to group the AVPF = and AVP alternatives.
=0A=
 
=0A=
However, I believe that even if you use = some grouping mechanism, you are still not allowed to use the same port = number in two m=3D lines. There has been much discussion about this on = the MMUSIC list, but as far as I know that rule hasn't been changed. I = assume this would be only an editorial bug?
=0A=
 
=0A=
Regards,
=0A=
 
=0A=
Christer
=0A= =0A= ------_=_NextPart_001_01C80402.A2A8DEB2-- --===============0607608417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0607608417==-- From avt-bounces@ietf.org Mon Oct 01 14:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPtX-0006jw-Qv; Mon, 01 Oct 2007 14:21:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPtV-0006Kr-Mz for avt@ietf.org; Mon, 01 Oct 2007 14:21:25 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcPtQ-0002Bs-73 for avt@ietf.org; Mon, 01 Oct 2007 14:21:20 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 14:21:19 -0400 To: "Christer Holmberg" Subject: Re: [AVT] Offer/answer questions on RFC 4585 References: From: Randell Jesup Date: Mon, 01 Oct 2007 14:21:18 -0400 In-Reply-To: (Christer Holmberg's message of "Mon, 1 Oct 2007 10:11:13 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Oct 2007 18:21:19.0258 (UTC) FILETIME=[DCC457A0:01C80457] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Christer Holmberg" writes: >I have a couple of questions on RFC 4585, regarding the usage with offer/answer. > >My FIRST question is: are there any TECHNICAL reasons (I know it's >probably not allowed by RFC 3264) why a user receiving an AVPF offer, but >doesn't support it, can't reply with AVP answer (instead of rejecting the >stream)? My understanding is that if you offer AVPF you still have to be >able to do AVP, so... > >(The receiver of course needs to understand the "AVPF" string in the SDP) That probably violates a number of the offer-answer MUSTs, but technically it certainly can be handled. From Section 5: AVP and AVPF are defined in a way that, from a robustness point of view, the RTP entities do not need to be aware of entities of the respective other profile: they will not disturb each other's functioning. However, the quality of the media presented may suffer. and the rest of section 5 in general addresses this point, though not head-on. (Section 5 is obviously written with non-point-to-point uses in mind, where each participant may have accepted one or the other). >My SECOND question is on example 3 in chapter 4.4. The RFC shows two >m=video lines (one AVPF and one AVP) with the SAME port number (51372), >and says that an appropriate grouping mechanism should be used to group >the AVPF and AVP alternatives. > >However, I believe that even if you use some grouping mechanism, you are >still not allowed to use the same port number in two m= lines. There has >been much discussion about this on the MMUSIC list, but as far as I know >that rule hasn't been changed. I assume this would be only an editorial >bug? > RFC 4566: The semantics of multiple "m=" lines using the same transport address are undefined. This implies that, unlike limited past practice, there is no implicit grouping defined by such means and an explicit grouping framework (for example, [18]) should instead be used to express the intended semantics. The "limited past practice" probably refers to people ad-hoc using identical ports as a way of saying "accept a or b but not both". The older RFC for SDP didn't mention it. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 01 18:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTeT-00041U-44; Mon, 01 Oct 2007 18:22:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTeR-0003lG-SF for avt@ietf.org; Mon, 01 Oct 2007 18:22:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcTeR-00078t-9W for avt@ietf.org; Mon, 01 Oct 2007 18:22:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,218,1188802800"; d="scan'208";a="228555192" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Oct 2007 15:22:06 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l91MM6H1023847; Mon, 1 Oct 2007 15:22:06 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l91MM1vP029084; Mon, 1 Oct 2007 22:22:01 GMT From: "Dan Wing" To: "'Randell Jesup'" , "'Christer Holmberg'" References: Subject: RE: [AVT] Offer/answer questions on RFC 4585 Date: Mon, 1 Oct 2007 15:22:01 -0700 Message-ID: <048f01c80479$80067580$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: AcgEWgxNu9Dl3nvKT1qKmBB0i4S3zAAHp9Aw In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3825; t=1191277326; x=1192141326; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[AVT]=20Offer/answer=20questions=20on=20RFC=204585 |Sender:=20; bh=qW/U1oAferYUEwLe3DqryBm6/Z1WHM4Gut7IcsGG0ic=; b=GyU0R6oVKDhxotUejF0NoZGlMdXAu1hV1qCo0fVu3tTBN2HGVIyFvaHl0rL94NuTnCX7zQbe KhWPukXKzzk3ts16hqa36/axPscGVrVKyKzqEN1HFUfGYcHirQm2gCIO; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org >"Christer Holmberg" writes: >>I have a couple of questions on RFC 4585, regarding the usage with >>offer/answer. >> >>My FIRST question is: are there any TECHNICAL reasons (I know it's >>probably not allowed by RFC 3264) why a user receiving an AVPF offer, but >>doesn't support it, can't reply with AVP answer (instead of rejecting the >>stream)? My understanding is that if you offer AVPF you still have to be >>able to do AVP, so... >> >>(The receiver of course needs to understand the "AVPF" string in the SDP) > That probably violates a number of the offer-answer MUSTs, > but technically it certainly can be handled. From Section 5: > > AVP and AVPF are defined in a way that, from a robustness point of > view, the RTP entities do not need to be aware of entities of the > respective other profile: they will not disturb each other's > functioning. However, the quality of the media presented may > suffer. > > and the rest of section 5 in general addresses this point, > though not head-on. (Section 5 is obviously written with non-point- > to-point uses in mind, where each participant may have accepted > one or the other). The better way to handle this is to use SDP capability negotiation (draft-ietf-mmusic-sdp-capability-negotiation) which doesn't require the answerer to understand the "F" of "AVPF" at all. Using SDP capability negotiation is more robust and allows much cleaner fallback. > >My SECOND question is on example 3 in chapter 4.4. The RFC shows two > >m=video lines (one AVPF and one AVP) with the SAME port > >number (51372), > >and says that an appropriate grouping mechanism should be > >used to group the AVPF and AVP alternatives. > > > >However, I believe that even if you use some grouping > >mechanism, you are > >still not allowed to use the same port number in two m= > >lines. There has > >been much discussion about this on the MMUSIC list, but as > >far as I know > >that rule hasn't been changed. I assume this would be only > >an editorial bug? > > RFC 4566: > > The semantics of multiple "m=" lines using the same transport > address are undefined. This implies that, unlike limited past > practice, there is no implicit grouping defined by such > means and > an explicit grouping framework (for example, [18]) > should instead > be used to express the intended semantics. > > The "limited past practice" probably refers to people ad-hoc using > identical ports as a way of saying "accept a or b but not > both". I agree, that is probably what it was referring to. However, its reference to [18] (RFC3388) doesn't provide the escape clause that the authors of RFC4566 intended. Specifically, RFC3388 says this about using the same transport address: "7.5.3 Same IP Address and Port Number If several codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used. FID MUST NOT be used to group "m" lines with the same IP address/port. Therefore, an SDP like the one below MUST NOT be generated. v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30000 RTP/AVP 8 a=mid:2 The correct SDP for the session above would be the following one: v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 m=audio 30000 RTP/AVP 0 8 If two "m" lines are grouped using FID they MUST differ in their transport addresses (i.e., IP address plus port)." -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 02 03:26:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icc66-0005mn-T1; Tue, 02 Oct 2007 03:23:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icc64-0004sR-Ud for avt@ietf.org; Tue, 02 Oct 2007 03:23:13 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icc5x-00028k-93 for avt@ietf.org; Tue, 02 Oct 2007 03:23:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] Offer/answer questions on RFC 4585 Date: Tue, 2 Oct 2007 09:24:35 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04F08B8F@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/answer questions on RFC 4585 Thread-Index: Acf6nevN92RI54DBTDShiT2WcHTWpQKJnY5Q From: "Even, Roni" To: "Christer Holmberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0858657344==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0858657344== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C804C5.488EA1A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C804C5.488EA1A4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Christer, Inline =20 ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, October 01, 2007 10:11 AM To: avt@ietf.org Subject: [AVT] Offer/answer questions on RFC 4585 =20 Hi, =20 I have a couple of questions on RFC 4585, regarding the usage with = offer/answer. =20 My FIRST question is: are there any TECHNICAL reasons (I know it's = probably not allowed by RFC 3264) why a user receiving an AVPF offer, = but doesn't support it, can't reply with AVP answer (instead of = rejecting the stream)? My understanding is that if you offer AVPF you = still have to be able to do AVP, so... =20 (The receiver of course needs to understand the "AVPF" string in the = SDP) =20 [RE:] I think that is this case the offer will include a=3Drtcp-fb = with rtcp-fb-vals. Since the receiver understands AVPF but do not = support any feedback message it will remove all rtcp-fb-val in the = answers. To me that looks like support of AVP so why do you want to change the = avpf to avp. =20 =20 My SECOND question is on example 3 in chapter 4.4. The RFC shows two = m=3Dvideo lines (one AVPF and one AVP) with the SAME port number = (51372), and says that an appropriate grouping mechanism should be used = to group the AVPF and AVP alternatives =20 However, I believe that even if you use some grouping mechanism, you are = still not allowed to use the same port number in two m=3D lines. There = has been much discussion about this on the MMUSIC list, but as far as I = know that rule hasn't been changed. I assume this would be only an = editorial bug? [RE:] Yes =20 Regards, =20 Christer =20 ------_=_NextPart_001_01C804C5.488EA1A4 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Christer,

Inline

 

From: = Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, October 01, = 2007 10:11 AM
To: avt@ietf.org
Subject: [AVT] = Offer/answer questions on RFC 4585

 

Hi,

 

I have a couple of questions on RFC 4585, regarding = the usage with offer/answer.

 

My FIRST question is: are there any TECHNICAL = reasons (I know it's probably not allowed by RFC 3264) why a user receiving an = AVPF offer, but doesn't support it, can't reply with AVP answer (instead of rejecting the stream)? My understanding is that if you offer AVPF you = still have to be able to do AVP, so...

 

(The receiver of course needs to understand the "AVPF" string in the SDP)

 

[RE:] =A0I think that is this case the offer =A0will = include a=3Drtcp-fb with rtcp-fb-vals. Since the receiver understands AVPF but do not = support any feedback message it will remove all rtcp-fb-val in the = answers.

To me that looks like support of AVP so why do you = want to change the avpf to avp.

 

 

My SECOND question is on example = 3 in chapter 4.4. = The RFC shows two m=3Dvideo lines (one AVPF and one AVP) with the SAME port = number (51372), and says that an appropriate grouping mechanism = should be used to group the AVPF and AVP alternatives

 

However, I believe that even if you use some grouping mechanism, you are still not allowed to use the same port number in two = m=3D lines. There has been much discussion about this on the MMUSIC list, but = as far as I know that rule hasn't been changed. I assume this would be only an editorial bug?

[RE:] Yes

 

Regards,

 

Christer

 

------_=_NextPart_001_01C804C5.488EA1A4-- --===============0858657344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0858657344==-- From avt-bounces@ietf.org Tue Oct 02 08:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgct-0005Lk-RJ; Tue, 02 Oct 2007 08:13:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgcs-0005Lf-VU for avt@ietf.org; Tue, 02 Oct 2007 08:13:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icgcs-0001OV-Em for avt@ietf.org; Tue, 02 Oct 2007 08:13:22 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1BCB221121 for ; Tue, 2 Oct 2007 14:13:20 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-ca-470235e032d4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 046BE2102C for ; Tue, 2 Oct 2007 14:13:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 14:13:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/answer questions on RFC 4585 Date: Tue, 2 Oct 2007 14:13:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [AVT] Offer/answer questions on RFC 4585 Thread-Index: AcgE7Z5rzGaYvf0KStei+LHD/qwFkQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 02 Oct 2007 12:13:19.0859 (UTC) FILETIME=[9ED52C30:01C804ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi Roni, >>I have a couple of questions on RFC 4585, regarding the usage with offer/answer. >> >>My FIRST question is: are there any TECHNICAL reasons (I know it's probably not allowed by RFC 3264) why a user receiving an AVPF offer, but doesn't=20 >>support it, can't reply with AVP answer (instead of rejecting the stream)? My understanding is that if you offer AVPF you still have to be able to do=20 >>AVP, so... >>(The receiver of course needs to understand the "AVPF" string in the SDP) >[RE:] I think that is this case the offer will include a=3Drtcp-fb with rtcp-fb-vals. Since the receiver understands AVPF but do not support any feedback=20 >message it will remove all rtcp-fb-val in the answers. >To me that looks like support of AVP so why do you want to change the avpf to avp. Ok, if it works that way. So, if I have an MGCF/MGW I can do the following: - The MGCF answers with AVPF, but without rtcp-fb-val - The MGCF sends AVP down to the MGW (e.g using H.248) Regards, Christer _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 02 11:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjIA-0001DO-2r; Tue, 02 Oct 2007 11:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjI8-0001DD-Qq for avt@ietf.org; Tue, 02 Oct 2007 11:04:08 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcjI2-0004DC-KN for avt@ietf.org; Tue, 02 Oct 2007 11:04:08 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:52179) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IcjHr-0005v7-RW for avt@ietf.org; Tue, 02 Oct 2007 16:03:51 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E5DE7BC-BA9E-4919-855C-BAA6B20A1010@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Working group last call: draft-ietf-avt-rfc3119bis-05.txt Date: Tue, 2 Oct 2007 16:03:49 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 4 Sep 2007, at 10:47, Colin Perkins wrote: > This is to announce a working group last call on the More Loss- > Tolerant RTP Payload Format for MP3 Audio (draft-ietf-avt- > rfc3119bis-05.txt). This draft corrects some minor mistakes in RFC > 3119 (see http://tinyurl.com/2c757d for details of the changes). > > Please send any final comments on this draft to the list by 17 > September 2007. If no substantive issues are raised by that time, > we will request the IESG consider this for publication as a > Proposed Standard RFC, making RFC 3119 obsolete. This working group last call has concluded. There were no objections, therefore we will send this document to the IESG for publication. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 03 22:06:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdG32-0001qA-Qx; Wed, 03 Oct 2007 22:02:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdG31-0001V5-G4 for avt@ietf.org; Wed, 03 Oct 2007 22:02:43 -0400 Received: from smtp102.rog.mail.re2.yahoo.com ([206.190.36.80]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdG2w-000732-36 for avt@ietf.org; Wed, 03 Oct 2007 22:02:38 -0400 Received: (qmail 15649 invoked from network); 4 Oct 2007 02:02:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bmPiux4HHXQnTCaakiVp00LXRzIfIMajhM+Gg+x2ZlG+1XK2ktAZpriX8Ri21PpF6c/CAXFHH6mPkiq1idOw3ZzpUteMKo2voUn3ncaxwjtxLEbtDRdVAzU1fywCNKQAhbl9vSPu4caNFf8EJpFgBLzzdpXLWMWSCVNSy62lnUE= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 4 Oct 2007 02:02:37 -0000 X-YMail-OSG: Z5UMrpMVM1lR9wewWkCMZTz3fQ9qIWZmjcA_IjMG56OoI6HIXJOz1dndu79JIUWfaQ-- Message-ID: <470449BC.50603@rogers.com> Date: Wed, 03 Oct 2007 22:02:36 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF AVT WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Cullen Jennings , avt-chairs@tools.ietf.org Subject: [AVT] Open issue on hdrext draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Before the header extension draft can be approved we have to settle two or three points that have been raised after the document passed WGLC. One of them is the view of the Working Group regarding registration requirements. Is it the Working Group's intention that: (a) any SDO can standardize and register a new RTP header extension without IETF review or consent; or (b) all RTP header extensions require review and agreement by an IETF expert before they can be registered; or (c) all RTP header extensions require IETF consensus before they can be registered. David Singer had a clear view on this question when he wrote the document in the first place. I should let him speak for himself, but his basic idea was to encourage registration as an alternative to hard-to-get-rid-of experimental identifiers, by making registration a simple process. His preference was thus toward alternative (a). Last time we didn't ask the question in quite these stark terms, and only Magnus replied. It's hard to read a consensus from that. Would other people care to comment? Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 00:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdI8K-0005WS-43; Thu, 04 Oct 2007 00:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdI8J-0005WM-4D for avt@ietf.org; Thu, 04 Oct 2007 00:16:19 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdI8D-0006Sp-KZ for avt@ietf.org; Thu, 04 Oct 2007 00:16:19 -0400 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id DB63213F4830; Wed, 3 Oct 2007 21:15:59 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id BDE7928085; Wed, 3 Oct 2007 21:15:59 -0700 (PDT) X-AuditID: 11807134-a6e95bb000000861-ae-470468ffe367 Received: from [17.202.37.243] (unknown [17.151.102.186]) by relay14.apple.com (Apple SCV relay) with ESMTP id E974728050; Wed, 3 Oct 2007 21:15:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <470449BC.50603@rogers.com> References: <470449BC.50603@rogers.com> Date: Wed, 3 Oct 2007 21:14:33 -0700 To: Tom Taylor , IETF AVT WG From: Dave Singer Subject: Re: [AVT] Open issue on hdrext draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Cullen Jennings , avt-chairs@tools.ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I don't know if it helps, but in case it does, it might help if I 'frame' the question and provide some history and rationale for the current state. See below, after Tom's questions... At 22:02 -0400 3/10/07, Tom Taylor wrote: >Before the header extension draft can be approved we have to settle >two or three points that have been raised after the document passed >WGLC. One of them is the view of the Working Group regarding >registration requirements. > >Is it the Working Group's intention that: > >(a) any SDO can standardize and register a new RTP header extension >without IETF >review or consent; or > >(b) all RTP header extensions require review and agreement by an IETF expert >before they can be registered; or > >(c) all RTP header extensions require IETF consensus before they can >be registered. > >David Singer had a clear view on this question when he wrote the >document in the first place. I should let him speak for himself, but >his basic idea was to encourage registration as an alternative to >hard-to-get-rid-of experimental identifiers, by making registration >a simple process. His preference was thus toward alternative (a). > >Last time we didn't ask the question in quite these stark terms, and >only Magnus replied. It's hard to read a consensus from that. Would >other people care to comment? The current RTP specification makes provision for header extensions. However, there is no process defined to identify them, or register identifiers. Indeed, the 16-bit field that might be thought of as a label in the RTP packets is not clearly defined as such, and there is no registration or documentation process defined for it. This has led some to believe that they can use it as they wish, and others to believe that it is unusable. The header extension draft has been before this group since the latter part of 2005. It defines a way to pack multiple header extensions into a packet, and defines a way for them to be labelled. Initial drafts used reverse domain names (kind of like Java), and later ones moved to using URIs for the labelling. The question has arisen as to what requirements there should be around the documentation and registration of header extensions. Currently the draft says that IANA will provide a registry, but only for IANA-form URNs, and that to use an IANA-form URN, the extension must be defined in a standards-track RFC. This leaves open, of course, the ability of anyone who can make a URI (URL or URN) to define and use a header extension. Historically, IETF specs (including those from this WG) have had features or fields defined by 'simple names' that are registered, often with provision for an experimental X- prefix. I think we've all observed cases where X- names become by common usage, even with the risk of collision and lack of registration that they suffer from. Clearly, in cases where interop is important, the use of formats or labels for which either the registration or documentation cannot be assured to be found is undesirable, to the point that specifications are usually written to discourage this state. However, header extensions are defined in RTP (and this is re-inforced by the header extension draft) to be ignorable. It is an absolute requirement that the interoperability of an RTP stream cannot be affected by the presence or absence of an extension (though, of course, its utility might, or it's hard to see what the extension is doing). This led to the current design and status: there would be 'preferred, vetted' extensions, defined in RFCs, using IANA URN names. But those needing to experiment, or develop an extension for a more restricted environment etc., would be able to use other URIs to label them, without running risk of collision, and without running the risk of an interop problem with systems that were written either without knowledge of that extension, or indeed, without knowledge of this header extension mechanism at all (i.e. using only RFC 3550 or 1889). The author(s) saw this state as preferable to the 'x-' method, in this case. So, I guess I'd like to know whether there are other considerations that should be taken into account. Then, here are some more worked-out questions from Tom's various choices: a) whether the current 'two tier' state, using URIs with an IANA registry for RFC-defined extensions is acceptable; b.i) whether IANA should be asked to document the mapping from any URI to a publicly available specification; b.ii) whether, in order to be entered into such a registry, some IETF process such as expert review should be required; b.iii) whether the 'official' extensions should be considered only those registered at IANA; b.iv) or whether we should move to a simple name system, with IANA registry only (presumably, explicitly or implicitly with the x- prefix being available); c) whether the header extension space should be restricted to only those extensions defined in RFCs, requiring IETF consensus for any header extension. As said above, the author(s) felt that, given that the header extension document constrains these extensions to be small and ignorable, that choice (a) provided a reasonable balance and set of options, with the other options being either more restrictive than needed or potentially problematic in other ways. But there may be other considerations, or other preferences. I think it would help, if you don't like the current state, you could indicate what considerations lead you to another preference. -- David Singer Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 05:36:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdN48-0003Yf-6e; Thu, 04 Oct 2007 05:32:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdN46-0003YI-VV for avt@ietf.org; Thu, 04 Oct 2007 05:32:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdN45-0004Wq-Pc for avt@ietf.org; Thu, 04 Oct 2007 05:32:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l949ViDF013664; Thu, 4 Oct 2007 12:32:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 12:32:01 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 12:32:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Open issue on hdrext draft Date: Thu, 4 Oct 2007 12:32:00 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Open issue on hdrext draft Thread-Index: AcgGQCm/XpnpsommQpqdnKdVIAKsIQAHjoMg From: To: , , X-OriginalArrivalTime: 04 Oct 2007 09:32:01.0163 (UTC) FILETIME=[6AB4DDB0:01C80669] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: fluffy@cisco.com, avt-chairs@tools.ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, An RTP gateway (translator/mixer) that for some reason does not receive/parse the SDP and is then not aware of the mapping between the RTP header extension and the ID will not be able to process the RTP packet appropriately. This speaks for IETF agreed registration (option c). On the other hand, since the space for 1-byte header IDs is very limited (14 values only), registration might exhaust the space rather quickly. One possible solution is to introduce registration for 2-byte headers and leave 1-byte headers for application-specific usage. However, this has the limitation that you cannot mix registered and application-specific extensions into a single RTP packet. It also imposes length limitations on application-specific extensions. BTW, am I right in the assumption that this I-D still discourages the usage of RTP header extensions, as is the case in RFC3550? One might ask why do we need to register some headers that are just for experimental purposes? Regards, Imed >-----Original Message----- >From: ext Dave Singer [mailto:singer@apple.com]=20 >Sent: 04 October, 2007 07:15 >To: Tom Taylor; IETF AVT WG >Cc: Cullen Jennings; avt-chairs@tools.ietf.org >Subject: Re: [AVT] Open issue on hdrext draft > >I don't know if it helps, but in case it does, it might help=20 >if I 'frame' the question and provide some history and=20 >rationale for the current state. > >See below, after Tom's questions... > > >At 22:02 -0400 3/10/07, Tom Taylor wrote: >>Before the header extension draft can be approved we have to=20 >settle two=20 >>or three points that have been raised after the document passed WGLC.=20 >>One of them is the view of the Working Group regarding registration=20 >>requirements. >> >>Is it the Working Group's intention that: >> >>(a) any SDO can standardize and register a new RTP header extension=20 >>without IETF review or consent; or >> >>(b) all RTP header extensions require review and agreement by an IETF=20 >>expert before they can be registered; or >> >>(c) all RTP header extensions require IETF consensus before=20 >they can be=20 >>registered. >> >>David Singer had a clear view on this question when he wrote the=20 >>document in the first place. I should let him speak for himself, but=20 >>his basic idea was to encourage registration as an alternative to=20 >>hard-to-get-rid-of experimental identifiers, by making registration a=20 >>simple process. His preference was thus toward alternative (a). >> >>Last time we didn't ask the question in quite these stark terms, and=20 >>only Magnus replied. It's hard to read a consensus from that. Would=20 >>other people care to comment? > > >The current RTP specification makes provision for header extensions.=20 >However, there is no process defined to identify them, or=20 >register identifiers. Indeed, the 16-bit field that might be=20 >thought of as a label in the RTP packets is not clearly=20 >defined as such, and there is no registration or documentation=20 >process defined for it. This has led some to believe that=20 >they can use it as they wish, and others to believe that it is=20 >unusable. > >The header extension draft > >has been before this group since the latter part of 2005. It=20 >defines a way to pack multiple header extensions into a=20 >packet, and defines a way for them to be labelled. Initial=20 >drafts used reverse domain names (kind of like Java), and=20 >later ones moved to using URIs for the labelling. > >The question has arisen as to what requirements there should=20 >be around the documentation and registration of header extensions.=20 >Currently the draft says that IANA will provide a registry,=20 >but only for IANA-form URNs, and that to use an IANA-form URN,=20 >the extension must be defined in a standards-track RFC. This=20 >leaves open, of course, the ability of anyone who can make a=20 >URI (URL or URN) to define and use a header extension. > >Historically, IETF specs (including those from this WG) have=20 >had features or fields defined by 'simple names' that are=20 >registered, often with provision for an experimental X-=20 >prefix. I think we've all observed cases where X- names=20 >become by common usage, even with the risk of collision and=20 >lack of registration that they suffer from. > >Clearly, in cases where interop is important, the use of=20 >formats or labels for which either the registration or=20 >documentation cannot be assured to be found is undesirable, to=20 >the point that specifications are usually written to=20 >discourage this state. > >However, header extensions are defined in RTP (and this is=20 >re-inforced by the header extension draft) to be ignorable. =20 >It is an absolute requirement that the interoperability of an=20 >RTP stream cannot be affected by the presence or absence of an=20 >extension (though, of course, its utility might, or it's hard=20 >to see what the extension is doing). > >This led to the current design and status: there would be=20 >'preferred, vetted' extensions, defined in RFCs, using IANA=20 >URN names. But those needing to experiment, or develop an=20 >extension for a more restricted environment etc., would be=20 >able to use other URIs to label them, without running risk of=20 >collision, and without running the risk of an interop problem=20 >with systems that were written either without knowledge of=20 >that extension, or indeed, without knowledge of this header=20 >extension mechanism at all (i.e. using only RFC 3550 or 1889).=20 > The author(s) saw this state as preferable to the 'x-'=20 >method, in this case. > >So, I guess I'd like to know whether there are other=20 >considerations that should be taken into account. Then, here=20 >are some more worked-out questions from Tom's various choices: > >a) whether the current 'two tier' state, using URIs with an=20 >IANA registry for RFC-defined extensions is acceptable; > >b.i) whether IANA should be asked to document the mapping from=20 >any URI to a publicly available specification; > >b.ii) whether, in order to be entered into such a registry,=20 >some IETF process such as expert review should be required; > >b.iii) whether the 'official' extensions should be considered=20 >only those registered at IANA; > >b.iv) or whether we should move to a simple name system, with=20 >IANA registry only (presumably, explicitly or implicitly with=20 >the x- prefix being available); > >c) whether the header extension space should be restricted to=20 >only those extensions defined in RFCs, requiring IETF=20 >consensus for any header extension. > > >As said above, the author(s) felt that, given that the header=20 >extension document constrains these extensions to be small and=20 >ignorable, that choice (a) provided a reasonable balance and=20 >set of options, with the other options being either more=20 >restrictive than needed or potentially problematic in other=20 >ways. But there may be other considerations, or other preferences. > >I think it would help, if you don't like the current state,=20 >you could indicate what considerations lead you to another preference. > >-- >David Singer >Apple/QuickTime > >_______________________________________________ >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 avt-bounces@ietf.org Thu Oct 04 07:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdP7s-0000r7-Th; Thu, 04 Oct 2007 07:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdP7s-0000ky-48 for avt@ietf.org; Thu, 04 Oct 2007 07:44:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdP7h-0004AT-Q1 for avt@ietf.org; Thu, 04 Oct 2007 07:44:18 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF68920F1C; Thu, 4 Oct 2007 13:43:50 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-ee-4704d1f601f0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEA0D2052C; Thu, 4 Oct 2007 13:43:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:43:50 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:43:50 +0200 Message-ID: <4704D1F5.3010809@ericsson.com> Date: Thu, 04 Oct 2007 13:43:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Imed.Bouazizi@nokia.com Subject: Re: [AVT] Open issue on hdrext draft References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2007 11:43:50.0203 (UTC) FILETIME=[D4DC98B0:01C8067B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: fluffy@cisco.com, avt-chairs@tools.ietf.org, singer@apple.com, avt@ietf.org, tom.taylor@rogers.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Imed.Bouazizi@nokia.com skrev: > Hi, > > An RTP gateway (translator/mixer) that for some reason does not > receive/parse the SDP and is then not aware of the mapping between the > RTP header extension and the ID will not be able to process the RTP > packet appropriately. This speaks for IETF agreed registration (option > c). I think this is an irrelevant comment as any mixer or translator that needs to understand the packet content anyway will require to be part of the signalling context. Thus, I don't think there is a any benefit at all with static mappings. > On the other hand, since the space for 1-byte header IDs is very limited > (14 values only), registration might exhaust the space rather quickly. > One possible solution is to introduce registration for 2-byte headers > and leave 1-byte headers for application-specific usage. However, this > has the limitation that you cannot mix registered and > application-specific extensions into a single RTP packet. It also > imposes length limitations on application-specific extensions. Exactly. There is also an implementation issue with increased complexity to allow multiple mechanisms. > > BTW, am I right in the assumption that this I-D still discourages the > usage of RTP header extensions, as is the case in RFC3550? One might ask > why do we need to register some headers that are just for experimental > purposes? Well, read the draft, or even David's mail properly. For experimentation or proprietary extensions you only need a unique URI, any unique URI representing your extension will do. What we are discussing is what rules applies for the IETF URN space, i.e. the header extensions that will look like they are blessed by IETF. The current draft version was in fact a) as this specified "Specification Required" from RFC 2434: " Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible." I think A is fine but would probably prefer this to be b) with explicit rule requiring a publicly available specification. Having an expert look at any registrations to ensure that they are not totally wacko is in my book a good thing. But at the same time put minimal bar on the registrations. Other SDOs should basically be able to send in an email with a request containing a reference and things usually go through. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 09:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQj4-0005s2-57; Thu, 04 Oct 2007 09:26:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQj2-0005oY-K7 for avt@ietf.org; Thu, 04 Oct 2007 09:26:48 -0400 Received: from smtp106.rog.mail.re2.yahoo.com ([68.142.225.204]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdQio-0007B6-9q for avt@ietf.org; Thu, 04 Oct 2007 09:26:34 -0400 Received: (qmail 82381 invoked from network); 4 Oct 2007 13:26:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=r2H3THOShCcwGxlNSeSGGZnlYn9nLAm4rDHulehPnklOcUAvKojdpxHLewJwwZKn3yzNJtzqpY7hKpI3fjwZc8Wj+KL3wjbpwnn0OvtzewyDeBa1J7UxGU+jjepuNy5siVUXY6WGfP2aXMPgFUPpFPrKx8U9nYpU+bFIf3HpU14= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 4 Oct 2007 13:26:33 -0000 X-YMail-OSG: hHeAvoYVM1lexaV5P5AG_WWropLAMob8qB1lZARxxlSDRoGY1whhEL2Pzw6N15n6gQ-- Message-ID: <4704EA08.8010009@rogers.com> Date: Thu, 04 Oct 2007 09:26:32 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [AVT] Re: Open issue on hdrext draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Could further notes on this topic please be restricted to the AVT list only? I failed to see the extra addresses on my original note, and have been getting three copies of everything as a result. Tom _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 11:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSxv-00044U-Iz; Thu, 04 Oct 2007 11:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSxt-00043r-Ne for avt@ietf.org; Thu, 04 Oct 2007 11:50:17 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdSxl-0005sJ-H0 for avt@ietf.org; Thu, 04 Oct 2007 11:50:17 -0400 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 12832148BFC5; Thu, 4 Oct 2007 08:50:03 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id EA34928059; Thu, 4 Oct 2007 08:50:02 -0700 (PDT) X-AuditID: 11807130-a3bc2bb000004daf-8f-47050baa8a96 Received: from [17.202.37.243] (unknown [17.151.104.94]) by relay11.apple.com (Apple SCV relay) with ESMTP id 714402804E; Thu, 4 Oct 2007 08:50:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4704D1F5.3010809@ericsson.com> References: <4704D1F5.3010809@ericsson.com> Date: Thu, 4 Oct 2007 08:48:23 -0700 To: Magnus Westerlund , Imed.Bouazizi@nokia.com From: Dave Singer Subject: Re: [AVT] Open issue on hdrext draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt-chairs@tools.ietf.org, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org At 13:43 +0200 4/10/07, Magnus Westerlund wrote: >Imed.Bouazizi@nokia.com skrev: >> Hi, >> >> An RTP gateway (translator/mixer) that for some reason does not >> receive/parse the SDP and is then not aware of the mapping between the >> RTP header extension and the ID will not be able to process the RTP >> packet appropriately. This speaks for IETF agreed registration (option >> c). > >I think this is an irrelevant comment as any mixer or translator that >needs to understand the packet content anyway will require to be part of >the signalling context. Thus, I don't think there is a any benefit at >all with static mappings. I agree; the general question "should RTP packets be comprehensible without their signaling context" is outside the scope of this discussion (though my sense is that the consensus direction is "no", as shown, for example, by the fact that we no longer approve of static payload type mappings). > >What we are discussing is what rules applies for the IETF URN space, >i.e. the header extensions that will look like they are blessed by IETF. >The current draft version was in fact a) as this specified >"Specification Required" from RFC 2434: > >" Specification Required - Values and their meaning must be > documented in an RFC or other permanent and readily available > reference, in sufficient detail so that interoperability > between independent implementations is possible." > >I think A is fine but would probably prefer this to be b) with explicit >rule requiring a publicly available specification. I'm sorry, I may have mis-written something, since I tried to agree with you here! The current intention is that for the IETF URN space, a standards-track RFC is required. And that for IANA registration, an IETF URN is required: "To be registered with IANA, the extension MUST use this IETF URN form; to use the IETF URN form, the extension MUST be defined in an RFC." If there is other text that isn't clear, can you tell me what it is? >Having an expert look >at any registrations to ensure that they are not totally wacko is in my >book a good thing. Me too, no dispute here. >But at the same time put minimal bar on the >registrations. Other SDOs should basically be able to send in an email >with a request containing a reference and things usually go through. > So, you would permit non-IETF URIs in the IANA registry, also, after, what 'expert review' and with 'publicly available specification required'? That's fine by me also. -- David Singer Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 12:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTrm-0004oz-1V; Thu, 04 Oct 2007 12:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTrk-0004cS-Pb for avt@ietf.org; Thu, 04 Oct 2007 12:48:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdTrc-0007n1-DH for avt@ietf.org; Thu, 04 Oct 2007 12:47:58 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE98D204DF; Thu, 4 Oct 2007 18:47:46 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-c2-47051932fafa Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9C3D42043F; Thu, 4 Oct 2007 18:47:46 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 18:47:46 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 18:47:46 +0200 Message-ID: <47051932.2080909@ericsson.com> Date: Thu, 04 Oct 2007 18:47:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Singer Subject: Re: [AVT] Open issue on hdrext draft References: <4704D1F5.3010809@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2007 16:47:46.0562 (UTC) FILETIME=[4A942620:01C806A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: fluffy@cisco.com, Imed.Bouazizi@nokia.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dave Singer skrev: > At 13:43 +0200 4/10/07, Magnus Westerlund wrote: >> Imed.Bouazizi@nokia.com skrev: >> >> What we are discussing is what rules applies for the IETF URN space, >> i.e. the header extensions that will look like they are blessed by IETF. >> The current draft version was in fact a) as this specified >> "Specification Required" from RFC 2434: >> >> " Specification Required - Values and their meaning must be >> documented in an RFC or other permanent and readily available >> reference, in sufficient detail so that interoperability >> between independent implementations is possible." >> >> I think A is fine but would probably prefer this to be b) with explicit >> rule requiring a publicly available specification. > > I'm sorry, I may have mis-written something, since I tried to agree with > you here! The current intention is that for the IETF URN space, a > standards-track RFC is required. And that for IANA registration, an > IETF URN is required: > > "To be registered > with IANA, the extension MUST use this IETF URN form; to use the IETF > URN form, the extension MUST be defined in an RFC." > > If there is other text that isn't clear, can you tell me what it is? In section 9.1 of draft-ietf-avt-rtp-hdrext-13: The rtp-hdrext namespace under urn:ietf:params: needs to be created for management, referenced to RFCxxxx. Additions in this namespace shall be made on the basis of "Specification Required". Which indicates that you can add new entires only requiring a specification which is actually a contradiction to what is written in Section 5: For extensions defined in RFCs, the URI used SHOULD be a URN starting "urn:ietf:params:rtp-hdrext:" and followed by a registered, descriptive name. These URNs are managed by IANA. To be registered with IANA, the extension MUST use this IETF URN form; to use the IETF URN form, the extension MUST be defined in an RFC. So I think you need to use the Standards Action level in 9.1 to match the section 5 text. > >> Having an expert look >> at any registrations to ensure that they are not totally wacko is in my >> book a good thing. > > Me too, no dispute here. > >> But at the same time put minimal bar on the >> registrations. Other SDOs should basically be able to send in an email >> with a request containing a reference and things usually go through. >> > > So, you would permit non-IETF URIs in the IANA registry, also, after, > what 'expert review' and with 'publicly available specification required'? > > That's fine by me also. > I think we can allow people to use the public IANA registry for header extensions as long as there is a reasonable and publicly available. Thus I would use Expert Review and some requirements on what the Expert is allowed to approve. Where the primary is: Open publicly available Specification. But there is likely that some more should be written. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 04 22:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcjX-00075e-Ri; Thu, 04 Oct 2007 22:16:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcjX-00072y-0F for avt@ietf.org; Thu, 04 Oct 2007 22:16:07 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdcjW-0000ek-3W for avt@ietf.org; Thu, 04 Oct 2007 22:16:06 -0400 X-VirusChecked: Checked X-Env-Sender: Qiaobing.Xie@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1191550564!4765225!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12760 invoked from network); 5 Oct 2007 02:16:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 5 Oct 2007 02:16:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l952G4FL008983; Thu, 4 Oct 2007 19:16:04 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l952G3Du018971; Thu, 4 Oct 2007 21:16:03 -0500 (CDT) Received: from [202.181.125.202] ([10.193.155.181]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l952G0Vf018904; Thu, 4 Oct 2007 21:16:01 -0500 (CDT) Message-ID: <47059733.5030707@motorola.com> Date: Thu, 04 Oct 2007 20:45:23 -0500 From: Qiaobing Xie User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ingemar Johansson S Subject: Re: [AVT] Re: I-D ACTION:draft-ietf-avt-forward-shifted-red-00.txt References: <026F8EEDAD2C4342A993203088C1FC0505C2976F@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0505C2976F@esealmw109.eemea.ericsson.se> X-CFilter-Loop: Reflected X-Spam-Score: 1.7 (+) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0162881573==" Errors-To: avt-bounces@ietf.org --===============0162881573== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hi, Ingemar
Sorry for slow response (I am on vacation and having very limited email access).

The restriction imposed by RFC2198 that only allow the redundant data be shifted backward seems quite arbitrary. The intention of this draft is just to relax that restriction so that the redundant data can be shifted forward. There are cases where forward shifting of the redundant data can be advantageous (as illustrated by the anti-shadow example in Appendix A in the draft).

In other words, improving the delay is not the gaol of this draft.

regards,
-Qiaobing
Ingemar Johansson S wrote: 
Hi

Read the draft and although I understand the concept I fail to realize
what is gained with forward shifted redundancy. Could you please
elaborate what the possible gain with forward shifted redundancy is,
compared to what is specified in RFC2198. As I see it both alternatives
will eventually give the same delay.

Regards
Ingemar

  
-----Original Message-----
From: avt-request@ietf.org [mailto:avt-request@ietf.org] 
Sent: den 22 september 2007 18:00
To: avt@ietf.org
Subject: avt Digest, Vol 41, Issue 22

Send avt mailing list submissions to
	avt@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
	avt-request@ietf.org

You can reach the person managing the list at
	avt-owner@ietf.org

When replying, please edit your Subject line so it is more 
specific than "Re: Contents of avt digest..."


Today's Topics:

   1. I-D ACTION:draft-ietf-avt-forward-shifted-red-00.txt 
      (Internet-Drafts@ietf.org)


----------------------------------------------------------------------

Message: 1
Date: Fri, 21 Sep 2007 12:15:01 -0400
From: Internet-Drafts@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-forward-shifted-red-00.txt
To: i-d-announce@ietf.org
Cc: avt@ietf.org
Message-ID: <E1IYl9h-0004GN-Rw@stiedprstage1.ietf.org>
Content-Type: text/plain; charset="us-ascii"

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		: Forward-shifted RTP Redundancy Payload Support
	Author(s)	: Q. Xie, J. Schumacher
	Filename	: draft-ietf-avt-forward-shifted-red-00.txt
	Pages		: 13
	Date		: 2007-9-21
	
   This document defines a simple enhancement to RFC 2198 to 
support RTP
   sessions with forward-shifted redundant encodings, i.e., redundant
   data is sent before the corresponding primary data.  
Forward-shifted
   redundancy can be used to conceal losses of a large number of
   consecutive media frames (e.g., consecutive loss of seconds or even
   tens of seconds of media).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-forward-shi
fted-red-00.txt

To remove yourself from the I-D Announcement list, send a 
message to i-d-announce-request@ietf.org with the word 
unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-forward-shifted-red-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-forward-shifted-red-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.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

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


End of avt Digest, Vol 41, Issue 22
***********************************

    

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
--===============0162881573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0162881573==-- From avt-bounces@ietf.org Thu Oct 04 23:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iddgj-0007Jj-ME; Thu, 04 Oct 2007 23:17:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iddgi-0007Jc-JF for avt@ietf.org; Thu, 04 Oct 2007 23:17:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iddgi-0002Nw-7P for avt@ietf.org; Thu, 04 Oct 2007 23:17:16 -0400 X-IronPort-AV: E=Sophos;i="4.21,233,1188802800"; d="scan'208";a="531654901" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Oct 2007 20:17:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l953HFES011384; Thu, 4 Oct 2007 20:17:15 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l953H4Yv016281; Fri, 5 Oct 2007 03:17:13 GMT In-Reply-To: References: <4704D1F5.3010809@ericsson.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BA3478B-6DDF-47B0-8576-21D7E5021C7A@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [AVT] Open issue on hdrext draft Date: Thu, 4 Oct 2007 20:17:06 -0700 To: Dave Singer , Magnus Westerlund X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1174; t=1191554235; x=1192418235; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[AVT]=20Open=20issue=20on=20hdrext=20draft |Sender:=20; bh=dtFdwot/lpzd8otTC8zxLsAdAK+rwneMz8Ycr46I4Tg=; b=pZyTkD2lQnQhWaC9+O4rZG1no1gW8PftDMksFh8e9Bl9uL967PpvCI1qBAnbcNZaEISziGKN kiCd3zNlj2VKvbc/pWIW2qT8XexfhPCfDGl7KH3Fz3p69dcQToQ895v1FLfHbNY9MGm6OseW3Q nP720bn9AWEA9P8Xy7J2qox/o=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: avt-chairs@tools.ietf.org, Imed.Bouazizi@nokia.com, Dave Singer , avt@ietf.org, Tom Taylor X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 4, 2007, at 8:48 AM, Dave Singer wrote: > At 13:43 +0200 4/10/07, Magnus Westerlund wrote: >> Imed.Bouazizi@nokia.com skrev: >>> Hi, >>> >>> An RTP gateway (translator/mixer) that for some reason does not >>> receive/parse the SDP and is then not aware of the mapping >>> between the >>> RTP header extension and the ID will not be able to process the RTP >>> packet appropriately. This speaks for IETF agreed registration >>> (option >>> c). >> >> I think this is an irrelevant comment as any mixer or translator that >> needs to understand the packet content anyway will require to be >> part of >> the signalling context. Thus, I don't think there is a any benefit at >> all with static mappings. > > I agree; the general question "should RTP packets be > comprehensible without their signaling context" is outside the > scope of this discussion (though my sense is that the consensus > direction is "no", as shown, for example, by the fact that we no > longer approve of static payload type mappings). Agree we should keep that questions as a sperate one (and I think we will easily get to an answer on it) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 05 19:09:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwFb-0007ax-LL; Fri, 05 Oct 2007 19:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwFY-0007ab-O8 for avt@ietf.org; Fri, 05 Oct 2007 19:06:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdwFX-000094-I1 for avt@ietf.org; Fri, 05 Oct 2007 19:06:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,237,1188802800"; d="scan'208";a="231521973" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 05 Oct 2007 16:06:27 -0700 Received: from [10.32.245.156] ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l95LfHAb022793; Fri, 5 Oct 2007 14:42:20 -0700 In-Reply-To: <470449BC.50603@rogers.com> References: <470449BC.50603@rogers.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00B93312-D040-4240-8443-A5D40804866A@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] Open issue on hdrext draft Date: Fri, 5 Oct 2007 15:38:27 -0400 To: Tom Taylor X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1672; t=1191620541; x=1192484541; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Open=20issue=20on=20hdrext=20draft |Sender:=20 |To:=20Tom=20Taylor=20; bh=brfWnFheWfn/gcYx7XKhb2ZKHQeQ96qsoXPuulOi1Sg=; b=fD5muS8A5YJ/o2bhxTxLAZH8wtPXSNCTzBcTw6S+rB5Q0Ul6TL5sswGE/TD36rcYTAPocaOm Zmw834CbtgK9/o47tPSWqe1CBCJn+a7+k6+ilK8vXz8L5VehYlcMJXMD; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Cullen Jennings , IETF AVT WG , avt-chairs@tools.ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 3, 2007, at 10:02 PM, Tom Taylor wrote: > Before the header extension draft can be approved we have to settle > two or three points that have been raised after the document passed > WGLC. One of them is the view of the Working Group regarding > registration requirements. > > Is it the Working Group's intention that: > > (a) any SDO can standardize and register a new RTP header extension > without IETF > review or consent; or > > (b) all RTP header extensions require review and agreement by an > IETF expert > before they can be registered; or > > (c) all RTP header extensions require IETF consensus before they > can be registered. > > David Singer had a clear view on this question when he wrote the > document in the first place. I should let him speak for himself, > but his basic idea was to encourage registration as an alternative > to hard-to-get-rid-of experimental identifiers, by making > registration a simple process. His preference was thus toward > alternative (a). > > Last time we didn't ask the question in quite these stark terms, > and only Magnus replied. It's hard to read a consensus from that. > Would other people care to comment? > I would be happy with (a) or (b) with a mild preference for (b) because lack of any review often leads to duplication - essentially identical extensions with arbitrarily different syntax, and the consequent lost opportunities for interoperabiity. Dave Oran. > Tom Taylor > > _______________________________________________ > 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 avt-bounces@ietf.org Sun Oct 07 05:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeSg2-0003fL-9T; Sun, 07 Oct 2007 05:43:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeSg0-0003Yd-7M for avt@ietf.org; Sun, 07 Oct 2007 05:43:56 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeSft-0004VC-5a for avt@ietf.org; Sun, 07 Oct 2007 05:43:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/answer questions on RFC 4585 Date: Sun, 7 Oct 2007 11:45:18 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04F08FA1@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/answer questions on RFC 4585 Thread-Index: AcgE7Z5rzGaYvf0KStei+LHD/qwFkQD2ON+Q From: "Even, Roni" To: "Christer Holmberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Christer This is my view. The different between AVP and AVPF is in the RTCP messages so if the receiver understands the SDP of AVPF nothing bad will happen. Roni=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, October 02, 2007 2:13 PM > To: avt@ietf.org > Subject: RE: [AVT] Offer/answer questions on RFC 4585 >=20 >=20 > Hi Roni, >=20 > >>I have a couple of questions on RFC 4585, regarding the usage with > offer/answer. > >> > >>My FIRST question is: are there any TECHNICAL reasons (I know it's > probably not allowed by RFC 3264) why a user receiving an AVPF offer, > but doesn't > >>support it, can't reply with AVP answer (instead of rejecting the > stream)? My understanding is that if you offer AVPF you still have to be > able to do > >>AVP, so... > >>(The receiver of course needs to understand the "AVPF" string in the > SDP) >=20 > >[RE:] I think that is this case the offer will include a=3Drtcp-fb = with > rtcp-fb-vals. Since the receiver understands AVPF but do not support any > feedback > >message it will remove all rtcp-fb-val in the answers. > >To me that looks like support of AVP so why do you want to change the > avpf to avp. >=20 > Ok, if it works that way. >=20 > So, if I have an MGCF/MGW I can do the following: >=20 > - The MGCF answers with AVPF, but without rtcp-fb-val >=20 > - The MGCF sends AVP down to the MGW (e.g using H.248) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > 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 avt-bounces@ietf.org Mon Oct 08 04:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iendx-0003yr-TU; Mon, 08 Oct 2007 04:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iendw-0003yg-QN for avt@ietf.org; Mon, 08 Oct 2007 04:07:12 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iendq-0006RA-KK for avt@ietf.org; Mon, 08 Oct 2007 04:07:12 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B5624209E5; Mon, 8 Oct 2007 10:06:47 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-35-4709e5171fd7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A946C209D9; Mon, 8 Oct 2007 10:06:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 10:06:47 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 10:06:46 +0200 Message-ID: <4709E516.2040400@ericsson.com> Date: Mon, 08 Oct 2007 10:06:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Even, Roni" Subject: Re: [AVT] Offer/answer questions on RFC 4585 References: <144ED8561CE90C41A3E5908EDECE315C04F08FA1@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04F08FA1@IsrExch01.israel.polycom.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2007 08:06:46.0591 (UTC) FILETIME=[2BD61CF0:01C80982] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Even, Roni skrev: > Christer > This is my view. The different between AVP and AVPF is in the RTCP > messages so if the receiver understands the SDP of AVPF nothing bad will > happen. Hmmm, I would not fully agree with this. I think it will work. However, there are important difference in the RTCP timing rules between AVPF and AVP, even when no AVPF feedback messages are used. Thus, the processing of timing out SSRCs can be affected. But normally there is very little difference unless feedback messages are sent. I do expect things to work, unless the AVP receivers are strict about checking the timing behavior of the other senders (which it really shouldn't do). So one better test this well with the AVP implementation one is actually using. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 04:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IenwK-0005RW-NY; Mon, 08 Oct 2007 04:26:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IenwJ-0005RN-Qx for avt@ietf.org; Mon, 08 Oct 2007 04:26:11 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IenwJ-0006BL-Bt for avt@ietf.org; Mon, 08 Oct 2007 04:26:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/answer questions on RFC 4585 Date: Mon, 8 Oct 2007 10:27:42 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04F95794@IsrExch01.israel.polycom.com> In-Reply-To: <4709E516.2040400@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/answer questions on RFC 4585 Thread-Index: AcgJgqkH5adg4fLTQ66fyWUgvI+OtgAAl++Q From: "Even, Roni" To: "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus, Do you see a problem in unicast? Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, October 08, 2007 10:07 AM > To: Even, Roni > Cc: Christer Holmberg; avt@ietf.org > Subject: Re: [AVT] Offer/answer questions on RFC 4585 >=20 > Even, Roni skrev: > > Christer > > This is my view. The different between AVP and AVPF is in the RTCP > > messages so if the receiver understands the SDP of AVPF nothing bad = will > > happen. >=20 > Hmmm, I would not fully agree with this. I think it will work. = However, > there are important difference in the RTCP timing rules between AVPF = and > AVP, even when no AVPF feedback messages are used. Thus, the = processing > of timing out SSRCs can be affected. But normally there is very little > difference unless feedback messages are sent. I do expect things to > work, unless the AVP receivers are strict about checking the timing > behavior of the other senders (which it really shouldn't do). >=20 > So one better test this well with the AVP implementation one is = actually > using. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 04:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieo7q-00040y-2M; Mon, 08 Oct 2007 04:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieo7p-00040s-3z for avt@ietf.org; Mon, 08 Oct 2007 04:38:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieo7j-0007Az-QH for avt@ietf.org; Mon, 08 Oct 2007 04:38:05 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4677621395; Mon, 8 Oct 2007 10:37:54 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-2d-4709ec629489 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B572204DD; Mon, 8 Oct 2007 10:37:54 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 10:37:54 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 10:37:53 +0200 Message-ID: <4709EC60.1020306@ericsson.com> Date: Mon, 08 Oct 2007 10:37:52 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Even, Roni" Subject: Re: [AVT] Offer/answer questions on RFC 4585 References: <144ED8561CE90C41A3E5908EDECE315C04F95794@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04F95794@IsrExch01.israel.polycom.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2007 08:37:53.0930 (UTC) FILETIME=[84DB6EA0:01C80986] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Even, Roni skrev: > Magnus, > Do you see a problem in unicast? Yes, the main problem is how one configures the bandwidth combined with the need for "trr-int". If one reads Section 5 on compatibilities between AVP and AVPF there is stressed the need to set "trr-int" to 5 seconds to avoid AVPF users to timeout AVP users. And if "trr-int" is set to high AVP can timeout AVPF users. Thus removing rtcp-fb completely may not be the right move, but only leaving trr-int=5 should work as intended. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 09:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesce-0000pA-KT; Mon, 08 Oct 2007 09:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iescc-0000nr-Tj; Mon, 08 Oct 2007 09:26:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iescc-000768-IX; Mon, 08 Oct 2007 09:26:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 735D026EE2; Mon, 8 Oct 2007 13:26:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iescc-0001wP-C6; Mon, 08 Oct 2007 09:26:10 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:26:10 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rtp-evrc-wb (RTP payload format for EVRC-WB codec and media subtype updates for EVRC-B codec) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP payload format for EVRC-WB codec and media subtype updates for EVRC-B codec ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15628&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 09:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesbo-0008Ly-3z; Mon, 08 Oct 2007 09:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesbn-0008Lp-9G; Mon, 08 Oct 2007 09:25:19 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iesbm-00073Q-7b; Mon, 08 Oct 2007 09:25:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1068726EE3; Mon, 8 Oct 2007 13:25:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IesbY-0001uQ-VQ; Mon, 08 Oct 2007 09:25:04 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:25:04 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-avpf-ccm (Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)) to Proposed Standard X-BeenThereFrom avt-bounces@ietf.org Mon Oct 08 09:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesce-0000pA-KT; Mon, 08 Oct 2007 09:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iescc-0000nr-Tj; Mon, 08 Oct 2007 09:26:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iescc-000768-IX; Mon, 08 Oct 2007 09:26:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 735D026EE2; Mon, 8 Oct 2007 13:26:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iescc-0001wP-C6; Mon, 08 Oct 2007 09:26:10 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:26:10 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rtp-evrc-wb (RTP payload format for EVRC-WB codec and media subtype updates for EVRC-B codec) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP payload format for EVRC-WB codec and media subtype updates for EVRC-B codec ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15628&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 09:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesbo-0008Ly-3z; Mon, 08 Oct 2007 09:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesbn-0008Lp-9G; Mon, 08 Oct 2007 09:25:19 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iesbm-00073Q-7b; Mon, 08 Oct 2007 09:25:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1068726EE3; Mon, 8 Oct 2007 13:25:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IesbY-0001uQ-VQ; Mon, 08 Oct 2007 09:25:04 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:25:04 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-avpf-ccm (Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15111&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt : avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15111&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 09:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesdq-0003f4-Eg; Mon, 08 Oct 2007 09:27:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesdo-0003el-MF; Mon, 08 Oct 2007 09:27:24 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iesdo-0008JV-EU; Mon, 08 Oct 2007 09:27:24 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5BA4E2AC2B; Mon, 8 Oct 2007 13:26:54 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IesdK-0001yI-3D; Mon, 08 Oct 2007 09:26:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:26:54 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rtp-vorbis (RTP Payload Format for Vorbis Encoded Audio) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP Payload Format for Vorbis Encoded Audio ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14346&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 08 09:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeseZ-0004Yl-AI; Mon, 08 Oct 2007 09:28:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeseY-0004Xs-3B; Mon, 08 Oct 2007 09:28:10 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeseX-0008LN-Rx; Mon, 08 Oct 2007 09:28:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8565E175A5; Mon, 8 Oct 2007 13:28:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IeseX-00020m-2g; Mon, 08 Oct 2007 09:28:09 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:28:09 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-topologies (RTP Topologies) to Informational RFC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP Topologies ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15112&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 10 10:48:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifco7-0002Ym-PD; Wed, 10 Oct 2007 10:45:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifco6-0002Xt-UL; Wed, 10 Oct 2007 10:45:06 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifco6-0006ui-HU; Wed, 10 Oct 2007 10:45:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2B2BE175C1; Wed, 10 Oct 2007 14:44:36 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ifcnb-0004yN-Mr; Wed, 10 Oct 2007 10:44:35 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Oct 2007 10:44:35 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'RTP Payload Format for Generic Forward Error Correction' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has approved the following document: - 'RTP Payload Format for Generic Forward Error Correction ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-23.txt Technical Summary This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this draft allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristic. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. Working Group Summary This document has been under discussion in the AVT working group since the 48th IETF meeting, having been brought to AVT along with a competing draft (draft-lnt-avt-uxp-00.txt) from the ITU-T SG16. Considering their relative merits, AVT eventually decided to adopt both drafts, this draft being simpler and conceptually backwards compatible with RFC 2733, the UXP work being more complex (based on Reed Solomon coding, rather than simple parity coding) but with potentially better performance in some scenarios. Work on the UXP draft was abandoned in 2004, and the ULP draft progressed to completion. More recently, there has been some discussion of the merits of the ULP work, compared to the schemes employed by 3GPP, and the ongoing work in FECFRAME. We believe the FECFRAME proposals will likely form the basis of future FEC work for RTP. Despite this, we believe it necessary to publish the ULP draft all the same, since it contains an important bug fix to RFC 2733, and since the layered extensions can potentially offer improved performance in a manner that is conceptually compatible with to RFC 2733. Document Quality Media type review on the -14 took place starting in December 2005, with no objection (there have been no changes in the draft that would change that consensus since then). Jonathan Rosenberg and Mark Watson provided extensive last call comments and review. Personnel Colin Perkins is the document shepherd. Cullen Jennings is the responsible AD. David McGrew and Eric Rescorla review the interaction of SRTP encryption and FEC. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 10 14:14:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifg3B-0004UC-S5; Wed, 10 Oct 2007 14:12:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifg39-0004Ts-P3 for avt@ietf.org; Wed, 10 Oct 2007 14:12:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifg39-0005Qv-Bl for avt@ietf.org; Wed, 10 Oct 2007 14:12:51 -0400 X-IronPort-AV: E=Sophos;i="4.21,255,1188802800"; d="scan'208";a="11750658" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2007 11:12:48 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9AICmpK028120; Wed, 10 Oct 2007 11:12:48 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l9AIClG2005248; Wed, 10 Oct 2007 18:12:47 GMT References: Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27C556E9-6E18-444C-B79B-C1885D957D65@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 10 Oct 2007 11:12:30 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1591; t=1192039968; x=1192903968; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Question=20from=20IANA=20abut=20registry=20for=20WAV=20and=20 AVI=20codecs=20 |Sender:=20; bh=S1m7MchoRXM/bXWAI1mqxduJF5dS+70AOZ5/LDHGcwo=; b=hCYzcnr9vNh3FdRVZmw2iOdDiJdxciqC+OzagTMwnYmuz9hRn4GzssjAEZgyM8ZR6Rs5rDHM 2/5Xva9Rxmq4+AJQgxKkIAo3LD4Fgyn9mEiFTN0nlsPTEP6BfW0PmoZyPAqNTRPZt2du6eEqn6 fEmcjP1UpreBPsNf+sUg25Vug=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: avt-chairs@tools.ietf.org Subject: [AVT] Question from IANA abut registry for WAV and AVI codecs X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I have tried to reach the authors of these registrations but failed to resolve the issue. Does anyone know if we have the wrong values in the registry and is so can you please suggest what values should be in the registry. Thanks, Cullen Begin forwarded message: >>> >>> >>> On Mon Aug 13 18:16:20 2007, shawn@vrfarchive.com wrote: >>>>> Can you provide the URL for which registry you are referring to? >>>> >>>> Sure thing: >>>> >>>> http://www.iana.org/assignments/wave-avi-codec-registry >>>> >>>> It seems that AC3 and DVM are mixed up. Or at least, I know a >>>> Format >>>> Tag of 0x2000 means AC3 for sure. >>>> >>>> I found this because of an AVI that wouldn't play sound. It's >>>> tag was >>>> 0x2000 and I looked it up in the registry (which identifies >>>> it as >>>> DVM). I searched for the namespace type (audio/ >>>> vnd.wave;codec=2000) >>>> and found this: >>>> >>>> http://forum.doom9.org/archive/index.php/t-34712.html >>>> >>>> [quote] >>>> For instance, Tag2000 is AC3, yet in the RFC, AC3 is listed as >>>> Tag92. >>>> It is the only listing for AC3 in the RFC : >>>> [snip] >>>> Furthermore, tag2000 is in the list, but is listed as DVM. What in >>>> the >>>> world is DVM? >>>> [/quote] >>>> >>>> I'd like to provide an automatic codec download service, and I >>>> planned >>>> on using RFC 2361 as a reference. I can easily swap these >>>> two, but >>>> I'm wondering if there are other entries that need fixing. >>>> -SHAWN- >>>> >>>> >>> >> > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 11 04:19:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftEK-0002Ov-ML; Thu, 11 Oct 2007 04:17:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftEK-0002Oj-7v for avt@ietf.org; Thu, 11 Oct 2007 04:17:16 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IftEJ-0007pv-HE for avt@ietf.org; Thu, 11 Oct 2007 04:17:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 10:18:46 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04F95DD7@IsrExch01.israel.polycom.com> In-Reply-To: <27C556E9-6E18-444C-B79B-C1885D957D65@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question from IANA abut registry for WAV and AVI codecs Thread-Index: AcgLaWta5uDohtwiR6mlRmCdbUWkHwAdOM9A From: "Even, Roni" To: "Cullen Jennings" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: avt-chairs@tools.ietf.org Subject: [AVT] RE: Question from IANA abut registry for WAV and AVI codecs X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Cullen, Searching I found that DVM is also Dolby AC3, probably different format FAST Multimedia AG DVM (Dolby AC3) http://www.codeclibrary.com/details.php?code=3D0x2000 Roni > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, October 10, 2007 8:13 PM > To: avt@ietf.org > Cc: avt-chairs@tools.ietf.org > Subject: Question from IANA abut registry for WAV and AVI codecs >=20 >=20 > I have tried to reach the authors of these registrations but failed > to resolve the issue. Does anyone know if we have the wrong values in > the registry and is so can you please suggest what values should be > in the registry. >=20 > Thanks, Cullen >=20 >=20 > Begin forwarded message: >=20 > >>> > >>> > >>> On Mon Aug 13 18:16:20 2007, shawn@vrfarchive.com wrote: > >>>>> Can you provide the URL for which registry you are referring to? > >>>> > >>>> Sure thing: > >>>> > >>>> http://www.iana.org/assignments/wave-avi-codec-registry > >>>> > >>>> It seems that AC3 and DVM are mixed up. Or at least, I know a > >>>> Format > >>>> Tag of 0x2000 means AC3 for sure. > >>>> > >>>> I found this because of an AVI that wouldn't play sound. It's > >>>> tag was > >>>> 0x2000 and I looked it up in the registry (which identifies > >>>> it as > >>>> DVM). I searched for the namespace type (audio/ > >>>> vnd.wave;codec=3D2000) > >>>> and found this: > >>>> > >>>> http://forum.doom9.org/archive/index.php/t-34712.html > >>>> > >>>> [quote] > >>>> For instance, Tag2000 is AC3, yet in the RFC, AC3 is listed as > >>>> Tag92. > >>>> It is the only listing for AC3 in the RFC : > >>>> [snip] > >>>> Furthermore, tag2000 is in the list, but is listed as DVM. What in > >>>> the > >>>> world is DVM? > >>>> [/quote] > >>>> > >>>> I'd like to provide an automatic codec download service, and I > >>>> planned > >>>> on using RFC 2361 as a reference. I can easily swap these > >>>> two, but > >>>> I'm wondering if there are other entries that need fixing. > >>>> -SHAWN- > >>>> > >>>> > >>> > >> > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 12 09:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKf3-0003Gl-S8; Fri, 12 Oct 2007 09:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6xQ-0006XD-8X for avt@ietf.org; Thu, 11 Oct 2007 18:56:44 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig6xF-0001W4-TI for avt@ietf.org; Thu, 11 Oct 2007 18:56:40 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BMuLTq029845 for ; Thu, 11 Oct 2007 22:56:21 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BMuK7L015142 for ; Thu, 11 Oct 2007 16:56:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BMuKl1027331; Thu, 11 Oct 2007 17:56:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BMuI39027330; Thu, 11 Oct 2007 17:56:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 17:56:18 -0500 From: Nicolas Williams To: secdir-secretary@MIT.EDU Message-ID: <20071011225618.GD24532@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Fri, 12 Oct 2007 09:34:41 -0400 Cc: fluffy@cisco.com, jon.peterson@neustar.biz, carrara@kth.se, secdir@MIT.EDU, avt@ietf.org Subject: [AVT] Review of draft-ietf-avt-profile-savpf-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document does not say whether it is intended to be on the Standards Track, Informational, etcetera. I assume it is intended to be on the Standards Track. Although some of the text in this document is somewhat confusing, has a number of grammatical and other editing errors, and in many places fails to expand acronyms, it is a simple profile of SRTP. The security considerations section covers all the areas that I think needed to be covered, except, perhaps, two things. In section 3.4 example #2 contains symmetric key material which, as the description correctly states, requires confidentiality protection by whatever channel is used to obtain the given session description. Other examples, such as example #1, might require at least integrity protection, but this is not discussed. It may be that they do not require integrity protection, but I can't tell as I'm not an expert in MIKEY (which was used in the example) and, in any case, other key management frameworks can be used and some might require at least integrity protection. For example, when unauthenticated DH key exchanges are used I would expect integrity protection by some other channel to be required in order to prevent MITM attacks. A small amount of text should cover this case. Additionally, it's not clear to me whether whether there are any attributes of an SDP besides a=key-mgmt: and a=crypto: which might need integrity and even confidentiality protection. Additional text about this would be good. Nico -- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 13 11:07:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgiWb-0007ib-Vv; Sat, 13 Oct 2007 11:03:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgiWa-0007i1-Pa for avt@ietf.org; Sat, 13 Oct 2007 11:03:32 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgiWa-0004qb-5I for avt@ietf.org; Sat, 13 Oct 2007 11:03:32 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60475 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IgiWZ-000403-BA for avt@ietf.org; Sat, 13 Oct 2007 16:03:31 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28C7ACE1-3D71-431D-A0CD-84E95D9EB361@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Sat, 13 Oct 2007 16:03:29 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [AVT] Fwd: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Note new rules for submission of -00 working group drafts that replace existing individual drafts. Colin Begin forwarded message: > From: IETF Secretariat > Date: 12 October 2007 16:45:00 BDT > To: IETF Announcement list > Subject: REVISED Internet-Draft Submission Cutoff Dates for the > 70th IETF Meeting in Vancouver, BC, Canada > > There are two (2) Internet-Draft cutoff dates for the 70th IETF > Meeting in Vancouver, BC, Canada: > > November 12th: Cutoff Date for Initial (i.e., version -00) Internet- > Draft > Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > November 12th at 9:00 AM ET (14:00 UTC/GMT). The only exception is for > version -00 WG drafts that replace existing non-WG drafts. Such > drafts > may be submitted until the cutoff date for version -01 and higher > drafts. > As always, all initial submissions with a filename beginning with > "draft-ietf" must be approved by the appropriate WG Chair before > they can > be processed or announced. The Secretariat would appreciate > receiving WG > Chair approval by Monday, November 5th at 9:00 AM ET (14:00 UTC/GMT). > > November 19th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be > submitted by > Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). > > Initial and revised Internet-Drafts submitted after their respective > cutoff dates will not be made available in the Internet-Drafts > directory > or announced until on or after Monday, December 3rd at 9:00 AM ET > (14:00 > UTC/GMT), when Internet-Draft posting resumes. Please do not wait > until > the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via the > Internet-Draft Submission Tool (IDST) > https://datatracker.ietf.org/idst/upload.cgi. If you are unable to > do so, > then you may still submit your Internet-Drafts manually by sending > them to > internet-drafts@ietf.org. If you are submitting a version -00 WG > draft > that replaces non-WG draft, then you must submit it manually as the > current IDST cannot handle replacements. Please be sure to state > that one > draft replaces another in the cover note that accompanies your > submission. Also, please note that the IDST will not accept drafts > submitted after their respective cutoff dates. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 70th IETF Meeting can be found at > http://www3.ietf.org/meetings/70-cutoff_dates.html. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 15 14:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUtl-00025R-CH; Mon, 15 Oct 2007 14:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUtj-00024T-3A; Mon, 15 Oct 2007 14:42:39 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUtc-0006Iv-SF; Mon, 15 Oct 2007 14:42:39 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63292 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IhUtQ-00075U-Ne; Mon, 15 Oct 2007 19:42:20 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C905A61-7086-4BB9-AD4B-F238FB1DC8FC@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 15 Oct 2007 19:42:19 +0100 To: The IESG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: AVT WG Subject: [AVT] Re: Document Action: 'BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)' to Informational RFC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 15 Oct 2007, at 15:51, The IESG wrote: > The IESG has approved the following document: > > - 'BT's eXtended Network Quality RTP Control Protocol Extended Reports > (RTCP XR XNQ) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product > of an > IETF Working Group. > > The IESG contact person is Cullen Jennings. ... > IESG Note > > The IESG has concerns about vendor code points > allocation in this small namespace and might > not approve similar documents in the future. Can the IESG explain the reasoning behind this note? It appears there is some concern about the size of the namespace, but - since the namespace is managed according to a specification required (not RFC required) policy - withholding approval of similar documents won't help there. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 15 19:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhZPE-0008On-GR; Mon, 15 Oct 2007 19:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhZPC-0008Og-Hp for avt@ietf.org; Mon, 15 Oct 2007 19:31:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhZP6-0000zW-CE for avt@ietf.org; Mon, 15 Oct 2007 19:31:26 -0400 X-IronPort-AV: E=Sophos;i="4.21,279,1188802800"; d="scan'208";a="406723950" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2007 16:31:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9FNVEVC008005; Mon, 15 Oct 2007 16:31:14 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l9FNVAx8005711; Mon, 15 Oct 2007 23:31:10 GMT In-Reply-To: <20071011225618.GD24532@Sun.COM> References: <20071011225618.GD24532@Sun.COM> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 15 Oct 2007 16:30:52 -0700 To: Nicolas Williams X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=342; t=1192491074; x=1193355074; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Review=20of=20draft-ietf-avt-profile-savpf-11 |Sender:=20; bh=Q3FyjjcwLYqSqv9/cno4YisL9x3JJyVZr6jNTCLUfbI=; b=eYV/AF9HMr1Xc8P7cSC6KmVnTAw8C2kG+Nx33Se6BCl5W9GM4sDxJg/MIKlnAgPEMhFQFWC9 MKfW2Df+ICuX6n98W3pArAo5QspYRRQbpnP2k+NrIlJg/fXXA8FHqzxJ; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: secdir-secretary@MIT.EDU, jon.peterson@neustar.biz, carrara@kth.se, secdir@MIT.EDU, avt@ietf.org Subject: [AVT] Re: Review of draft-ietf-avt-profile-savpf-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 11, 2007, at 3:56 PM, Nicolas Williams wrote: > This document does not say whether it is intended to be on the > Standards > Track, Informational, etcetera. I assume it is intended to be on the > Standards Track. Just to answer this one question (I hope the other ones get answered too), yes this is Standards Track. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 16 10:52:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnkn-0004QY-Um; Tue, 16 Oct 2007 10:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnkl-0004Oz-Pt for avt@ietf.org; Tue, 16 Oct 2007 10:50:40 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihnkk-0006M7-FP for avt@ietf.org; Tue, 16 Oct 2007 10:50:39 -0400 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GEob3L010575 for ; Tue, 16 Oct 2007 14:50:37 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9GEoXhx050082 for ; Tue, 16 Oct 2007 08:50:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9GEoad0001334; Tue, 16 Oct 2007 09:50:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9GEoZa1001333; Tue, 16 Oct 2007 09:50:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 16 Oct 2007 09:50:35 -0500 From: Nicolas Williams To: Tim Polk Message-ID: <20071016145035.GZ29257@Sun.COM> References: <20071011225618.GD24532@Sun.COM> <77093CA5-A161-49FF-B3B8-E5E8E3D5A0A7@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77093CA5-A161-49FF-B3B8-E5E8E3D5A0A7@nist.gov> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: fluffy@cisco.com, secdir-secretary@mit.edu, jon.peterson@neustar.biz, carrara@kth.se, secdir@mit.edu, avt@ietf.org Subject: [AVT] Re: [secdir] Review of draft-ietf-avt-profile-savpf-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Tue, Oct 16, 2007 at 09:38:54AM -0400, Tim Polk wrote: > Thanks for highlighting this in your review. I believe that all the > critical information is in RFC 4756, "Key Management Extensions for > Session Description Protocol (SDP) and Real Time Streaming Protocol > (RTSP)", but I am not sure the linkage is clear enough in > profile-savpf-11. Exactly. The text in this I-D is missing some simple wording in the examples, and maybe in the security considerations. Simply stating that the security considerations of various other RFCs should normally suffice, but given that the text in examples 1 and 2 is inconsistent (in terms of specifying what protection the SDPs in them require) I think at least a small update of the description of example 1 would help a lot. > The key management attribute (a=key-mgmt) is defined in RFC 4756. > According to the applicability statement: > > > In contrast, this specification expects endpoints to have > > preconfigured keys or common security infrastructure. It provides > > its own security and is independent of the protection of signaling > > (if any). As a result, it can be applied in environments where > > signaling protection is not turned on, or used hop-by-hop (i.e., > > scenarios where the SDP is not protected end-to-end). This > > specification will, independently of the signaling protection > > applied, ensure end-to-end security establishment for the media. Ah, I see then why example 1 might not have stated any need for integrity protection, though it is needed. > However, the Security Considerations section highlights the need for > integrity protection. The immediate relevant excerpt is: > > > .... However, if the SDP messages > > are not sent integrity protected between the parties, it is > > possible for an active attacker to change attributes without > > being detected. As the key management protocol may > > (indirectly) rely on some of the session information from SDP > > (e.g., address information), an attack on SDP may have indirect > > consequences on the key management. Even if the key management > > protocol does not rely on parameters of SDP and will not be > > affected by manipulation of these, different denial-of- service > > (DoS) attacks aimed at SDP may lead to undesired interruption > > in the setup. See also the attacks described at the end of > > this section. > > > > ... > After reviewing this, it appears that a couple of simple changes > could address integrity protection in profile-savpf-11. First, it > would be nice if Example 1 noted that an integrity protected channel > was required to support the security negotiations. (Examples 3-5 > share that requirement, but I would hope that careful wording in > Example 1 could keep us from repeating ourselves.) More importantly, > the security considerations section really needs an explicit pointer > to the security considerations in RFC 4576. I'm in agreement. Thanks, Nico -- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 16 11:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoA0-0007UE-78; Tue, 16 Oct 2007 11:16:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhTFy-0003gj-No for avt@ietf.org; Mon, 15 Oct 2007 12:57:30 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhTFy-0005ii-EW for avt@ietf.org; Mon, 15 Oct 2007 12:57:30 -0400 Received: (qmail 31878 invoked by uid 0); 15 Oct 2007 16:57:25 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 15 Oct 2007 16:57:25 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Oct 2007 12:57:23 -0400 To: Nicolas Williams ,secdir-secretary@MIT.EDU From: Russ Housley In-Reply-To: <20071011225618.GD24532@Sun.COM> References: <20071011225618.GD24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Tue, 16 Oct 2007 11:16:42 -0400 Cc: fluffy@cisco.com, jon.peterson@neustar.biz, carrara@kth.se, secdir@MIT.EDU, avt@ietf.org Subject: [AVT] Re: [secdir] Review of draft-ietf-avt-profile-savpf-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Message-Id: This might be handled by a reference. When the SDP document reviewed, some text was added to it I believe. Russ At 06:56 PM 10/11/2007, Nicolas Williams wrote: >Additionally, it's not clear to me whether whether there are any >attributes of an SDP besides a=key-mgmt: and a=crypto: which might need >integrity and even confidentiality protection. Additional text about >this would be good. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 16 11:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoA0-0007UT-M9; Tue, 16 Oct 2007 11:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmdt-0006L0-5l for avt@ietf.org; Tue, 16 Oct 2007 09:39:29 -0400 Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihmdi-00044z-6r for avt@ietf.org; Tue, 16 Oct 2007 09:39:29 -0400 Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l9GDctKx018579; Tue, 16 Oct 2007 09:38:55 -0400 In-Reply-To: <20071011225618.GD24532@Sun.COM> References: <20071011225618.GD24532@Sun.COM> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77093CA5-A161-49FF-B3B8-E5E8E3D5A0A7@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 16 Oct 2007 09:38:54 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-Mailman-Approved-At: Tue, 16 Oct 2007 11:16:42 -0400 Cc: fluffy@cisco.com, secdir-secretary@mit.edu, jon.peterson@neustar.biz, carrara@kth.se, secdir@mit.edu, avt@ietf.org Subject: [AVT] Re: [secdir] Review of draft-ietf-avt-profile-savpf-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Nico, Thanks for highlighting this in your review. I believe that all the critical information is in RFC 4756, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", but I am not sure the linkage is clear enough in profile-savpf-11. The key management attribute (a=key-mgmt) is defined in RFC 4756. According to the applicability statement: > In contrast, this specification expects endpoints to have > preconfigured keys or common security infrastructure. It provides > its own security and is independent of the protection of signaling > (if any). As a result, it can be applied in environments where > signaling protection is not turned on, or used hop-by-hop (i.e., > scenarios where the SDP is not protected end-to-end). This > specification will, independently of the signaling protection > applied, ensure end-to-end security establishment for the media. > However, the Security Considerations section highlights the need for integrity protection. The immediate relevant excerpt is: > .... However, if the SDP messages > are not sent > integrity protected between the parties, it is possible for an > active > attacker to change attributes without being detected. As the key > management protocol may (indirectly) rely on some of the session > information from SDP (e.g., address information), an attack on SDP > may have indirect consequences on the key management. Even if the > key management protocol does not rely on parameters of SDP and will > not be affected by manipulation of these, different denial-of- > service > (DoS) attacks aimed at SDP may lead to undesired interruption in > the > setup. See also the attacks described at the end of this section. > > The only integrity-protected attribute of the media stream is, > in the > framework proposed here, the set of key management protocols. For > instance, it is possible to (1) swap key management offers > across SDP > messages, or (2) inject a previous key management offer into a new > SDP message. Making the (necessary) assumption that all > involved key > management protocols are secure, the second attack will be detected > by replay protection mechanisms of the key management protocol(s). > Making the further assumption that, according to normal best > current > practice, the production of each key management offer is done with > independent (pseudo)random choices (for session keys and other > parameters), the first attack will either be detected in the > Responder's (now incorrect) verification reply message (if such is > used) or be a pure DoS attack, resulting in Initiator and Responder > using different keys. After reviewing this, it appears that a couple of simple changes could address integrity protection in profile-savpf-11. First, it would be nice if Example 1 noted that an integrity protected channel was required to support the security negotiations. (Examples 3-5 share that requirement, but I would hope that careful wording in Example 1 could keep us from repeating ourselves.) More importantly, the security considerations section really needs an explicit pointer to the security considerations in RFC 4576. Thanks, Tim On Oct 11, 2007, at 6:56 PM, Nicolas Williams wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document does not say whether it is intended to be on the > Standards > Track, Informational, etcetera. I assume it is intended to be on the > Standards Track. > > Although some of the text in this document is somewhat confusing, > has a > number of grammatical and other editing errors, and in many places > fails > to expand acronyms, it is a simple profile of SRTP. The security > considerations section covers all the areas that I think needed to be > covered, except, perhaps, two things. > > In section 3.4 example #2 contains symmetric key material which, as > the > description correctly states, requires confidentiality protection by > whatever channel is used to obtain the given session description. > Other > examples, such as example #1, might require at least integrity > protection, but this is not discussed. It may be that they do not > require integrity protection, but I can't tell as I'm not an expert in > MIKEY (which was used in the example) and, in any case, other key > management frameworks can be used and some might require at least > integrity protection. For example, when unauthenticated DH key > exchanges are used I would expect integrity protection by some other > channel to be required in order to prevent MITM attacks. A small > amount > of text should cover this case. > > Additionally, it's not clear to me whether whether there are any > attributes of an SDP besides a=key-mgmt: and a=crypto: which might > need > integrity and even confidentiality protection. Additional text about > this would be good. > > Nico > -- > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 17 05:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii5JZ-000791-A7; Wed, 17 Oct 2007 05:35:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii5JY-00076Q-0l for avt@ietf.org; Wed, 17 Oct 2007 05:35:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii5JT-0004xv-5j for avt@ietf.org; Wed, 17 Oct 2007 05:35:39 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8D912200D4; Wed, 17 Oct 2007 11:35:38 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-2b-4715d76a3374 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 73F5420798; Wed, 17 Oct 2007 11:35:38 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 11:35:37 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 11:35:37 +0200 Message-ID: <4715D769.9010203@ericsson.com> Date: Wed, 17 Oct 2007 11:35:37 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Polk Subject: Re: [AVT] Re: [secdir] Review of draft-ietf-avt-profile-savpf-11 References: <20071011225618.GD24532@Sun.COM> <77093CA5-A161-49FF-B3B8-E5E8E3D5A0A7@nist.gov> In-Reply-To: <77093CA5-A161-49FF-B3B8-E5E8E3D5A0A7@nist.gov> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 09:35:37.0603 (UTC) FILETIME=[1315BD30:01C810A1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: fluffy@cisco.com, secdir-secretary@mit.edu, jon.peterson@neustar.biz, carrara@kth.se, secdir@mit.edu, avt@ietf.org, Nicolas Williams X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Tim Polk skrev: > Nico, > > Thanks for highlighting this in your review. I believe that all the > critical information > is in RFC 4756, "Key Management Extensions for Session Description Protocol > (SDP) and Real Time Streaming Protocol (RTSP)", but I am not sure the > linkage > is clear enough in profile-savpf-11. > > The key management attribute (a=key-mgmt) is defined in RFC 4756. > According > to the applicability statement: > >> In contrast, this specification expects endpoints to have >> preconfigured keys or common security infrastructure. It provides >> its own security and is independent of the protection of signaling >> (if any). As a result, it can be applied in environments where >> signaling protection is not turned on, or used hop-by-hop (i.e., >> scenarios where the SDP is not protected end-to-end). This >> specification will, independently of the signaling protection >> applied, ensure end-to-end security establishment for the media. >> > > However, the Security Considerations section highlights the need for > integrity protection. The immediate relevant excerpt is: > >> .... However, if the SDP messages >> are not sent >> integrity protected between the parties, it is possible for an active >> attacker to change attributes without being detected. As the key >> management protocol may (indirectly) rely on some of the session >> information from SDP (e.g., address information), an attack on SDP >> may have indirect consequences on the key management. Even if the >> key management protocol does not rely on parameters of SDP and will >> not be affected by manipulation of these, different denial-of-service >> (DoS) attacks aimed at SDP may lead to undesired interruption in the >> setup. See also the attacks described at the end of this section. >> >> The only integrity-protected attribute of the media stream is, in the >> framework proposed here, the set of key management protocols. For >> instance, it is possible to (1) swap key management offers across SDP >> messages, or (2) inject a previous key management offer into a new >> SDP message. Making the (necessary) assumption that all involved key >> management protocols are secure, the second attack will be detected >> by replay protection mechanisms of the key management protocol(s). >> Making the further assumption that, according to normal best current >> practice, the production of each key management offer is done with >> independent (pseudo)random choices (for session keys and other >> parameters), the first attack will either be detected in the >> Responder's (now incorrect) verification reply message (if such is >> used) or be a pure DoS attack, resulting in Initiator and Responder >> using different keys. > > After reviewing this, it appears that a couple of simple changes could > address > integrity protection in profile-savpf-11. First, it would be nice if > Example 1 > noted that an integrity protected channel was required to support the > security > negotiations. (Examples 3-5 share that requirement, but I would hope that > careful wording in Example 1 could keep us from repeating ourselves.) > More importantly, the security considerations section really needs an > explicit > pointer to the security considerations in RFC 4576. > To my knowledge MIKEY when used in SDP according to RFC 4567 it will integrity protect the most important SDP parts also to prevent bid-down attacks. So it is not guaranteed that full integrity protection of the SDP is needed. However, it is of course advisable to protect against other attacks on the SDP. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 23 10:06:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKLs-0004lS-MV; Tue, 23 Oct 2007 10:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKLr-0004iN-QW for avt@ietf.org; Tue, 23 Oct 2007 10:03:23 -0400 Received: from smtp105.rog.mail.re2.yahoo.com ([206.190.36.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkKLh-0001Y0-MF for avt@ietf.org; Tue, 23 Oct 2007 10:03:19 -0400 Received: (qmail 38492 invoked from network); 23 Oct 2007 14:02:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mg7pCufLdF8KTIo8xZpXNbL3Xca52YxO3eW02ozi9Kmp30jkiVOY/M8p5lg2egHYe0DR3/eB6mL3wbrYhsbzL1s47ozMY+3qNyi0eDosXxEoU2oQB3oOECsXHVOawWhpN1ElScMzGMFKiFa3OXppdMbyBQq88HVYGAFTvGvE9cY= ; Received: from unknown (HELO ?192.168.10.170?) (tom.taylor@rogers.com@70.91.200.60 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 23 Oct 2007 14:02:32 -0000 X-YMail-OSG: .WcpLZQVM1lhXnrUZP85DCcdnzmVBkzxkKY0JHTu91E5Rf3QTAOfFi2_8YmzwTgtpg-- Message-ID: <471DFEFC.9080407@rogers.com> Date: Tue, 23 Oct 2007 10:02:36 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] Open issue on hdrext draft References: <4704D1F5.3010809@ericsson.com> <47051932.2080909@ericsson.com> In-Reply-To: <47051932.2080909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: fluffy@cisco.com, Magnus Westerlund , Imed.Bouazizi@nokia.com, Dave Singer X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org This was the last word on the topic, quite a while ago. I think we have agreement on Expert Review and a publicly available specification. One of the criteria for the expert would be to prevent excessive duplication of functionality. What else? Magnus Westerlund wrote: > > Dave Singer skrev: >> At 13:43 +0200 4/10/07, Magnus Westerlund wrote: >>> Imed.Bouazizi@nokia.com skrev: >>> >>> What we are discussing is what rules applies for the IETF URN space, >>> i.e. the header extensions that will look like they are blessed by IETF. >>> The current draft version was in fact a) as this specified >>> "Specification Required" from RFC 2434: >>> >>> " Specification Required - Values and their meaning must be >>> documented in an RFC or other permanent and readily available >>> reference, in sufficient detail so that interoperability >>> between independent implementations is possible." >>> >>> I think A is fine but would probably prefer this to be b) with explicit >>> rule requiring a publicly available specification. >> I'm sorry, I may have mis-written something, since I tried to agree with >> you here! The current intention is that for the IETF URN space, a >> standards-track RFC is required. And that for IANA registration, an >> IETF URN is required: >> >> "To be registered >> with IANA, the extension MUST use this IETF URN form; to use the IETF >> URN form, the extension MUST be defined in an RFC." >> >> If there is other text that isn't clear, can you tell me what it is? > > In section 9.1 of draft-ietf-avt-rtp-hdrext-13: > > The rtp-hdrext namespace under urn:ietf:params: needs to be created > for management, referenced to RFCxxxx. Additions in this namespace > shall be made on the basis of "Specification Required". > > Which indicates that you can add new entires only requiring a > specification which is actually a contradiction to what is written in > Section 5: > > For extensions defined in RFCs, the URI used SHOULD be a URN starting > "urn:ietf:params:rtp-hdrext:" and followed by a registered, > descriptive name. These URNs are managed by IANA. To be registered > with IANA, the extension MUST use this IETF URN form; to use the IETF > URN form, the extension MUST be defined in an RFC. > > > So I think you need to use the Standards Action level in 9.1 to match > the section 5 text. > >>> Having an expert look >>> at any registrations to ensure that they are not totally wacko is in my >>> book a good thing. >> Me too, no dispute here. >> >>> But at the same time put minimal bar on the >>> registrations. Other SDOs should basically be able to send in an email >>> with a request containing a reference and things usually go through. >>> >> So, you would permit non-IETF URIs in the IANA registry, also, after, >> what 'expert review' and with 'publicly available specification required'? >> >> That's fine by me also. >> > > I think we can allow people to use the public IANA registry for header > extensions as long as there is a reasonable and publicly available. > > Thus I would use Expert Review and some requirements on what the Expert > is allowed to approve. Where the primary is: Open publicly available > Specification. But there is likely that some more should be written. > > Cheers > > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 24 04:32:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikbbb-0006K6-T7; Wed, 24 Oct 2007 04:28:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikbba-0006Jh-D9 for avt@ietf.org; Wed, 24 Oct 2007 04:28:46 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkbbX-0005MT-I7 for avt@ietf.org; Wed, 24 Oct 2007 04:28:44 -0400 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id D887016B0632; Wed, 24 Oct 2007 01:28:42 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id B67CA2804D; Wed, 24 Oct 2007 01:28:42 -0700 (PDT) X-AuditID: 11807134-a5659bb000000c52-67-471f0239d70e Received: from [17.84.23.140] (unknown [17.84.20.157]) by relay14.apple.com (Apple SCV relay) with ESMTP id 9186628050; Wed, 24 Oct 2007 01:28:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <471DFEFC.9080407@rogers.com> References: <4704D1F5.3010809@ericsson.com> <47051932.2080909@ericsson.com> <471DFEFC.9080407@rogers.com> Date: Wed, 24 Oct 2007 16:27:01 +0800 To: Tom Taylor , avt@ietf.org From: Dave Singer Subject: Re: [AVT] Open issue on hdrext draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: fluffy@cisco.com, Magnus Westerlund , Imed.Bouazizi@nokia.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org At 10:02 -0400 23/10/07, Tom Taylor wrote: >This was the last word on the topic, quite a while ago. I think we >have agreement on Expert Review and a publicly available >specification. One of the criteria for the expert would be to >prevent excessive duplication of functionality. What else? complies with the requirements of RTP and the hdrext specification, for extensions (notably, that the stream is still decodable if the extension is ignored or not recognized) technical consistency (in itself and with RTP), completeness, and comprehensibility does not duplicate functionality in existing IETF specifications (including RTP itself), or other extensions already registered anything else? >Magnus Westerlund wrote: >> >>Dave Singer skrev: >>>At 13:43 +0200 4/10/07, Magnus Westerlund wrote: >>>>Imed.Bouazizi@nokia.com skrev: >>>> >>>>What we are discussing is what rules applies for the IETF URN space, >>>>i.e. the header extensions that will look like they are blessed by IETF. >>>>The current draft version was in fact a) as this specified >>>>"Specification Required" from RFC 2434: >>>> >>>>" Specification Required - Values and their meaning must be >>>> documented in an RFC or other permanent and readily available >>>> reference, in sufficient detail so that interoperability >>>> between independent implementations is possible." >>>> >>>>I think A is fine but would probably prefer this to be b) with explicit >>>>rule requiring a publicly available specification. >>>I'm sorry, I may have mis-written something, since I tried to agree with >>>you here! The current intention is that for the IETF URN space, a >>>standards-track RFC is required. And that for IANA registration, an >>>IETF URN is required: >>> >>>"To be registered >>> with IANA, the extension MUST use this IETF URN form; to use the IETF >>> URN form, the extension MUST be defined in an RFC." >>> >>>If there is other text that isn't clear, can you tell me what it is? >> >>In section 9.1 of draft-ietf-avt-rtp-hdrext-13: >> >> The rtp-hdrext namespace under urn:ietf:params: needs to be created >> for management, referenced to RFCxxxx. Additions in this namespace >> shall be made on the basis of "Specification Required". >> >>Which indicates that you can add new entires only requiring a >>specification which is actually a contradiction to what is written in >>Section 5: >> >> For extensions defined in RFCs, the URI used SHOULD be a URN starting >> "urn:ietf:params:rtp-hdrext:" and followed by a registered, >> descriptive name. These URNs are managed by IANA. To be registered >> with IANA, the extension MUST use this IETF URN form; to use the IETF >> URN form, the extension MUST be defined in an RFC. >> >> >>So I think you need to use the Standards Action level in 9.1 to match >>the section 5 text. >> >>>>Having an expert look >>>>at any registrations to ensure that they are not totally wacko is in my >>>>book a good thing. >>>Me too, no dispute here. >>> >>>>But at the same time put minimal bar on the >>>>registrations. Other SDOs should basically be able to send in an email >>>>with a request containing a reference and things usually go through. >>>> >>>So, you would permit non-IETF URIs in the IANA registry, also, after, >>>what 'expert review' and with 'publicly available specification required'? >>> >>>That's fine by me also. >>> >> >>I think we can allow people to use the public IANA registry for header >>extensions as long as there is a reasonable and publicly available. >> >>Thus I would use Expert Review and some requirements on what the Expert >>is allowed to approve. Where the primary is: Open publicly available >>Specification. But there is likely that some more should be written. >> >>Cheers >> >> >>Magnus Westerlund >> >>IETF Transport Area Director & TSVWG Chair >>---------------------------------------------------------------------- >>Multimedia Technologies, Ericsson Research EAB/TVM/M >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>---------------------------------------------------------------------- >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt -- David Singer Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 24 13:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikjdu-00034V-Mm; Wed, 24 Oct 2007 13:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikjdt-00034A-8S; Wed, 24 Oct 2007 13:03:41 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikjdp-0005ut-Uz; Wed, 24 Oct 2007 13:03:41 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id CDB1B33C28; Wed, 24 Oct 2007 09:59:08 -0700 (PDT) Date: Wed, 24 Oct 2007 09:59:08 -0700 From: Eric Rescorla To: avt@ietf.org, mmusic@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071024165908.CDB1B33C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [AVT] Symmetry breaking for DTLS-SRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org TLS (and by extension) DTLS-SRTP requires unambiguity about which side is to be the client and which is the server. This isn't an issue of credentials--DTLS-SRTP assumes that each side can take either role--it's just that TLS requires that one side initiate the handshake. My original intention had been to make this conditional on which side was the offerer and which was the answerer, but JDR pointed out in ORD that there are cases involving 3PCC where it's not unambiguous which is which. Here's the paradigmatic case, transcribed from a phone call with JDR (so any errors are my fault): Alice Controller Bob ------------------------------------------------------------------ INVITE + Offer -> INVITE -> <- OK + Offer <- OK + Answer ACK + Answer -> ACK -> Because the controller sends an INVITE with no offer, Bob is the offererer, and of course Alice is. So, you can't use offerer or answerer to break symmetry. This same problem occurs with ICE, which uses a random tiebreaker value in the ICE messages to determine which side should take which role (controlling vs. controlled). This works because in ICE both sides are trying to transmit so they quickly detect conflicts. Unfortunately, in DTLS-SRTP, the server just waits so if the rule we adopt allows both sides to think they are the server then we get deadlock. The above exchange shows how both sides can be offerer so clearly we can't have offerer=server, but it seems that we could make a new exchange where both sides are answerer in which case we can't have offerer=client. JDR tells me that we don't have an actual use case like this yet but I would not want to count on that unless we're very sure. We could use exactly the trick that ICE uses but that requires modifying DTLS to make the server send messages unprompted. I don't think that's necessary here because we can break the tie in the SDP where we announce the DTLS-SRTP capability (however that's done). The basic principle is this: 1. Each side generates a random tiebreaker value T. 2. In the SDP offer/answer, he indicates whether he wishes to be the TLS client or server (if you're the offerer you SHOULD ask to be the server since that's faster, and vice versa). 3. If each side sees a consistent view (one client, one server) then that is what is used. 4. If the views are inconsistent, then the side with the higher T is be the client. This is basically the same algorithm as used with ICE, just moving the tiebreaker into the SDP. Does anyone see a problem with this? -Ekr _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 24 15:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklib-0007I9-RZ; Wed, 24 Oct 2007 15:16:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklia-0007Fw-Bu; Wed, 24 Oct 2007 15:16:40 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkliZ-00070L-JE; Wed, 24 Oct 2007 15:16:40 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQF00B3MK74H7@siemenscomms.co.uk>; Wed, 24 Oct 2007 20:16:16 +0100 (BST) Date: Wed, 24 Oct 2007 20:16:37 +0100 From: "Elwell, John" In-reply-to: <20071024165908.CDB1B33C28@delta.rtfm.com> To: Eric Rescorla , avt@ietf.org, mmusic@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D5E4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] Symmetry breaking for DTLS-SRTP Thread-Index: AcgWYYUSDnaoYlqJS0+cdjPoIgDg1QADmipA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20071024165908.CDB1B33C28@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: [AVT] RE: [MMUSIC] Symmetry breaking for DTLS-SRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Ekr, I don't have a problem with the solution, but I am doubtful whether it is a problem we need to solve. The case illustrated is based on the assumption that offer and answer are symmetrical, in the sense that an offer can be reused as an answer (and vice versa). In this case the offer from A becomes an answer to B and vice versa. There are two extensions to SDP that I am aware of that break this, and therefore any controller that misuses SDP in this way will screw things up. One example is the key management extension when used to carry MIKEY, because a MIKEY request (which always goes in the offer) is very different in syntax and semantics from a MIKEY response (which always goes in the answer). Of course, this will not apply when using DTLS-SRTP as the means of key management. The second example is the SDP capability negotiation draft, which certainly will be applicable with DTLS-SRTP. I am not aware of how the particular flow shown would arise. It is not documented in RFC 3725 (3PCC). It has similarities to flow II in RFC 3725, which the RFC does not recommend. The other 3PCC flows in RFC 3725 do not mix up offers and answers in this way. I also questioned the need for the solution in ICE, but as it came virtually for free, it was not worth arguing about. If we continue this discussion, I would suggest we stick to the MMUSIC list rather than AVT. John > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: 24 October 2007 17:59 > To: avt@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] Symmetry breaking for DTLS-SRTP > > TLS (and by extension) DTLS-SRTP requires unambiguity about which side > is to be the client and which is the server. This isn't an issue of > credentials--DTLS-SRTP assumes that each side can take either > role--it's just that TLS requires that one side initiate the > handshake. My original intention had been to make this conditional on > which side was the offerer and which was the answerer, but JDR pointed > out in ORD that there are cases involving 3PCC where it's not > unambiguous which is which. > > Here's the paradigmatic case, transcribed from a phone call with > JDR (so any errors are my fault): > > > Alice Controller Bob > ------------------------------------------------------------------ > INVITE + Offer -> > INVITE -> > <- OK + Offer > <- OK + Answer > ACK + Answer -> > ACK -> > > Because the controller sends an INVITE with no offer, Bob is the > offererer, and of course Alice is. So, you can't use offerer > or answerer to break symmetry. > > This same problem occurs with ICE, which uses a random tiebreaker > value in the ICE messages to determine which side should take > which role (controlling vs. controlled). This works because > in ICE both sides are trying to transmit so they quickly > detect conflicts. Unfortunately, in DTLS-SRTP, the server just > waits so if the rule we adopt allows both sides to think they > are the server then we get deadlock. The above exchange > shows how both sides can be offerer so clearly we can't have > offerer=server, but it seems that we could make a new exchange > where both sides are answerer in which case we can't have > offerer=client. JDR tells me that we don't have an actual > use case like this yet but I would not want to count on that > unless we're very sure. > > We could use exactly the trick that ICE uses but that requires > modifying DTLS to make the server send messages unprompted. > I don't think that's necessary here because we can break > the tie in the SDP where we announce the DTLS-SRTP capability > (however that's done). > > The basic principle is this: > 1. Each side generates a random tiebreaker value T. > 2. In the SDP offer/answer, he indicates whether he wishes > to be the TLS client or server (if you're the offerer > you SHOULD ask to be the server since that's faster, > and vice versa). > 3. If each side sees a consistent view (one client, one > server) then that is what is used. > 4. If the views are inconsistent, then the side with the > higher T is be the client. > > This is basically the same algorithm as used with ICE, just > moving the tiebreaker into the SDP. > > Does anyone see a problem with this? > > -Ekr > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 25 05:29:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikyyc-0008IP-2H; Thu, 25 Oct 2007 05:26:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikyya-0007Rt-Ed for avt@ietf.org; Thu, 25 Oct 2007 05:26:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkyyU-0000jQ-Qn for avt@ietf.org; Thu, 25 Oct 2007 05:25:59 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1890D20FBF; Thu, 25 Oct 2007 11:25:58 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-a5-472061269b5c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 05EE220178; Thu, 25 Oct 2007 11:25:58 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 11:25:57 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 11:25:57 +0200 Message-ID: <47206125.6090801@ericsson.com> Date: Thu, 25 Oct 2007 11:25:57 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Singer Subject: Re: [AVT] Open issue on hdrext draft References: <4704D1F5.3010809@ericsson.com> <47051932.2080909@ericsson.com> <471DFEFC.9080407@rogers.com> In-Reply-To: X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 09:25:57.0419 (UTC) FILETIME=[0C92AFB0:01C816E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: fluffy@cisco.com, Imed.Bouazizi@nokia.com, Tom Taylor , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dave Singer skrev: > At 10:02 -0400 23/10/07, Tom Taylor wrote: >> This was the last word on the topic, quite a while ago. I think we >> have agreement on Expert Review and a publicly available >> specification. One of the criteria for the expert would be to prevent >> excessive duplication of functionality. What else? > > complies with the requirements of RTP and the hdrext specification, for > extensions (notably, that the stream is still decodable if the extension > is ignored or not recognized) > > technical consistency (in itself and with RTP), completeness, and > comprehensibility > > does not duplicate functionality in existing IETF specifications > (including RTP itself), or other extensions already registered > > anything else? > Contains a security analysis regarding the content of the header extension. That it is general applicable, for example point to multi-point safe and correctly describes limitations if they exist. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 25 13:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Ij-0000gw-ON; Thu, 25 Oct 2007 13:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Ig-0000fY-Nl; Thu, 25 Oct 2007 13:15:19 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6If-0004WU-6d; Thu, 25 Oct 2007 13:15:18 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E8A1226E83; Thu, 25 Oct 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Il6IP-0002Vy-RJ; Thu, 25 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 Oct 2007 13:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-seed-srtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) Author(s) : S. Yoon, et al. Filename : draft-ietf-avt-seed-srtp-00.txt Pages : 6 Date : 2007-10-25 This document describes the use of SEED block cipher algorithm in the Secure Real-time Transport Protocol [3] for confidentiality to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-seed-srtp-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-seed-srtp-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@From avt-bounces@ietf.org Thu Oct 25 13:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Ij-0000gw-ON; Thu, 25 Oct 2007 13:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Ig-0000fY-Nl; Thu, 25 Oct 2007 13:15:19 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6If-0004WU-6d; Thu, 25 Oct 2007 13:15:18 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E8A1226E83; Thu, 25 Oct 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Il6IP-0002Vy-RJ; Thu, 25 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 Oct 2007 13:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-seed-srtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) Author(s) : S. Yoon, et al. Filename : draft-ietf-avt-seed-srtp-00.txt Pages : 6 Date : 2007-10-25 This document describes the use of SEED block cipher algorithm in the Secure Real-time Transport Protocol [3] for confidentiality to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-seed-srtp-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-seed-srtp-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: <2007-10-25122143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-seed-srtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-seed-srtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-25122143.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 25 13:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6J6-0001Gw-Cs; Thu, 25 Oct 2007 13:15:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6J5-0001GL-4t; Thu, 25 Oct 2007 13:15:43 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il6J4-0006fy-OX; Thu, 25 Oct 2007 13:15:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 68B8B175E0; Thu, 25 Oct 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Il6IP-0002W8-TW; Thu, 25 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 Oct 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-evrc-wb-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 EVRC-WB codec and media subtype updates for EVRC-B codec Author(s) : H. Desineni, Q. Xie Filename : draft-ietf-avt-rtp-evrc-wb-04.txt Pages : 37 Date : 2007-10-25 This document specifies real-time transport protocol (RTP) payload formats to be used for the EVRC wideband codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-evrc-wb-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-rtp-evrc-wb-04.txt". NOTE: The mail sietf.org" Content-Type: text/plain Content-ID: <2007-10-25122143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-seed-srtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-seed-srtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-25122143.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 25 13:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6J6-0001Gw-Cs; Thu, 25 Oct 2007 13:15:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6J5-0001GL-4t; Thu, 25 Oct 2007 13:15:43 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il6J4-0006fy-OX; Thu, 25 Oct 2007 13:15:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 68B8B175E0; Thu, 25 Oct 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Il6IP-0002W8-TW; Thu, 25 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 Oct 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-evrc-wb-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 EVRC-WB codec and media subtype updates for EVRC-B codec Author(s) : H. Desineni, Q. Xie Filename : draft-ietf-avt-rtp-evrc-wb-04.txt Pages : 37 Date : 2007-10-25 This document specifies real-time transport protocol (RTP) payload formats to be used for the EVRC wideband codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-evrc-wb-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-rtp-evrc-wb-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: <2007-10-25122726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-evrc-wb-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-evrc-wb-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-25122726.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- erver 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: <2007-10-25122726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-evrc-wb-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-evrc-wb-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-25122726.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 26 09:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQS-00040f-CA; Fri, 26 Oct 2007 09:40:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQO-0003rJ-Qj; Fri, 26 Oct 2007 09:40:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlPQO-00022x-Ds; Fri, 26 Oct 2007 09:40:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 51F0A2AC7E; Fri, 26 Oct 2007 13:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlPPu-0001Ud-1p; Fri, 26 Oct 2007 09:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 09:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-avpf-ccm-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 : Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-avpf-ccm-10.txt Pages : 69 Date : 2007-10-26 This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate and Temporal Spatial Trade-off. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-avpf-ccm-10.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-avpf-ccm-10.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 cFrom avt-bounces@ietf.org Fri Oct 26 09:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQS-00040f-CA; Fri, 26 Oct 2007 09:40:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQO-0003rJ-Qj; Fri, 26 Oct 2007 09:40:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlPQO-00022x-Ds; Fri, 26 Oct 2007 09:40:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 51F0A2AC7E; Fri, 26 Oct 2007 13:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlPPu-0001Ud-1p; Fri, 26 Oct 2007 09:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 09:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-avpf-ccm-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 : Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-avpf-ccm-10.txt Pages : 69 Date : 2007-10-26 This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate and Temporal Spatial Trade-off. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-avpf-ccm-10.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-avpf-ccm-10.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: <2007-10-26093405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-avpf-ccm-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-avpf-ccm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26093405.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 26 09:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQQ-0003rY-6x; Fri, 26 Oct 2007 09:40:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQO-0003rE-NX; Fri, 26 Oct 2007 09:40:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlPQO-00022w-BR; Fri, 26 Oct 2007 09:40:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 473442AC76; Fri, 26 Oct 2007 13:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlPPu-0001UY-0X; Fri, 26 Oct 2007 09:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 09:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-topologies-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 Topologies Author(s) : M. Westerlund, S. Wenger Filename : draft-ietf-avt-topologies-07.txt Pages : 23 Date : 2007-10-26 This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-topologies-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body tyompliant 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: <2007-10-26093405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-avpf-ccm-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-avpf-ccm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26093405.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 26 09:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQQ-0003rY-6x; Fri, 26 Oct 2007 09:40:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPQO-0003rE-NX; Fri, 26 Oct 2007 09:40:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlPQO-00022w-BR; Fri, 26 Oct 2007 09:40:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 473442AC76; Fri, 26 Oct 2007 13:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlPPu-0001UY-0X; Fri, 26 Oct 2007 09:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 09:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-topologies-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@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 Topologies Author(s) : M. Westerlund, S. Wenger Filename : draft-ietf-avt-topologies-07.txt Pages : 23 Date : 2007-10-26 This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-topologies-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-topologies-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-26093350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-topologies-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-topologies-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26093350.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- pe: "FILE /internet-drafts/draft-ietf-avt-topologies-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-26093350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-topologies-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-topologies-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26093350.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 26 11:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQxk-0003av-OO; Fri, 26 Oct 2007 11:19:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQxj-0003Y1-JX for avt@ietf.org; Fri, 26 Oct 2007 11:19:03 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQxj-0005tJ-6h for avt@ietf.org; Fri, 26 Oct 2007 11:19:03 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A224D20A3A for ; Fri, 26 Oct 2007 17:19:02 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-24-472205662e4d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 96E0F20A52 for ; Fri, 26 Oct 2007 17:19:02 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 17:18:57 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 17:18:57 +0200 Message-ID: <47220560.1090401@ericsson.com> Date: Fri, 26 Oct 2007 17:18:56 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF AVT WG X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 15:18:57.0015 (UTC) FILETIME=[87025070:01C817E3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [AVT] Updates of CCM and Topologies X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, We have just submitted an update of the CCM and Topologies draft. These are updates to address some comments received from IETF last call reviewers. There where no substantial changes only some minor text clarifications and fixes of typos. There is one promotion of a lower case shall to SHALL in CCM. Diffs http://tools.ietf.org/wg/avt/draft-ietf-avt-avpf-ccm/draft-ietf-avt-avpf-ccm-10-from-09.diff.html http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-07-from-06.diff.html Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 26 11:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlR8P-0006Ew-9K; Fri, 26 Oct 2007 11:30:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlR8O-0006Eh-6d for avt@ietf.org; Fri, 26 Oct 2007 11:30:04 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlR8N-00068r-Oz for avt@ietf.org; Fri, 26 Oct 2007 11:30:04 -0400 Received: from cluster-e.mailcontrol.com (rly43e.srv.mailcontrol.com [10.69.1.153]) by rly14h.srv.mailcontrol.com (MailControl) with ESMTP id l9QFTxiv006804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Oct 2007 16:30:00 +0100 Received: from rly43e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly43e.srv.mailcontrol.com (MailControl) with ESMTP id l9QFTppW029653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Oct 2007 16:29:56 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly43e.srv.mailcontrol.com (MailControl) id l9QFSurf024388 for avt@ietf.org; Fri, 26 Oct 2007 16:28:56 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly43e-eth0.srv.mailcontrol.com (envelope-sender Jose.Rey@eu.panasonic.com) (MIMEDefang) with ESMTP id l9QFSnoS023547; Fri, 26 Oct 2007 16:28:56 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4ffc_b753fe1c_83d7_11dc_8de2_0030482aac25; Fri, 26 Oct 2007 17:25:42 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007102617275242-101818 ; Fri, 26 Oct 2007 17:27:52 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.048,BAYES_00: -1.665,TOTAL_SCORE: -1.617 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 26 Oct 2007 17:27:30 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions regarding unicast RTCP extensions for SSM sessions Thread-Index: AcgX5Lmm0mHoztMmSbG0EmT5bRlxzQ== To: "Joerg Ott" , , Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB594C2F@lan-ex-02.panasonic.de> Date: Fri, 26 Oct 2007 17:27:31 +0200 From: "Jose Rey" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.69.1.153 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF AVT WG Subject: [AVT] Questions regarding unicast RTCP extensions for SSM sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, I've read draft -13 and have some questions and comments: 1.- While the text in p.5 says: "The precise setup and configuration of the media senders and their interaction with the Distribution Source is beyond the scope of this document ... " and=20 the example given in p. 50, S. 15.3=20 "the Distribution Source also needs to relay media traffic from each Media Sender to the receivers and to forward (aggregated) feedback from the receivers to the Media Senders. In addition, the Distribution Source relays RTCP packets ^^^^^^ (SRs) from each Media Sender to the other two." ^^^^^^^^^^^^^^^^^ is a bit confusing to me. My questions are a) whether this SR forwarding = is mandatory or just an example configuration and b) if so, of what use = for Media Senders would be to have the SR of the other Media Senders?, = and 3) is this what is meant in S.4 with 'virtual multicast = environment'? (see below) I don't understand the motivation, that's all. "Distribution Source: In an SSM context, only one entity distributes RTP data and redistributes RTCP information to all receivers. This entity is called the Distribution Source. It is also responsible for forwarding RTCP feedback to the Media Senders and thus creates a virtual multicast environment in which RTP and RTCP can be applied." 2.- S 10.2, p. 36 says: There SHOULD be exactly one "a=3Dsource-filter:incl" attribute = listing the address of the sender. The RTCP port MUST be derived from the ^^^^^^ m=3D line of the media description. I guess 'sender' is the Distribution Source. 3.- In 11.3. I guess when 'source' is written in this section it = actually means 'Distribution Source'. If so, the text alternates between = 'source' and 'Distribution Source', which is confusing.=20 I also found some nits: N1.- P.4 says: "In the Summary Feedback Model the node or nodes performing feedback = compute ^^^^^^^^^^ =20 summary information which is distributed to the members by the Distribution Source." I believe 'receiving' instead of performing is what is meant. N2.- S 10.1, p. 35 : it seems one bracket "]" got forgotten rtcp-unicast:rsi *(SP :]) ^ Also later below: / "rsi" *(SP rsi-rule] =20 ^ Thanks in advance, Jos=E9 =20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 26 13:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTGt-0007S4-9V; Fri, 26 Oct 2007 13:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPKg-00020d-Q7 for avt@ietf.org; Fri, 26 Oct 2007 09:34:38 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlPKf-0004Pp-Lu for avt@ietf.org; Fri, 26 Oct 2007 09:34:38 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 9F086328F8; Fri, 26 Oct 2007 13:34:07 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IlPKB-0003rf-Hx; Fri, 26 Oct 2007 09:34:07 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: magnus.westerlund@ericsson.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 26 Oct 2007 09:34:07 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:46:43 -0400 Cc: bo.burman@ericsson.com, Umesh.1.Chandra@nokia.com, stewe@stewe.org, avt@ietf.org Subject: [AVT] New Version Notification for draft-ietf-avt-avpf-ccm-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org A new version of I-D, draft-ietf-avt-avpf-ccm-10.txt has been successfuly submitted by Magnus Westerlund and posted to the IETF repository. Filename: draft-ietf-avt-avpf-ccm Revision: 10 Title: Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Creation_date: 2007-10-26 WG ID: avt Number_of_pages: 69 Abstract: This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate and Temporal Spatial Trade-off. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 26 13:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTGl-0007PL-ED; Fri, 26 Oct 2007 13:46:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPKQ-0001T9-Nb for avt@ietf.org; Fri, 26 Oct 2007 09:34:22 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlPKQ-0001pv-Fz for avt@ietf.org; Fri, 26 Oct 2007 09:34:22 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 656302AC76; Fri, 26 Oct 2007 13:33:52 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IlPJw-0003rR-5w; Fri, 26 Oct 2007 09:33:52 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: magnus.westerlund@ericsson.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 26 Oct 2007 09:33:52 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:46:43 -0400 Cc: stewe@stewe.org, avt@ietf.org Subject: [AVT] New Version Notification for draft-ietf-avt-topologies-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org A new version of I-D, draft-ietf-avt-topologies-07.txt has been successfuly submitted by Magnus Westerlund and posted to the IETF repository. Filename: draft-ietf-avt-topologies Revision: 07 Title: RTP Topologies Creation_date: 2007-10-26 WG ID: avt Number_of_pages: 23 Abstract: This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Oct 28 06:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im5Cy-0002nD-7k; Sun, 28 Oct 2007 06:17:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im5Cw-0002iV-Gt for avt@ietf.org; Sun, 28 Oct 2007 06:17:26 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Im5Cn-0007YY-IE for avt@ietf.org; Sun, 28 Oct 2007 06:17:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] Accepting draft-kristensen-avt-rtp-h264-rcdo-00 as workinggroup item Date: Sun, 28 Oct 2007 12:18:57 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0501BA19@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04E7660E@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Accepting draft-kristensen-avt-rtp-h264-rcdo-00 as workinggroup item Thread-Index: Acf2+o1Fkdgzq9PXSFGVIZYbuU2s+AiUErTA From: "Even, Roni" To: "Even, Roni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: Colin Perkins , tom.taylor@rogers.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0790513264==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0790513264== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8194B.EC7DE690" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8194B.EC7DE690 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Based on the email discussion you can submit this draft as a WG item.=20 Note that there were some concerns about the relationship between this = work and H.264. As you register here a new payload type for this codec = addresses the main concern.=20 I assume you will modify the document based on your editorial note in = the introduction. =20 Roni Even =20 ________________________________ From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Friday, September 14, 2007 9:11 PM To: avt@ietf.org Cc: Colin Perkins; tom.taylor@rogers.com Subject: [AVT] Accepting draft-kristensen-avt-rtp-h264-rcdo-00 as = workinggroup item =20 Hi, draft-kristensen-avt-rtp-h264-rcdo-00 was presented in the last two IETF = meeting (initially as H264 params).=20 =20 The draft describes an RTP Payload format for the Reduced-Complexity = Decoding Operation (RCDO) for H.264. RCDO reduces the decoding cost and = resource consumption of the video processing. The RTP Payload format is = based on the description in RFC 3984. =20 Since this is a payload specification and is within the charter of the = AVT WG, the chairs propose to accept this draft as an AVT work item. = Please send any comments, objections, or statements in favour to the = mailing list by 1st of October 2007. If there are no objections, we will = ask the authors to submit the next version as an AVT working group = draft. =20 Thanks Roni Even ------_=_NextPart_001_01C8194B.EC7DE690 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Tom,

Based on the email discussion you = can submit this draft as a WG item.

Note that there were some concerns = about the relationship between this work and H.264. As you register here a new payload type for this codec addresses the main concern. =

I assume you will modify the = document based on your editorial note in the = introduction.

 

Roni Even

 

From: Even, = Roni [mailto:roni.even@polycom.co.il]
Sent: Friday, September = 14, 2007 9:11 PM
To: avt@ietf.org
Cc: Colin Perkins; tom.taylor@rogers.com
Subject: [AVT] Accepting draft-kristensen-avt-rtp-h264-rcdo-00 as workinggroup = item

 

Hi,

draft-kristensen-avt-rtp-h264-rcdo-00 was presented in the last = two IETF meeting (initially as H264 params).

 

The draft describes an RTP Payload format for the = Reduced-Complexity Decoding Operation (RCDO) for H.264.  RCDO reduces the decoding = cost and resource consumption of the video processing.  The RTP Payload = format is based on the description in RFC 3984.

 

Since this is a = payload specification and is within the charter of the AVT WG, the chairs = propose to accept this draft as an AVT work item. Please send any comments, = objections, or statements in favour to the mailing list by 1st of October = 2007. If there are no objections, we will ask the authors to submit the next = version as an AVT working group draft.

 

Thanks

Roni Even

------_=_NextPart_001_01C8194B.EC7DE690-- --===============0790513264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0790513264==-- From avt-bounces@ietf.org Mon Oct 29 09:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUvt-00030M-9F; Mon, 29 Oct 2007 09:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUvs-000307-Df; Mon, 29 Oct 2007 09:45:32 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImUvr-0007Ra-AT; Mon, 29 Oct 2007 09:45:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4575F328E4; Mon, 29 Oct 2007 13:45:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ImUvN-0003ff-63; Mon, 29 Oct 2007 09:45:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 29 Oct 2007 09:45:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rfc2833biscas (Definition of Events For Channel-Oriented Telephony Signalling) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Definition of Events For Channel-Oriented Telephony Signalling ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-11-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833biscas-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12768&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt