Your c a hanc h e to eco c nomiz u e wi d th us http://paliteryunherdun.com ------=_NextPart_000_0001_01C6CF38.9A509B90-- From avt-bounces@ietf.org Wed Sep 06 16:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3l2-00038A-EA; Wed, 06 Sep 2006 16:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3Wp-0005T2-0z for avt@ietf.org; Wed, 06 Sep 2006 15:57:43 -0400 Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3WS-0002X3-7K for avt@ietf.org; Wed, 06 Sep 2006 15:57:42 -0400 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by warlock.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k86JvJDb009143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Sep 2006 12:57:19 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k86JuxJu009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Sep 2006 12:57:01 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k86JuumC007142; Wed, 6 Sep 2006 12:56:59 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 12:56:56 -0700 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] VoIP Shim for RTP Payload Formats Date: Wed, 6 Sep 2006 12:56:50 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F49E5D@NAEX01.na.qualcomm.com> In-Reply-To: <60797CE0-1F20-4AE2-B7B2-E3B4E61083F9@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+Q From: "Desineni, Harikishan" To: "Colin Perkins" , "Ingemar Johansson S $\(LU/EAB$\)" X-OriginalArrivalTime: 06 Sep 2006 19:56:56.0529 (UTC) FILETIME=[9B57EC10:01C6D1EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 I am under the impression that in-band signaling inside payload header is an accepted concept in this community. Other than AMR Payload format, there is another payload format which is trying to use this concept. Once such work is the use of MBS field in Sec 5.2 draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt "MBS (4 bits): maximum bit rate supported. Indicates a maximum bit rate to the encoder at the site of the receiver of this payload." I think that RTCP (AVPF) has a similar message which can be used to convey maximum bit rate to the encoder at the remote end. I'd like to infer the following statements from the reference to the above work in RTP and RTCP: 1) In-band signaling using RTP payload header is an allowed/accepted concept. 2) RTCP signaling may also exist to carry the same information. In certain scenarios (MOH, voice mail), RTCP signaling is unavoidable. One will end up defining methods to carry the same information using both in-band RTP and RTCP based feedback. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: Friday, August 25, 2006 7:30 AM To: Ingemar Johansson S ((LU/EAB)) Cc: avt@ietf.org Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > Inband signaling of the type proposed already exist for eg. > the AMR payload format (RFC3267), it is however limited to the > request of lower/higher codec rate. The intention of this added > inband signaling is to allow for requests regarding frame aggregation > and redundancy during a session so in that aspect it is a > continuation of the inband signaling concept that already exist. This is one of the less desirable features of the AMR payload format, =20 and was included solely for backwards compatibility. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Sep 07 02:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLDgL-0007dW-LM; Thu, 07 Sep 2006 02:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLDgK-0007d3-7S for avt@ietf.org; Thu, 07 Sep 2006 02:48:12 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLDgI-0005No-Q7 for avt@ietf.org; Thu, 07 Sep 2006 02:48:12 -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] VoIP Shim for RTP Payload Formats Date: Thu, 7 Sep 2006 09:48:03 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03DC9C13@IsrExch01.israel.polycom.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B01F49E5D@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkA= From: "Even, Roni" To: "Desineni, Harikishan" , "Colin Perkins" , "Ingemar Johansson S $\(LU/EAB$\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Hi, I want to put my 2 cents on in band signaling. I would agree that in-band signaling will work I point to point call. Care should be taken for the following cases 1. Unidirectional media. 2. Multicast 3. Multipoint cases That is why I think that capabilities should be in the signaling path In the media path you can have changes which are of a temporary nature like rate change commands for video or audio or indications. I think you suggest a capability describing a more permanent state which should be in SDP. Roni Even =20 > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > Sent: Wednesday, September 06, 2006 10:57 PM > To: Colin Perkins; Ingemar Johansson S ((LU/EAB)) > Cc: avt@ietf.org > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats >=20 >=20 > I am under the impression that in-band signaling inside payload header > is an accepted concept in this community. Other than AMR Payload format, > there is another payload format which is trying to use this concept. > Once such work is the use of MBS field in Sec 5.2 > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt >=20 > "MBS (4 bits): maximum bit rate supported. Indicates a maximum bit > rate to the encoder at the site of the receiver of this payload." >=20 > I think that RTCP (AVPF) has a similar message which can be used to > convey maximum bit rate to the encoder at the remote end. >=20 > I'd like to infer the following statements from the reference to the > above work in RTP and RTCP: >=20 > 1) In-band signaling using RTP payload header is an allowed/accepted > concept. > 2) RTCP signaling may also exist to carry the same information. >=20 > In certain scenarios (MOH, voice mail), RTCP signaling is unavoidable. > One will end up defining methods to carry the same information using > both in-band RTP and RTCP based feedback. >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, August 25, 2006 7:30 AM > To: Ingemar Johansson S ((LU/EAB)) > Cc: avt@ietf.org > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats >=20 > > Inband signaling of the type proposed already exist for eg. > > the AMR payload format (RFC3267), it is however limited to the > > request of lower/higher codec rate. The intention of this added > > inband signaling is to allow for requests regarding frame aggregation > > and redundancy during a session so in that aspect it is a > > continuation of the inband signaling concept that already exist. >=20 > This is one of the less desirable features of the AMR payload format, > and was included solely for backwards compatibility. >=20 >=20 > Colin >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=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 Thu Sep 07 04:01:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEoQ-000715-E3; Thu, 07 Sep 2006 04:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEoO-00070v-Jh for avt@ietf.org; Thu, 07 Sep 2006 04:00:36 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLEoN-0001ux-6L for avt@ietf.org; Thu, 07 Sep 2006 04:00:36 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 10:00: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] VoIP Shim for RTP Payload Formats Date: Thu, 7 Sep 2006 10:01:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABnaDwA= From: "SOLLAUD Aurelien RD-TECH-LAN" To: "Desineni, Harikishan" , "Colin Perkins" , "Ingemar Johansson S $\(LU/EAB$\)" X-OriginalArrivalTime: 07 Sep 2006 08:00:19.0905 (UTC) FILETIME=[A9C58310:01C6D253] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 As author of the draft you quote, I'd like to say that it was done this = way because of the need for an "immediate" deployment of G.729.1 VoIP. I really welcome the AVPF/CCM work for controling the bitrate but that = is not available *now*, so an alternative in-band solution (MBS) has = been chosen. Aurelien=20 -----Message d'origine----- De : Desineni, Harikishan [mailto:hdesinen@qualcomm.com]=20 Envoy=E9 : mercredi 6 septembre 2006 21:57 =C0 : Colin Perkins; Ingemar Johansson S ((LU/EAB)) Cc : avt@ietf.org Objet : RE: [AVT] VoIP Shim for RTP Payload Formats I am under the impression that in-band signaling inside payload header = is an accepted concept in this community. Other than AMR Payload format, = there is another payload format which is trying to use this concept. Once such work is the use of MBS field in Sec 5.2 = draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt "MBS (4 bits): maximum bit rate supported. Indicates a maximum bit = rate to the encoder at the site of the receiver of this payload." I think that RTCP (AVPF) has a similar message which can be used to = convey maximum bit rate to the encoder at the remote end. I'd like to infer the following statements from the reference to the = above work in RTP and RTCP: 1) In-band signaling using RTP payload header is an allowed/accepted = concept. 2) RTCP signaling may also exist to carry the same information. In certain scenarios (MOH, voice mail), RTCP signaling is unavoidable. One will end up defining methods to carry the same information using = both in-band RTP and RTCP based feedback. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, August 25, 2006 7:30 AM To: Ingemar Johansson S ((LU/EAB)) Cc: avt@ietf.org Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > Inband signaling of the type proposed already exist for eg. > the AMR payload format (RFC3267), it is however limited to the request = > of lower/higher codec rate. The intention of this added inband=20 > signaling is to allow for requests regarding frame aggregation and=20 > redundancy during a session so in that aspect it is a continuation of=20 > the inband signaling concept that already exist. This is one of the less desirable features of the AMR payload format, = and was included solely for backwards compatibility. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 08 10:52:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhgv-0002S1-ID; Fri, 08 Sep 2006 10:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhgj-00027T-UU; Fri, 08 Sep 2006 10:50:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhgj-0001Po-Rq; Fri, 08 Sep 2006 10:50:37 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GLhge-00063s-J2; Fri, 08 Sep 2006 10:50:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5CBED2ACA9; Fri, 8 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLhgA-0000Up-3B; Fri, 08 Sep 2006 10:50: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, 08 Sep 2006 10:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.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 Profile for TCP Friendly Rate Control Author(s) : L. Gharai Filename : draft-ietf-avt-tfrc-profile-06.txt Pages : 13 Date : 2006-9-8 This memo specifies a profile called "RTP/AVPFCC" for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with TCP Friendly Rate Control (TFRC). This profile extends the RTP/AVPF profile with RTP data header additions and new AVPF feedback packets, in order to support TFRCs integration with RTP. TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-06.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-tfrc-profile-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-tfrc-profile-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-8060927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tfrc-profile-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tfrc-profile-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8060927.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 Sep 08 11:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhuO-0000W4-JR; Fri, 08 Sep 2006 11:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhuN-0000Vl-2l for avt@ietf.org; Fri, 08 Sep 2006 11:04:43 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhu8-0003gX-B0 for avt@ietf.org; Fri, 08 Sep 2006 11:04:43 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63176 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1GLhu7-00051S-SE for avt@ietf.org; Fri, 08 Sep 2006 16:04:27 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 8 Sep 2006 16:04:24 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-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 The following draft proposes rules for multiplexing RTP and RTCP traffic on a single UDP port, to ease NAT traversal. Any comments appreciated! Colin Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 8 September 2006 15:50:02 BDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Multiplexing RTP Data and Control Packets on a Single Port > Author(s) : C. Perkins, M. Westerlund > Filename : draft-perkins-avt-rtp-and-rtcp-mux-00.txt > Pages : 12 > Date : 2006-9-8 > > This memo discusses issues that arise when multiplexing RTP data > packets and RTP control protocol (RTCP) packets on a single UDP port. > It updates RFC 3550 to describe when such multiplexing is, and is > not, appropriate, and explains how the Session Description Protocol > (SDP) can be used to signal multiplexed sessions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-and-rtcp- > mux-00.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 08 17:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnZn-00054g-8j; Fri, 08 Sep 2006 17:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnZm-00054b-D3 for avt@ietf.org; Fri, 08 Sep 2006 17:07:50 -0400 Received: from porter.east.isi.edu ([65.114.168.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnZl-0002La-0f for avt@ietf.org; Fri, 08 Sep 2006 17:07:50 -0400 Received: from [65.114.168.149] (java.east.isi.edu [65.114.168.149]) by porter.east.isi.edu (Postfix) with ESMTP id CF3B51C67 for ; Fri, 8 Sep 2006 17:07:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.txt Date: Fri, 8 Sep 2006 17:13:37 -0400 To: AVT Lista X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Dear AVT'ers: A new revision of the "RTP Profile for TCP Friendly Rate Control" is now available. There are a number of changes since the previous version of the draft. Most notably that the profile is now an extension of the AVPF profile and defines a new AVPF feedback packet for the TFRC algorithm. An alternative approach to defining a new profile is to use header extensions per draft-ietf-avt-rtp-hdrext-04. There was a general extensive discussion of the merit of each approach (new profile vs. use of header extensions) at the last IETF. However, I am not sure if a conclusion was gained? The draft also discusses the issues of RTCP bandwidth for AVPFCC flows with relatively small (say less than 20 ms) round trip times. The draft recommands abiding by the AVP 5% constraint, however this can preclude certain flows with small RTTs. Please send comments to the list. thank you, Ladan On Sep 8, 2006, at 10:50 AM, Internet-Drafts@ietf.org wrote: > 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 Profile for TCP Friendly Rate Control > Author(s) : L. Gharai > Filename : draft-ietf-avt-tfrc-profile-06.txt > Pages : 13 > Date : 2006-9-8 > > This memo specifies a profile called "RTP/AVPFCC" for the use of the > real-time transport protocol (RTP) and its associated control > protocol, RTCP, with TCP Friendly Rate Control (TFRC). This profile > extends the RTP/AVPF profile with RTP data header additions and new > AVPF feedback packets, in order to support TFRCs integration with > RTP. TFRC is an equation based congestion control scheme for unicast > flows operating in a best effort Internet environment. This profile > provides RTP flows with the mechanism to use congestion control in > best effort IP networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-06.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-tfrc-profile-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-avt-tfrc-profile-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-9-8060927.I-D@ietf.org> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Sep 09 00:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLusQ-00062E-1Y; Sat, 09 Sep 2006 00:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLusP-000628-0I for avt@ietf.org; Sat, 09 Sep 2006 00:55:33 -0400 Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLusN-00044L-Kj for avt@ietf.org; Sat, 09 Sep 2006 00:55:32 -0400 Received: from Misan (213.64.228.153) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) id 44FECF14000C9D8B; Sat, 9 Sep 2006 06:55:30 +0200 From: =?US-ASCII?Q?Gunnar_Hellstrom?= To: "Colin Perkins" , "AVT WG" Subject: RE: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt - multiplexing to what extent Date: Sat, 9 Sep 2006 06:55:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Colin and Magnus, Thanks for a good initiative and a good draft. It seems to cover part of the need for multiplexing in a good way. But, I suggest that you in the abstract and early in the text describe to what extent you solve the multiplexing problem. I read it with the initial hope that you proposed a method to multiplex all RTP and RTCP streams in e.g. a SIP session onto one UDP port. I had to read it all through down below the sdp example, before I could conclude that the method does not cover the problems that would occur if you want to multiplex all media in a session onto the same port. In multimedia applications, it is a similar burden to handle all media rtp streams through NAT. By this draft you cover half of the problem - the RTP-RTCP multiplexing belonging to one RTP session, but not how to multiplex all RTP sessions with its RTCP. Please indicate that early in the draft with wording that not forbids solving the other half of the problem. I leave to you to do the wording. Thanks, Gunnar ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, September 08, 2006 5:04 PM To: AVT WG Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt The following draft proposes rules for multiplexing RTP and RTCP traffic on a single UDP port, to ease NAT traversal. Any comments appreciated! Colin Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 8 September 2006 15:50:02 BDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Multiplexing RTP Data and Control Packets on a Single Port > Author(s) : C. Perkins, M. Westerlund > Filename : draft-perkins-avt-rtp-and-rtcp-mux-00.txt > Pages : 12 > Date : 2006-9-8 > > This memo discusses issues that arise when multiplexing RTP data > packets and RTP control protocol (RTCP) packets on a single UDP port. > It updates RFC 3550 to describe when such multiplexing is, and is > not, appropriate, and explains how the Session Description Protocol > (SDP) can be used to signal multiplexed sessions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-and-rtcp- > mux-00.txt _______________________________________________ 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 Sat Sep 09 14:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM7aq-0006TS-Cp; Sat, 09 Sep 2006 14:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM7ap-0006TN-1H for avt@ietf.org; Sat, 09 Sep 2006 14:30:15 -0400 Received: from levi.nethawkgroup.com ([194.100.156.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GM7an-00029t-FA for avt@ietf.org; Sat, 09 Sep 2006 14:30:15 -0400 Received: from (194.100.156.10) by levi.nethawkgroup.com via smtp id 4034_2ccf58ac_4032_11db_8854_003048245d96; Sat, 09 Sep 2006 21:36:58 +0300 Received: from nhus131 (192.1.2.130) by jopo.nethawk.fi (7.0.008) id 44351CCE000BD4E0 for avt@ietf.org; Sat, 9 Sep 2006 21:17:11 +0300 From: "Siddhartha Gandhi" To: Date: Sat, 9 Sep 2006 13:30:09 -0500 Message-ID: <000001c6d43d$fbd87b80$820201c0@nethawk.fi> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbUPfrZNfjNrircRwuaAEKjm3bs7A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [AVT] draft-ietf-avt-rtcpssm-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: , Content-Type: multipart/mixed; boundary="===============0360031525==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0360031525== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D414.13027380" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D414.13027380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Looks like the following draft will expire this month. I am wondering if it is still under review or expired yet. I am asking this question because I have implemented distribution source based multicasting and wanted to know whether this kind of architecture, as mentioned in the draft will ever be implemented commercially. Draft: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-11.txt - Siddhartha ------=_NextPart_000_0001_01C6D414.13027380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Looks like the following draft will expire this = month. I am wondering if it is still under review or expired yet. =

I am asking this question because I have implemented = distribution source based multicasting and wanted to know whether this kind of =

architecture, as mentioned in the draft will ever be = implemented commercially.

Draft:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-11.txt

- Siddhartha

------=_NextPart_000_0001_01C6D414.13027380-- --===============0360031525== 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 --===============0360031525==-- From avt-bounces@ietf.org Mon Sep 11 03:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMg6P-0000Cd-0D; Mon, 11 Sep 2006 03:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMg6N-000076-4E for avt@ietf.org; Mon, 11 Sep 2006 03:21:07 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMg6C-0005vO-Df for avt@ietf.org; Mon, 11 Sep 2006 03:21:07 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9B906FFF; Mon, 11 Sep 2006 09:20:53 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 09:20:53 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 09:20:52 +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] VoIP Shim for RTP Payload Formats Date: Mon, 11 Sep 2006 09:20:51 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260DFF2@esealmw109.eemea.ericsson.se> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03DC9C13@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats thread-index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkAAyiKd8A== From: "Ingemar Johansson S $LU/EAB$" To: "Even, Roni" , "Desineni, Harikishan" , "Colin Perkins" X-OriginalArrivalTime: 11 Sep 2006 07:20:52.0563 (UTC) FILETIME=[D060CA30:01C6D572] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Hi I agree that capabilities should be exhanged (eg. SDP) in order to decide if Shim should be allowed.=20 The main application is point to point communication. Of the cases below I belive that in case 1 and 2 Shim should be avoided. In case 3 it may be possible to use Shim if a conference bridge can do policing on the Shim information. Ingemar > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il]=20 > Sent: den 7 september 2006 08:48 > To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S (LU/EAB) > Cc: avt@ietf.org > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats >=20 > Hi, > I want to put my 2 cents on in band signaling. >=20 > I would agree that in-band signaling will work I point to point call. > Care should be taken for the following cases >=20 > 1. Unidirectional media. > 2. Multicast > 3. Multipoint cases >=20 > That is why I think that capabilities should be in the=20 > signaling path In the media path you can have changes which=20 > are of a temporary nature like rate change commands for video=20 > or audio or indications. >=20 > I think you suggest a capability describing a more permanent=20 > state which should be in SDP. >=20 > Roni Even =20 >=20 > > -----Original Message----- > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > Sent: Wednesday, September 06, 2006 10:57 PM > > To: Colin Perkins; Ingemar Johansson S ((LU/EAB)) > > Cc: avt@ietf.org > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > >=20 > >=20 > > I am under the impression that in-band signaling inside=20 > payload header=20 > > is an accepted concept in this community. Other than AMR Payload > format, > > there is another payload format which is trying to use this concept. > > Once such work is the use of MBS field in Sec 5.2=20 > > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt > >=20 > > "MBS (4 bits): maximum bit rate supported. Indicates a=20 > maximum bit =20 > > rate to the encoder at the site of the receiver of this payload." > >=20 > > I think that RTCP (AVPF) has a similar message which can be used to=20 > > convey maximum bit rate to the encoder at the remote end. > >=20 > > I'd like to infer the following statements from the=20 > reference to the=20 > > above work in RTP and RTCP: > >=20 > > 1) In-band signaling using RTP payload header is an=20 > allowed/accepted=20 > > concept. > > 2) RTCP signaling may also exist to carry the same information. > >=20 > > In certain scenarios (MOH, voice mail), RTCP signaling is=20 > unavoidable. > > One will end up defining methods to carry the same=20 > information using=20 > > both in-band RTP and RTCP based feedback. > >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Friday, August 25, 2006 7:30 AM > > To: Ingemar Johansson S ((LU/EAB)) > > Cc: avt@ietf.org > > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > >=20 > > > Inband signaling of the type proposed already exist for eg. > > > the AMR payload format (RFC3267), it is however limited to the=20 > > > request of lower/higher codec rate. The intention of this added=20 > > > inband signaling is to allow for requests regarding frame > aggregation > > > and redundancy during a session so in that aspect it is a=20 > > > continuation of the inband signaling concept that already exist. > >=20 > > This is one of the less desirable features of the AMR=20 > payload format,=20 > > and was included solely for backwards compatibility. > >=20 > >=20 > > Colin > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 15:16:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrFa-00081o-6q; Mon, 11 Sep 2006 15:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrFY-000814-V5 for avt@ietf.org; Mon, 11 Sep 2006 15:15:20 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMrFX-0007FN-Gn for avt@ietf.org; Mon, 11 Sep 2006 15:15:20 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 15:15:17 -0400 To: Gunnar Hellstrom Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt - multiplexing to what extent References: From: Randell Jesup Date: Mon, 11 Sep 2006 15:15:15 -0400 In-Reply-To: (Gunnar Hellstrom's message of "Sat, 9 Sep 2006 06:55:27 +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: 11 Sep 2006 19:15:17.0753 (UTC) FILETIME=[9E05B690:01C6D5D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Colin Perkins , AVT WG 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 Gunnar Hellstrom writes: >Thanks for a good initiative and a good draft. >It seems to cover part of the need for multiplexing in a good way. > >But, I suggest that you in the abstract and early in the text describe to >what extent you solve the multiplexing problem. > >I read it with the initial hope that you proposed a method to multiplex all >RTP and RTCP streams in e.g. a SIP session onto one UDP port. > >I had to read it all through down below the sdp example, before I could >conclude that the method does not cover the problems that would occur if you >want to multiplex all media in a session onto the same port. Another issue that at least should be mentioned is that it can fail if any proxy doesn't support a=rtcp: and that proxy changes the RTP port. Changing the RTP port is frequently (normally) done by ALGs and SBCs, and not all of them support a=rtcp: - and if they do support it, the traffic caused by this draft might mess them up. I will concede that lack of a=rtcp support by an SBC, ALG, rtp-relay, etc would also break regular RTCP - but these are important issues for this draft and for users of it. >In multimedia applications, it is a similar burden to handle all media rtp >streams through NAT. > >By this draft you cover half of the problem - the RTP-RTCP multiplexing >belonging to one RTP session, but not how to multiplex all RTP sessions with >its RTCP. Please indicate that early in the draft with wording that not >forbids solving the other half of the problem. This draft relies on a "tricky" use of a=rtcp as implicit signalling, and to in some cases trick implementations that predate this draft into using the same port for RTP and RTCP (assuming that they already support a=rtcp, which many do not). Explicit signalling would restrict it to implementations that know about this draft, but would avoid problems with a=rtcp implementation (see above about SBCs, etc). The other option to consider is a more explicit multiplexing as Gunnar is mentioning (sub-ports if you will) to minimize the number of holes that need to be punched and tested, especially when ICE is involved. A protocol that uses (say) 3 streams in each direction needs 6 incoming ports tested and punched open. With a full multiplex layer for RTP, you'd only need 1 port. In Message-ID: sent on April 4, 2006 to avt@ietf, Colin, etc, I suggested signalling a multiplex layer at the connection level. I quote: | the canonical way to achieve this to be define a multiplexing | protocol for datagrams, and specify this as part of a c= line in the | SDP. This would change the "port" value from the media line into a "stream | ID" on the multiplex. Something like: | | c=IN IP4/PLEX 23.45.67.89 1234 | m=audio 2 RTP/AVP 0 | m=video 4 RTP/AVP 99 | a=rtpmap:99 H999/90000 | | That would put audio on multiplex "ports" 2 & 3, and video on 4 & 5. | All data would be sent to 23.45.67.89 port 1234. | | This is more overhead than if it were designed into RTP - but it can be | used for any protocol, not just RTP. | | Packet data could be something like: | [short plex_port] | [datagram] | | Yes, this causes an MTU size drop, which is an issue for some. This would | need to be handled at the sending end. Perhaps (maybe) you could consider | optimizing this for the "common" case of "same as last packet", but you | still need at least a bit, and more likely a byte. Probably better to | stick to two. | | There would be no attempt to deal with duplication, ordering, timing or any | other issue at this layer. KISS. That's the job of the application these | datagrams get fed to. | | If you do need to get fancier, you can add fragmentation, etc, but it gets | ugly fast, and starts approaching the complexity/overhead of UDP. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnA-0005f2-B9; Mon, 11 Sep 2006 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0005eX-D1; Mon, 11 Sep 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0001lW-5m; Mon, 11 Sep 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 228A326E1D; Mon, 11 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMrn8-0005PE-1D; Mon, 11 Sep 2006 15:50: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: Mon, 11 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-05.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 : A general mechanism for RTP Header Extensions Author(s) : D. Singer Filename : draft-ietf-avt-rtp-hdrext-05.txt Pages : 17 Date : 2006-9-11 This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and unregistered. The actual extensions in use in a session are signaled in the setup information for that session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-05.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-hdrext-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; From avt-bounces@ietf.org Mon Sep 11 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnA-0005f2-B9; Mon, 11 Sep 2006 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0005eX-D1; Mon, 11 Sep 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0001lW-5m; Mon, 11 Sep 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 228A326E1D; Mon, 11 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMrn8-0005PE-1D; Mon, 11 Sep 2006 15:50: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: Mon, 11 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-05.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 : A general mechanism for RTP Header Extensions Author(s) : D. Singer Filename : draft-ietf-avt-rtp-hdrext-05.txt Pages : 17 Date : 2006-9-11 This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and unregistered. The actual extensions in use in a session are signaled in the setup information for that session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-05.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-hdrext-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-11115017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-hdrext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-11115017.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 Mon Sep 11 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnC-0005fS-Gc; Mon, 11 Sep 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrn9-0005eh-EQ; Mon, 11 Sep 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0001lX-6M; Mon, 11 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 26C8B32875; Mon, 11 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMrn8-0005PH-1o; Mon, 11 Sep 2006 15:50: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: Mon, 11 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-toffset-01.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 : Transmission Time offsets in RTP streams Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-toffset-01.txt Pages : 15 Date : 2006-9-11 This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-01.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-toffset-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-toffset-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENaccess-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-11115017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-hdrext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-11115017.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 Mon Sep 11 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnC-0005fS-Gc; Mon, 11 Sep 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrn9-0005eh-EQ; Mon, 11 Sep 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMrn8-0001lX-6M; Mon, 11 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 26C8B32875; Mon, 11 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMrn8-0005PH-1o; Mon, 11 Sep 2006 15:50: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: Mon, 11 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-toffset-01.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 : Transmission Time offsets in RTP streams Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-toffset-01.txt Pages : 15 Date : 2006-9-11 This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-01.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-toffset-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-toffset-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-11115336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-toffset-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-toffset-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-11115336.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-- CODING 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: <2006-9-11115336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-toffset-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-toffset-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-11115336.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 Mon Sep 11 16:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsZF-00063Q-8i; Mon, 11 Sep 2006 16:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsZE-00063L-Cw for avt@ietf.org; Mon, 11 Sep 2006 16:39:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMsZC-0008PG-Ur for avt@ietf.org; Mon, 11 Sep 2006 16:39:44 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A96E06D4; Mon, 11 Sep 2006 16:39:10 -0400 From: "Hadriel Kaplan" To: "'Randell Jesup'" , "'Gunnar Hellstrom'" Subject: RE: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent Date: Mon, 11 Sep 2006 16:39:09 -0400 Message-ID: <03d301c6d5e2$562b47c0$b7c8000a@acmepacket.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.2962 Thread-Index: AcbV14FDCxqEsRPIRSCsjtfuk8YS5gABiAug In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'Colin Perkins' , 'AVT WG' 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 Hey Randell, Comments inline... > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Monday, September 11, 2006 3:15 PM > To: Gunnar Hellstrom > Cc: Colin Perkins; AVT WG > Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux- > 00.txt- multiplexing to what extent > > Another issue that at least should be mentioned is that it can fail if any > proxy doesn't support a=rtcp: and that proxy changes the RTP port. > Changing the RTP port is frequently (normally) done by ALGs and SBCs, and > not all of them support a=rtcp: - and if they do support it, the traffic > caused by this draft might mess them up. I will concede that lack of > a=rtcp support by an SBC, ALG, rtp-relay, etc would also break regular > RTCP - but these are important issues for this draft and for users of it. I think this draft handles that: if the answer does not have an a=rtcp matching the m= udp port, then the offer must fail and the offerer must retry it without muxing. So an offer/answer using this draft through an ALG/FW which did not support rfc3605 would probably fail, with a very high probability, and re-signal. It is then just as good/bad as 3605, or the offerer could just not use a=rtcp at all at that point; i.e., it's no worse than before. > This draft relies on a "tricky" use of a=rtcp as implicit signalling, and > to in some cases trick implementations that predate this draft into using > the same port for RTP and RTCP (assuming that they already support a=rtcp, > which many do not). > Explicit signalling would restrict it to implementations that know about > this draft, but would avoid problems with a=rtcp implementation (see above > about SBCs, etc). I was going to comment originally that this draft could use explicit signaling instead of overloading a=rtcp; though I think it's a graceful/clever reuse of a=rtcp. But it occurs to me it's just as likely you hit a FW/SBC that doesn't allow non-conforming PT's in the stream, and you have as bad a problem. In that case it would have been better to fail the offer, as this draft would do. IOW, damned if you do, damned if you don't. Perhaps what this draft should say is if the answer still used a=rtcp but with mismatching udp port to the answer's m= line, that the offerer may consider retrying without muxing AND without using RFC 3605 at all, because the odds are something in the middle's mucking with SDP and doesn't understand a=rtcp? -hadriel _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 17:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMss7-0005F8-BY; Mon, 11 Sep 2006 16:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMss5-0005El-Ov for avt@ietf.org; Mon, 11 Sep 2006 16:59:13 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMss4-0002q0-GV for avt@ietf.org; Mon, 11 Sep 2006 16:59:13 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id AE1E03E8; Mon, 11 Sep 2006 16:59:10 -0400 From: "Hadriel Kaplan" To: Date: Mon, 11 Sep 2006 16:59:10 -0400 Message-ID: <03d601c6d5e5$21087fb0$b7c8000a@acmepacket.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.2962 Thread-Index: AcbV5SDgaPXLmVZ9TxWyqwHZJz2KAQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: csp@csperkins.org Subject: [AVT] Comments on draft-perkins-avt-rtp-and-rtcp-mux-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 Specific comments: 1) Since RTCP packets have to be sent as compounds with SR/RR first (right?), why do the other RTCP PT's matter for collisions? Because they could be sent over TCP, and thus be a stream? Or just for protocol purity of them being "packets"? Perhaps that should be stated in the draft, in case someone wonders. 2) What does this mean for bandwidth values encoded in SDP? Should it include the RTCP overhead in b=AS, or not? Or mandate using RFC 3556 b=RS/RR encoding? 3) The example SDP in section 5.1 has "IP6" twice in the connection line. -hadriel _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 17:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtAV-000547-LX; Mon, 11 Sep 2006 17:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtAU-00053w-0P for avt@ietf.org; Mon, 11 Sep 2006 17:18:14 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMt6r-00066E-J0 for avt@ietf.org; Mon, 11 Sep 2006 17:14:30 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 17:14:29 -0400 To: "Hadriel Kaplan" Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent References: <03d301c6d5e2$562b47c0$b7c8000a@acmepacket.com> From: Randell Jesup Date: Mon, 11 Sep 2006 17:14:27 -0400 In-Reply-To: <03d301c6d5e2$562b47c0$b7c8000a@acmepacket.com> (Hadriel Kaplan's message of "Mon, 11 Sep 2006 16:39:09 -0400") 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: 11 Sep 2006 21:14:29.0734 (UTC) FILETIME=[44EF6860:01C6D5E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'Gunnar Hellstrom' , 'Colin Perkins' , 'AVT WG' 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 "Hadriel Kaplan" writes: >> Another issue that at least should be mentioned is that it can fail if any >> proxy doesn't support a=rtcp: and that proxy changes the RTP port. >> Changing the RTP port is frequently (normally) done by ALGs and SBCs, and >> not all of them support a=rtcp: - and if they do support it, the traffic >> caused by this draft might mess them up. I will concede that lack of >> a=rtcp support by an SBC, ALG, rtp-relay, etc would also break regular >> RTCP - but these are important issues for this draft and for users of it. > >I think this draft handles that: if the answer does not have an a=rtcp >matching the m= udp port, then the offer must fail and the offerer must >retry it without muxing. That could still confuse an existing app. And the offer doesn't "fail", the offer has been accepted; you're talking about re-INVITEing/UPDATEing the offer after it's been accepted but with values that won't work correctly. This could cause problems until the call is re-established without that. And it may be more delayed if this means another pass of ICE (this time for more ports). >So an offer/answer using this draft through an ALG/FW which did not >support rfc3605 would probably fail, with a very high probability, and >re-signal. It is then just as good/bad as 3605, or the offerer could just >not use a=rtcp at all at that point; i.e., it's no worse than before. The reason I say it wouldn't fail is: Offer: m=audio 1234 .... a=rtcp:1234 Munged offer: m=audio 5678 .... a=rtcp:1234 Answer (200 OK): m=audio 9876 ... The answerer assumes that rtp goes to 5678 and rtcp goes to 1234. The offerer will need to re-INVITE (and perhaps re-STUN/ICE/TURN/etc). And RTCP will be lost for a while at call startup (at minimum). >> This draft relies on a "tricky" use of a=rtcp as implicit signalling, and >> to in some cases trick implementations that predate this draft into using >> the same port for RTP and RTCP (assuming that they already support a=rtcp, >> which many do not). >> Explicit signalling would restrict it to implementations that know about >> this draft, but would avoid problems with a=rtcp implementation (see above >> about SBCs, etc). > >I was going to comment originally that this draft could use explicit >signaling instead of overloading a=rtcp; though I think it's a >graceful/clever reuse of a=rtcp. But it occurs to me it's just as likely >you hit a FW/SBC that doesn't allow non-conforming PT's in the stream, and >you have as bad a problem. In that case it would have been better to fail >the offer, as this draft would do. IOW, damned if you do, damned if you >don't. non-conforming PT's? Perhaps you mean attributes. I'm more willing to deal with that sort of failure, and I think it will generally have less effect on the call setup (it will fail before getting to the dest, and in theory the caller could then retry). But a gateway that rejects invites with attributes it doesn't understand is quickly going to be a problem for EVERY protocol and draft, unless we hide every addition and extension in the few attributes it passes through. >Perhaps what this draft should say is if the answer still used a=rtcp but >with mismatching udp port to the answer's m= line, that the offerer may >consider retrying without muxing AND without using RFC 3605 at all, because >the odds are something in the middle's mucking with SDP and doesn't >understand a=rtcp? You could (though include the no "a=rtcp" case there too). But I think overall there are too many bandaids here. I'd recommend at least moving away from the attempt to overload a=rtcp; there's too much chance of breaking some ALG/SBC/UA that understands 3605 but not this (plus the issues above). It's cute, but I think the potential pain isn't worth it. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 17:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtBp-0005hC-0H; Mon, 11 Sep 2006 17:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtBn-0005h7-Qc for avt@ietf.org; Mon, 11 Sep 2006 17:19:35 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMtBm-0007Dy-KE for avt@ietf.org; Mon, 11 Sep 2006 17:19:35 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 17:19:34 -0400 To: "Hadriel Kaplan" Subject: Re: [AVT] Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt References: <03d601c6d5e5$21087fb0$b7c8000a@acmepacket.com> From: Randell Jesup Date: Mon, 11 Sep 2006 17:19:32 -0400 In-Reply-To: <03d601c6d5e5$21087fb0$b7c8000a@acmepacket.com> (Hadriel Kaplan's message of "Mon, 11 Sep 2006 16:59:10 -0400") 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: 11 Sep 2006 21:19:34.0911 (UTC) FILETIME=[FAD5B8F0:01C6D5E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: avt@ietf.org, csp@csperkins.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 "Hadriel Kaplan" writes: >Specific comments: >1) Since RTCP packets have to be sent as compounds with SR/RR first >(right?), why do the other RTCP PT's matter for collisions? Because they >could be sent over TCP, and thus be a stream? Or just for protocol purity >of them being "packets"? Perhaps that should be stated in the draft, in >case someone wonders. Good point - RTCP does ALWAYS have to start with SR or RR, so those are the only ones you need to worry about. Even on TCP, you know the framing of packets, so others won't be an issue. >2) What does this mean for bandwidth values encoded in SDP? Should it >include the RTCP overhead in b=AS, or not? Or mandate using RFC 3556 >b=RS/RR encoding? Good question. If you include the BW of the RTCP (b=AS:), then some QoS solutions will allocate that plus 5% for RTCP. That may not be a big problem (some wasted reservation, if the QoS reserver doesn't understand this draft). If you use AS, you should include it because a QoS service might reserve on a per-port basis. RS/RR might make sense (I'd have to brush up on them). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Sep 11 18:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMuMs-0003qH-0R; Mon, 11 Sep 2006 18:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMuMq-0003oa-RZ for avt@ietf.org; Mon, 11 Sep 2006 18:35:04 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMuMm-0007Wh-HD for avt@ietf.org; Mon, 11 Sep 2006 18:35:04 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A48C01A0; Mon, 11 Sep 2006 18:34:52 -0400 From: "Hadriel Kaplan" To: "'Randell Jesup'" Subject: RE: [AVT] Fwd: I-DACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to whatextent Date: Mon, 11 Sep 2006 18:34:52 -0400 Message-ID: <004201c6d5f2$7f62c860$b7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbV62EdCDiUV1zoTyOkUS7DkY8VMwAAtF0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'Gunnar Hellstrom' , 'Colin Perkins' , 'AVT WG' 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 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > > >I think this draft handles that: if the answer does not have an a=rtcp > >matching the m= udp port, then the offer must fail and the offerer must > >retry it without muxing. > > That could still confuse an existing app. And the offer doesn't "fail", > the offer has been accepted; you're talking about re-INVITEing/UPDATEing > the offer after it's been accepted but with values that won't work > correctly. This could cause problems until the call is re-established > without that. And it may be more delayed if this means another pass of > ICE > (this time for more ports). Yup, I assumed this draft meant the offerer would cancel/terminate the session or re-invite/update the offer. It's ugly though, obviously. > The reason I say it wouldn't fail is: > Offer: > m=audio 1234 .... > a=rtcp:1234 > Munged offer: > m=audio 5678 .... > a=rtcp:1234 > Answer (200 OK): > m=audio 9876 ... > The answerer assumes that rtp goes to 5678 and rtcp goes to 1234. > The offerer will need to re-INVITE (and perhaps re-STUN/ICE/TURN/etc). > And RTCP will be lost for a while at call startup (at minimum). Yup, as it would for RFC 3605 alone. Thus my point was it's no worse than that rfc, fwiw. > non-conforming PT's? Perhaps you mean attributes. I'm more willing to > deal with that sort of failure, and I think it will generally have less > effect on the call setup (it will fail before getting to the dest, and > in theory the caller could then retry). Nope, I meant payload-types in RTP-UDP streams that weren't signaled in the m= line. In this case a RR/SR showing up. There are such FW/SBCs. So for example this draft instead uses a=rtcp-mux or some such, to bypass the FW/SBC/ALG's ineptitude. Both sides then mux RTP+RTCP, and the FW blocks it in the stream. The irony is RTP+RTCP un-muxed would have worked fine, because the FW was the one who NATs and thus would have opened UDP port+1 for RTCP. But no matter - we've got to pick a poison no matter what, and I agree with you it's less common to block on PT types. > I'd recommend at least moving > away from the attempt to overload a=rtcp; there's too much chance of > breaking some ALG/SBC/UA that understands 3605 but not this (plus the > issues above). It's cute, but I think the potential pain isn't worth it. Huh. I was thinking the other way round - that a 3605-understanding ALG is one that *would* work, because it would modify the a=rtcp line as well. But on reflection I think your point is it may modify it to be non-equal to the m= line? That's a good point, it might. (who knows with these foolish intermediaries - that's what they get for mucking with SDP :) -hadriel _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Sep 14 11:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtRJ-0008Iz-5e; Thu, 14 Sep 2006 11:47:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtRH-0008Iu-FE for avt@ietf.org; Thu, 14 Sep 2006 11:47:43 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtRG-0007Ve-0F for avt@ietf.org; Thu, 14 Sep 2006 11:47:43 -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] VoIP Shim for RTP Payload Formats Date: Thu, 14 Sep 2006 18:47:36 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03DCA8B5@IsrExch01.israel.polycom.com> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260DFF2@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkAAyiKd8ACfhPeQ From: "Even, Roni" To: "Ingemar Johansson S $LU/EAB$" , "Desineni, Harikishan" , "Colin Perkins" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Hi, I think that I was not clear about capabilities. What I meant was not that SDP should be used to find if Shim should be used but I said that Shim should not be used to replace SDP by signaling end to end capabilities that are to be conveyed in SDP. The extreme case is to signal all optional parameters defined in SDP via in-band signaling, the example for G.729 looked to me like SDP and not in-band Roni > -----Original Message----- > From: Ingemar Johansson S (LU/EAB) > [mailto:ingemar.s.johansson@ericsson.com] > Sent: Monday, September 11, 2006 10:21 AM > To: Even, Roni; Desineni, Harikishan; Colin Perkins > Cc: avt@ietf.org > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats >=20 > Hi >=20 > I agree that capabilities should be exhanged (eg. SDP) in order to > decide if Shim should be allowed. > The main application is point to point communication. > Of the cases below I belive that in case 1 and 2 Shim should be avoided. > In case 3 it may be possible to use Shim if a conference bridge can do > policing on the Shim information. >=20 > Ingemar >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: den 7 september 2006 08:48 > > To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S (LU/EAB) > > Cc: avt@ietf.org > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > Hi, > > I want to put my 2 cents on in band signaling. > > > > I would agree that in-band signaling will work I point to point call. > > Care should be taken for the following cases > > > > 1. Unidirectional media. > > 2. Multicast > > 3. Multipoint cases > > > > That is why I think that capabilities should be in the > > signaling path In the media path you can have changes which > > are of a temporary nature like rate change commands for video > > or audio or indications. > > > > I think you suggest a capability describing a more permanent > > state which should be in SDP. > > > > Roni Even > > > > > -----Original Message----- > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > Sent: Wednesday, September 06, 2006 10:57 PM > > > To: Colin Perkins; Ingemar Johansson S ((LU/EAB)) > > > Cc: avt@ietf.org > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > > I am under the impression that in-band signaling inside > > payload header > > > is an accepted concept in this community. Other than AMR Payload > > format, > > > there is another payload format which is trying to use this concept. > > > Once such work is the use of MBS field in Sec 5.2 > > > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt > > > > > > "MBS (4 bits): maximum bit rate supported. Indicates a > > maximum bit > > > rate to the encoder at the site of the receiver of this payload." > > > > > > I think that RTCP (AVPF) has a similar message which can be used to > > > convey maximum bit rate to the encoder at the remote end. > > > > > > I'd like to infer the following statements from the > > reference to the > > > above work in RTP and RTCP: > > > > > > 1) In-band signaling using RTP payload header is an > > allowed/accepted > > > concept. > > > 2) RTCP signaling may also exist to carry the same information. > > > > > > In certain scenarios (MOH, voice mail), RTCP signaling is > > unavoidable. > > > One will end up defining methods to carry the same > > information using > > > both in-band RTP and RTCP based feedback. > > > > > > -----Original Message----- > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > Sent: Friday, August 25, 2006 7:30 AM > > > To: Ingemar Johansson S ((LU/EAB)) > > > Cc: avt@ietf.org > > > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > Inband signaling of the type proposed already exist for eg. > > > > the AMR payload format (RFC3267), it is however limited to the > > > > request of lower/higher codec rate. The intention of this added > > > > inband signaling is to allow for requests regarding frame > > aggregation > > > > and redundancy during a session so in that aspect it is a > > > > continuation of the inband signaling concept that already exist. > > > > > > This is one of the less desirable features of the AMR > > payload format, > > > and was included solely for backwards compatibility. > > > > > > > > > Colin > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Sep 14 17:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz5P-0002B5-4m; Thu, 14 Sep 2006 17:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz5N-0002B0-T0 for avt@ietf.org; Thu, 14 Sep 2006 17:49:29 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNz5L-00068w-GX for avt@ietf.org; Thu, 14 Sep 2006 17:49:29 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8ELnMq7024517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Sep 2006 14:49:24 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8ELmB9K019104; Thu, 14 Sep 2006 14:49:21 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 14:45:43 -0700 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] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent Date: Thu, 14 Sep 2006 14:45:34 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A910@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent Thread-Index: AcbV1480oPPOcOtMTZa1wZDZDXXptQCbPN6w From: "Desineni, Harikishan" To: "Randell Jesup" , "Gunnar Hellstrom" X-OriginalArrivalTime: 14 Sep 2006 21:45:43.0666 (UTC) FILETIME=[211FFD20:01C6D847] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Colin Perkins , AVT WG 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 What if you allow the following? Both RTP streams will arrive on 20000 and the receiver will demux based on payload type. Wouldn't this work as long as the payload type for both media streams is not the same? m=3Daudio 20000 RTP/AVP 0 m=3Dvideo 20000 RTP/AVP 99 a=3Drtpmap:99 H263/90000 This draft is proposing that a payload type be used for de-multiplexing RTP and RTCP. This might just work to de-mux RTP streams as well. The above SDP signaling approach looks much simpler than PLEX proposal (if you choose to use PT as demux point). - - - - - - - - - - - - - - - - - - Harikishan Desineni Qualcomm Inc., mailto:hd@qualcomm.com > mentioning (sub-ports if you will) to minimize the number of holes that > need to be punched and tested, especially when ICE is involved. A > protocol > that uses (say) 3 streams in each direction needs 6 incoming ports tested > and punched open. With a full multiplex layer for RTP, you'd only need 1 > port. >=20 > In Message-ID: sent on April 4, 2006 > to avt@ietf, Colin, etc, I suggested signalling a multiplex layer at the > connection level. I quote: >=20 >=20 > | the canonical way to achieve this to be define a multiplexing > | protocol for datagrams, and specify this as part of a c=3D line in = the > | SDP. This would change the "port" value from the media line into a > "stream > | ID" on the multiplex. Something like: > | > | c=3DIN IP4/PLEX 23.45.67.89 1234 > | m=3Daudio 2 RTP/AVP 0 > | m=3Dvideo 4 RTP/AVP 99 > | a=3Drtpmap:99 H999/90000 > | > | That would put audio on multiplex "ports" 2 & 3, and video on 4 & 5. > | All data would be sent to 23.45.67.89 port 1234. > | > | This is more overhead than if it were designed into RTP - but it can be > | used for any protocol, not just RTP. > | > | Packet data could be something like: > | [short plex_port] > | [datagram] > | > | Yes, this causes an MTU size drop, which is an issue for some. This > would > | need to be handled at the sending end. Perhaps (maybe) you could > consider > | optimizing this for the "common" case of "same as last packet", but you > | still need at least a bit, and more likely a byte. Probably better to > | stick to two. > | > | There would be no attempt to deal with duplication, ordering, timing or > any > | other issue at this layer. KISS. That's the job of the application > these > | datagrams get fed to. > | > | If you do need to get fancier, you can add fragmentation, etc, but it > gets > | ugly fast, and starts approaching the complexity/overhead of UDP. >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com >=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 Thu Sep 14 18:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzaa-0000N8-49; Thu, 14 Sep 2006 18:21:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzaY-0000Kh-N2 for avt@ietf.org; Thu, 14 Sep 2006 18:21:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNzaW-000655-9E for avt@ietf.org; Thu, 14 Sep 2006 18:21:42 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8EMLYr1029307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Sep 2006 15:21:36 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8EMKKxv027806; Thu, 14 Sep 2006 15:21:33 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 15:20:43 -0700 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] Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt Date: Thu, 14 Sep 2006 15:20:42 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A92D@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt Thread-Index: AcbV6HThvxAtThHdRJCgJSBNQNcfrwCXwWTQ From: "Desineni, Harikishan" To: "Randell Jesup" , "Hadriel Kaplan" X-OriginalArrivalTime: 14 Sep 2006 22:20:43.0225 (UTC) FILETIME=[048F4490:01C6D84C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: avt@ietf.org, csp@csperkins.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 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Monday, September 11, 2006 2:20 PM > To: Hadriel Kaplan > Cc: avt@ietf.org; csp@csperkins.org > Subject: Re: [AVT] Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt >=20 > "Hadriel Kaplan" writes: > >Specific comments: > >1) Since RTCP packets have to be sent as compounds with SR/RR first > >(right?), why do the other RTCP PT's matter for collisions? Because they > >could be sent over TCP, and thus be a stream? Or just for protocol > purity > >of them being "packets"? Perhaps that should be stated in the draft, in > >case someone wonders. >=20 > Good point - RTCP does ALWAYS have to start with SR or RR, so those are > the only ones you need to worry about. Even on TCP, you know the framing > of packets, so others won't be an issue. [A] Is a new RTP profile allowed to relax the requirement that RTCP packet need not always start with SR or RR?=20 I see such relaxation useful with existing profile AVPF which allows much smaller RTCP intervals than AVP. I prefer to use such benefit in a unicast environment for providing only relevant feedback to the sender and avoid unnecessary resource consumption by packing RR/SR with each and every AVPF feedback message. A receiver can however continue to send RR/SR messages at the same resolution as AVP used to provide. Mandating RR in every RTCP packet for the sake of increasing the resolution of statistics isn't really a big plus in this scenario. Not having to stick an RR (and other irrelevant messages) will reduce the average RTCP packet size, Avg., RTCP interval, and average bit rate of RTCP stream. All these provide benefits in some network environments. If there are any (future) implementations which do not stick RR/SR with every out going RTCP packet, they would definitely benefit from avoiding the collision of RTP PT with RTCP PT of non SR/RR packets. Hence, it would be safe to avoid such collision with all possible payload types of RTCP packets. >=20 > >2) What does this mean for bandwidth values encoded in SDP? Should it > >include the RTCP overhead in b=3DAS, or not? Or mandate using RFC = 3556 > >b=3DRS/RR encoding? >=20 > Good question. If you include the BW of the RTCP (b=3DAS:), then > some QoS solutions will allocate that plus 5% for RTCP. That may not > be a big problem (some wasted reservation, if the QoS reserver doesn't > understand this draft). If you use AS, you should include it because a > QoS service might reserve on a per-port basis. RS/RR might make sense > (I'd have to brush up on them). For a session negotiated with offer/answer model: Per current definition, AS specifies the max receive bandwidth for the media stream. If there is no RS/RR, as a receiver, I would allocate QoS for (AS + 5% of AS) for the receive stream. If there is RS/RR, as a receiver, I would allocate QoS for (AS + RS from the SDP answer + RR from the SDP answer) >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com >=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 Thu Sep 14 19:26:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO0aG-0003E8-2T; Thu, 14 Sep 2006 19:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO0aE-0003E0-P3 for avt@ietf.org; Thu, 14 Sep 2006 19:25:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO0aE-0002ph-7W for avt@ietf.org; Thu, 14 Sep 2006 19:25:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8ENPLCI004264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Sep 2006 16:25:22 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8ENPKhu022449; Thu, 14 Sep 2006 16:25:20 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 16:25:20 -0700 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] VoIP Shim for RTP Payload Formats Date: Thu, 14 Sep 2006 16:25:16 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A956@NAEX01.na.qualcomm.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03DCA8B5@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkAAyiKd8ACfhPeQABfzDmA= From: "Desineni, Harikishan" To: "Even, Roni" , "Ingemar Johansson S $LU/EAB$" , "Colin Perkins" X-OriginalArrivalTime: 14 Sep 2006 23:25:20.0052 (UTC) FILETIME=[0B541F40:01C6D855] X-Spam-Score: 0.0 (/) 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: , Errors-To: avt-bounces@ietf.org "mbs" in SDP is to communicate the max rate (parameter) at the time of call setup (offer/answer). During the call, max bit rate ("mbs") updates can be communicated using in-band signaling. At the time of call set up, "mbs" is serving as a parameter. During the call, "mbs" in the payload header is acting as a request to the other end. In this scenario, using in-band looks like a better approach than updating SDP. SDP update would require parsing the entire SDP and identifying the modified value, which doesn't look like a nice implementation and may not be as fast as in-band signaling. In-band signaling in offer/answer sessions is definitely a good approach if the information being carried is not part of SDP. I agree with you that in-band signaling shall not be used as a back door to update any attribute values that might have been communicated via SDP during call setup. In theory, a receiver can use in-band signaling to carry whatever feedback information RTCP can carry. I prefer to see in-band signaling as a means to provide quick feedback of delay sensitive information to the remote end (sender) in unicast configurations. As pointed out by Colin, using SHIM is like proposing a new RTP profile, which will introduce profile negotiation issues which are being worked out in MMUSIC. If this approach is chosen, then I prefer this one to evolve as a new RTP profile optimized for point to point conversational multi-media services. This would make SHIMs more generic for use by other media types, and a place holder for other RTP/RTCP optimizations applicable in point to point topology. - - - - - - - - - - - - - - - - - - Harikishan Desineni Qualcomm Inc., mailto:hd@qualcomm.com > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, September 14, 2006 8:48 AM > To: Ingemar Johansson S (LU/EAB); Desineni, Harikishan; Colin Perkins > Cc: avt@ietf.org > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats >=20 > Hi, > I think that I was not clear about capabilities. > What I meant was not that SDP should be used to find if Shim should be > used but I said that Shim should not be used to replace SDP by signaling > end to end capabilities that are to be conveyed in SDP. The extreme case > is to signal all optional parameters defined in SDP via in-band > signaling, the example for G.729 looked to me like SDP and not in-band > Roni >=20 >=20 > > -----Original Message----- > > From: Ingemar Johansson S (LU/EAB) > > [mailto:ingemar.s.johansson@ericsson.com] > > Sent: Monday, September 11, 2006 10:21 AM > > To: Even, Roni; Desineni, Harikishan; Colin Perkins > > Cc: avt@ietf.org > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > Hi > > > > I agree that capabilities should be exhanged (eg. SDP) in order to > > decide if Shim should be allowed. > > The main application is point to point communication. > > Of the cases below I belive that in case 1 and 2 Shim should be > avoided. > > In case 3 it may be possible to use Shim if a conference bridge can do > > policing on the Shim information. > > > > Ingemar > > > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: den 7 september 2006 08:48 > > > To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S > (LU/EAB) > > > Cc: avt@ietf.org > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > Hi, > > > I want to put my 2 cents on in band signaling. > > > > > > I would agree that in-band signaling will work I point to point > call. > > > Care should be taken for the following cases > > > > > > 1. Unidirectional media. > > > 2. Multicast > > > 3. Multipoint cases > > > > > > That is why I think that capabilities should be in the > > > signaling path In the media path you can have changes which > > > are of a temporary nature like rate change commands for video > > > or audio or indications. > > > > > > I think you suggest a capability describing a more permanent > > > state which should be in SDP. > > > > > > Roni Even > > > > > > > -----Original Message----- > > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > > Sent: Wednesday, September 06, 2006 10:57 PM > > > > To: Colin Perkins; Ingemar Johansson S ((LU/EAB)) > > > > Cc: avt@ietf.org > > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > > > > > I am under the impression that in-band signaling inside > > > payload header > > > > is an accepted concept in this community. Other than AMR Payload > > > format, > > > > there is another payload format which is trying to use this > concept. > > > > Once such work is the use of MBS field in Sec 5.2 > > > > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt > > > > > > > > "MBS (4 bits): maximum bit rate supported. Indicates a > > > maximum bit > > > > rate to the encoder at the site of the receiver of this payload." > > > > > > > > I think that RTCP (AVPF) has a similar message which can be used > to > > > > convey maximum bit rate to the encoder at the remote end. > > > > > > > > I'd like to infer the following statements from the > > > reference to the > > > > above work in RTP and RTCP: > > > > > > > > 1) In-band signaling using RTP payload header is an > > > allowed/accepted > > > > concept. > > > > 2) RTCP signaling may also exist to carry the same information. > > > > > > > > In certain scenarios (MOH, voice mail), RTCP signaling is > > > unavoidable. > > > > One will end up defining methods to carry the same > > > information using > > > > both in-band RTP and RTCP based feedback. > > > > > > > > -----Original Message----- > > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > > Sent: Friday, August 25, 2006 7:30 AM > > > > To: Ingemar Johansson S ((LU/EAB)) > > > > Cc: avt@ietf.org > > > > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > > Inband signaling of the type proposed already exist for eg. > > > > > the AMR payload format (RFC3267), it is however limited to the > > > > > request of lower/higher codec rate. The intention of this added > > > > > inband signaling is to allow for requests regarding frame > > > aggregation > > > > > and redundancy during a session so in that aspect it is a > > > > > continuation of the inband signaling concept that already exist. > > > > > > > > This is one of the less desirable features of the AMR > > > payload format, > > > > and was included solely for backwards compatibility. > > > > > > > > > > > > Colin > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 03:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7xb-0005Lg-2A; Fri, 15 Sep 2006 03:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7xZ-0005IY-8K for avt@ietf.org; Fri, 15 Sep 2006 03:18:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7mt-0005qH-A9 for avt@ietf.org; Fri, 15 Sep 2006 03:07:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8D50B4F0025; Fri, 15 Sep 2006 09:06:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 09:06:55 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 09:06:55 +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] VoIP Shim for RTP Payload Formats Date: Fri, 15 Sep 2006 09:06:54 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E024@esealmw109.eemea.ericsson.se> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A956@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats thread-index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkAAyiKd8ACfhPeQABfzDmAAER94cA== From: "Ingemar Johansson S $LU/EAB$" To: "Desineni, Harikishan" , "Even, Roni" , "Colin Perkins" X-OriginalArrivalTime: 15 Sep 2006 07:06:55.0500 (UTC) FILETIME=[871A1CC0:01C6D895] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 Hi As Mr Desiniemi pointed out the purpose of the inband signaling (e.g Shim) is to transmit delay sensitive information, the purpose is not to replace SDP.=20 SDP will be used to do session negotiation, among that it should be possible to negotiate if Shim inband signaling should be allowed/used during the session. =20 The aproach that is proposed in connection with the Shim draft is to, in its simplest form, to propose two payload types, for example=20 PT=3D97 : AMR=20 PT=3D98 : AMR with Shim It is then possible for the other end to accept one or both of the proposed PT's.=20 There is a possibility that a new session negotiation might take place for instance at an handover from a HSPA network to a GERAN-EDGE network, however it is very possible that the applications won't know that this happen (the radio interface might for instance be connected to a laptop via USB). Also if one use SDP it very easily becomes quite large messages even though compression is used. The word from the "network" guys that I ask is "don't count on session re-negotiation" in the middle of a session. One exception is of course if one add a new component or switch to a 3party call. As for a completely new RTP profile, it is possible that this is the way to go in the long perspective but this seems to be something that may take some time before it is settled.=20 The Shim proposal is something that will hopefully be added to the MTSI (Multimedia Telephony Service over IMS) standardization in 3GPP and the time perspective is such that it should preferrably be settled by the end of this year. =20 Regards Ingemar > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com]=20 > Sent: den 15 september 2006 01:25 > To: Even, Roni; Ingemar Johansson S (LU/EAB); Colin Perkins > Cc: avt@ietf.org > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats >=20 >=20 > "mbs" in SDP is to communicate the max rate (parameter) at=20 > the time of call setup (offer/answer). During the call, max=20 > bit rate ("mbs") updates can be communicated using in-band=20 > signaling. At the time of call set up, "mbs" is serving as a=20 > parameter. During the call, "mbs" in the payload header is=20 > acting as a request to the other end. >=20 > In this scenario, using in-band looks like a better approach=20 > than updating SDP. SDP update would require parsing the=20 > entire SDP and identifying the modified value, which doesn't=20 > look like a nice implementation and may not be as fast as=20 > in-band signaling. In-band signaling in offer/answer sessions=20 > is definitely a good approach if the information being=20 > carried is not part of SDP. >=20 > I agree with you that in-band signaling shall not be used as=20 > a back door to update any attribute values that might have=20 > been communicated via SDP during call setup. In theory, a=20 > receiver can use in-band signaling to carry whatever feedback=20 > information RTCP can carry. I prefer to see in-band signaling=20 > as a means to provide quick feedback of delay sensitive=20 > information to the remote end (sender) in unicast configurations. >=20 > As pointed out by Colin, using SHIM is like proposing a new=20 > RTP profile, which will introduce profile negotiation issues=20 > which are being worked out in MMUSIC. If this approach is=20 > chosen, then I prefer this one to evolve as a new RTP profile=20 > optimized for point to point conversational multi-media=20 > services. This would make SHIMs more generic for use by other=20 > media types, and a place holder for other RTP/RTCP=20 > optimizations applicable in point to point topology. >=20 >=20 > - - - - - - - - - - - - - - - - - - > Harikishan Desineni > Qualcomm Inc., > mailto:hd@qualcomm.com >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Thursday, September 14, 2006 8:48 AM > > To: Ingemar Johansson S (LU/EAB); Desineni, Harikishan;=20 > Colin Perkins > > Cc: avt@ietf.org > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > >=20 > > Hi, > > I think that I was not clear about capabilities. > > What I meant was not that SDP should be used to find if=20 > Shim should be=20 > > used but I said that Shim should not be used to replace SDP by > signaling > > end to end capabilities that are to be conveyed in SDP. The extreme > case > > is to signal all optional parameters defined in SDP via in-band=20 > > signaling, the example for G.729 looked to me like SDP and=20 > not in-band=20 > > Roni > >=20 > >=20 > > > -----Original Message----- > > > From: Ingemar Johansson S (LU/EAB) > > > [mailto:ingemar.s.johansson@ericsson.com] > > > Sent: Monday, September 11, 2006 10:21 AM > > > To: Even, Roni; Desineni, Harikishan; Colin Perkins > > > Cc: avt@ietf.org > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > Hi > > > > > > I agree that capabilities should be exhanged (eg. SDP) in=20 > order to=20 > > > decide if Shim should be allowed. > > > The main application is point to point communication. > > > Of the cases below I belive that in case 1 and 2 Shim should be > > avoided. > > > In case 3 it may be possible to use Shim if a conference=20 > bridge can > do > > > policing on the Shim information. > > > > > > Ingemar > > > > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: den 7 september 2006 08:48 > > > > To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S > > (LU/EAB) > > > > Cc: avt@ietf.org > > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > Hi, > > > > I want to put my 2 cents on in band signaling. > > > > > > > > I would agree that in-band signaling will work I point to point > > call. > > > > Care should be taken for the following cases > > > > > > > > 1. Unidirectional media. > > > > 2. Multicast > > > > 3. Multipoint cases > > > > > > > > That is why I think that capabilities should be in the=20 > signaling=20 > > > > path In the media path you can have changes which are of a=20 > > > > temporary nature like rate change commands for video or=20 > audio or=20 > > > > indications. > > > > > > > > I think you suggest a capability describing a more=20 > permanent state=20 > > > > which should be in SDP. > > > > > > > > Roni Even > > > > > > > > > -----Original Message----- > > > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > > > Sent: Wednesday, September 06, 2006 10:57 PM > > > > > To: Colin Perkins; Ingemar Johansson S ((LU/EAB)) > > > > > Cc: avt@ietf.org > > > > > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > > > > > > > > I am under the impression that in-band signaling inside > > > > payload header > > > > > is an accepted concept in this community. Other than=20 > AMR Payload > > > > format, > > > > > there is another payload format which is trying to use this > > concept. > > > > > Once such work is the use of MBS field in Sec 5.2=20 > > > > > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt > > > > > > > > > > "MBS (4 bits): maximum bit rate supported. Indicates a > > > > maximum bit > > > > > rate to the encoder at the site of the receiver of this > payload." > > > > > > > > > > I think that RTCP (AVPF) has a similar message which=20 > can be used > > to > > > > > convey maximum bit rate to the encoder at the remote end. > > > > > > > > > > I'd like to infer the following statements from the > > > > reference to the > > > > > above work in RTP and RTCP: > > > > > > > > > > 1) In-band signaling using RTP payload header is an > > > > allowed/accepted > > > > > concept. > > > > > 2) RTCP signaling may also exist to carry the same=20 > information. > > > > > > > > > > In certain scenarios (MOH, voice mail), RTCP signaling is > > > > unavoidable. > > > > > One will end up defining methods to carry the same > > > > information using > > > > > both in-band RTP and RTCP based feedback. > > > > > > > > > > -----Original Message----- > > > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > > > Sent: Friday, August 25, 2006 7:30 AM > > > > > To: Ingemar Johansson S ((LU/EAB)) > > > > > Cc: avt@ietf.org > > > > > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats > > > > > > > > > > > Inband signaling of the type proposed already exist for eg. > > > > > > the AMR payload format (RFC3267), it is however=20 > limited to the=20 > > > > > > request of lower/higher codec rate. The intention of this > added > > > > > > inband signaling is to allow for requests regarding frame > > > > aggregation > > > > > > and redundancy during a session so in that aspect it is a=20 > > > > > > continuation of the inband signaling concept that already > exist. > > > > > > > > > > This is one of the less desirable features of the AMR > > > > payload format, > > > > > and was included solely for backwards compatibility. > > > > > > > > > > > > > > > Colin > > > > > > > > > > _______________________________________________ > > > > > Audio/Video Transport Working Group avt@ietf.org=20 > > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > _______________________________________________ > > > > > Audio/Video Transport Working Group avt@ietf.org=20 > > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 10:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOF42-00083Y-In; Fri, 15 Sep 2006 10:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOF41-00083T-BX for avt@ietf.org; Fri, 15 Sep 2006 10:53:09 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOF40-0007JE-2G for avt@ietf.org; Fri, 15 Sep 2006 10:53:09 -0400 Received: from vpn12.dcs.gla.ac.uk ([130.209.254.12]:52962) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1GOF3t-0003z2-RO; Fri, 15 Sep 2006 15:53:02 +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: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.txt Date: Fri, 15 Sep 2006 13:18:31 +0100 To: Ladan Gharai X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF AVT Working Group 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 Ladan, On 8 Sep 2006, at 22:13, Ladan Gharai wrote: > Dear AVT'ers: > > A new revision of the "RTP Profile for TCP Friendly Rate Control" > is now available. > > There are a number of changes since the previous version of the > draft. Most notably that the profile is now an extension of the > AVPF profile and defines a new AVPF feedback packet for the TFRC > algorithm. > > An alternative approach to defining a new profile is to use header > extensions per draft-ietf-avt-rtp-hdrext-04. There was a general > extensive discussion of the merit of each approach (new profile > vs. use of header extensions) at the last IETF. However, I am not > sure if a conclusion was gained? Defining a new profile, with extensions to the fixed RTP header, is somewhat more bandwidth efficient than using the mechanisms in rtp- hdrext, but is not backwards compatible (and hence there might be deployment challenges). Which is best is a design trade-off, with no single correct answer, although my personal opinion is that backwards compatibility and deployability are more important than saving a few octets per packet. > The draft also discusses the issues of RTCP bandwidth for AVPFCC > flows with relatively small (say less than 20 ms) round trip times. > The draft recommands abiding by the AVP 5% constraint, however this > can preclude certain flows with small RTTs. We have mechanisms for signalling a different RTCP bandwidth fraction [RFC 3566]. I'm curious why they're not used, rather than precluding certain flows from using congestion control? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 11:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFIh-0006jU-Aw; Fri, 15 Sep 2006 11:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFIf-0006jN-H0 for avt@ietf.org; Fri, 15 Sep 2006 11:08:17 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFIe-0000MG-5Z for avt@ietf.org; Fri, 15 Sep 2006 11:08:17 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 11:08:15 -0400 To: "Desineni, Harikishan" Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent References: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A910@NAEX01.na.qualcomm.com> From: Randell Jesup Date: Fri, 15 Sep 2006 11:08:13 -0400 In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A910@NAEX01.na.qualcomm.com> (Harikishan Desineni's message of "Thu, 14 Sep 2006 14:45:34 -0700") 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: 15 Sep 2006 15:08:15.0435 (UTC) FILETIME=[C4E279B0:01C6D8D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Gunnar Hellstrom , Colin Perkins , AVT WG 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 "Desineni, Harikishan" writes: >What if you allow the following? Both RTP streams will arrive on 20000 >and the receiver will demux based on payload type. Wouldn't this work as >long as the payload type for both media streams is not the same? > >m=audio 20000 RTP/AVP 0 >m=video 20000 RTP/AVP 99 >a=rtpmap:99 H263/90000 > >This draft is proposing that a payload type be used for de-multiplexing >RTP and RTCP. This might just work to de-mux RTP streams as well. The >above SDP signaling approach looks much simpler than PLEX proposal (if >you choose to use PT as demux point). I agree it *appears* simpler (though you're more limited due to available payload values). A few issues though: 1) To share media streams using the same codecs you'd need to use different payloads, even for "standard" codecs like PCMU. Not a big deal. 2) RTCP doesn't specify payload types, only SSRCs. This could be a problem, even for UAs/etc that know about this idea. 3) I guarantee this WILL break/crash/confuse existing UAs, SBCs, etc. Trying to shoehorn in something like this using existing signalling is simply dangerous; it will cause problems in practice. Now, you could try to come up with a signalling approach for initiating a PLEX connection without requiring another round-trip if the called UA didn't understand it; something like the capability stuff being discussed. I think also architecturally a PLEX-style transport-layer makes more sense, and isolates that complexity at that level. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 11:19:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFTE-0001Qs-O4; Fri, 15 Sep 2006 11:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFTD-0001Q0-Cb for avt@ietf.org; Fri, 15 Sep 2006 11:19:11 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFTC-00017A-3Y for avt@ietf.org; Fri, 15 Sep 2006 11:19:11 -0400 Received: from vpn12.dcs.gla.ac.uk ([130.209.254.12]:53045) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1GOFTB-0006nc-G2; Fri, 15 Sep 2006 16:19:09 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt - multiplexing to what extent Date: Fri, 15 Sep 2006 16:19:06 +0100 To: Gunnar Hellstrom X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: AVT WG 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 Gunnar, [Apologies for the slow response, I've been travelling] On 9 Sep 2006, at 05:55, Gunnar Hellstrom wrote: > Colin and Magnus, > Thanks for a good initiative and a good draft. > It seems to cover part of the need for multiplexing in a good way. > > But, I suggest that you in the abstract and early in the text > describe to > what extent you solve the multiplexing problem. > > I read it with the initial hope that you proposed a method to > multiplex all > RTP and RTCP streams in e.g. a SIP session onto one UDP port. > > I had to read it all through down below the sdp example, before I > could > conclude that the method does not cover the problems that would > occur if you > want to multiplex all media in a session onto the same port. > > In multimedia applications, it is a similar burden to handle all > media rtp > streams through NAT. > > By this draft you cover half of the problem - the RTP-RTCP > multiplexing > belonging to one RTP session, but not how to multiplex all RTP > sessions with > its RTCP. Please indicate that early in the draft with wording that > not > forbids solving the other half of the problem. I believe that multiplexing RTP streams representing different types of media onto a single port is a mistake, for the reasons enumerated in Section 5.2 of RFC 3550. I'll add a reference to that discussion, but I have no intention of changing this behaviour. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 11:42:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFp2-0003zn-6m; Fri, 15 Sep 2006 11:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFp0-0003yZ-Ib for avt@ietf.org; Fri, 15 Sep 2006 11:41:42 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFoz-0002Z8-Bx for avt@ietf.org; Fri, 15 Sep 2006 11:41:42 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 11:41:37 -0400 To: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.txt References:

From: Randell Jesup Date: Fri, 15 Sep 2006 11:41:35 -0400 In-Reply-To: (Colin Perkins's message of "Fri, 15 Sep 2006 13:18:31 +0100") 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: 15 Sep 2006 15:41:37.0473 (UTC) FILETIME=[6E313B10:01C6D8DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ladan Gharai , IETF AVT Working Group 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 Colin Perkins writes: >> The draft also discusses the issues of RTCP bandwidth for AVPFCC flows >> with relatively small (say less than 20 ms) round trip times. The draft >> recommands abiding by the AVP 5% constraint, however this can preclude >> certain flows with small RTTs. > >We have mechanisms for signalling a different RTCP bandwidth fraction [RFC >3566]. I'm curious why they're not used, rather than precluding certain >flows from using congestion control? I can't say, but one guess (alluded to in a different context in the last day) is that RTCP is not ... small. When being used for this type of realtime feedback, as opposed to the original usage (primarily reporting), it rapidly starts eating up a disproportionate percentage of your bandwidth. It seems odd to me to spend 10 or 15% (or more! I think it can end up going over 50%) of my bandwidth just for congestion control (and in the process making congestion worse...). Just a guess. As an aside: I wouldn't be shocked (Hadriel?) if some existing B2BUAs and SBCs (and QoS setups on cable CMTSes) limit RTCP to 5% regardless of signalling... :-( That's not a reason to avoid trying, though. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 12:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGAO-0007uR-LS; Fri, 15 Sep 2006 12:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGAN-0007rH-6Z for avt@ietf.org; Fri, 15 Sep 2006 12:03:47 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGAL-0004yz-Vi for avt@ietf.org; Fri, 15 Sep 2006 12:03:47 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 12:03:46 -0400 To: Colin Perkins Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt - multiplexing to what extent References:

From: Randell Jesup Date: Fri, 15 Sep 2006 12:03:44 -0400 In-Reply-To: (Colin Perkins's message of "Fri, 15 Sep 2006 16:19:06 +0100") 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: 15 Sep 2006 16:03:46.0296 (UTC) FILETIME=[863B8780:01C6D8E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Gunnar Hellstrom , AVT WG 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 Colin Perkins writes: >I believe that multiplexing RTP streams representing different types of >media onto a single port is a mistake, for the reasons enumerated in >Section 5.2 of RFC 3550. I'll add a reference to that discussion, but I >have no intention of changing this behaviour. 5.2 talks more about multiplexing via PT or SSRC as opposed to port number per se; it says that different streams should use different transport addresses. While Gunnar's proposal doesn't do that, the PLEX transport-level mux would, and so avoid all of the points in 5.2. As for 5.2 itself, I think point 4 may be wrong (though I'm not an expert on mixing), and point 5 I think is at least mostly incorrect, at least as far as this discussion: Using different network paths: since the receiver is specifying it wants to receive on the same port, that's not an issue - they chose it. Reception of a subset of media if desired for bw: again, they chose the media; if they don't want to receive all the media they should reject those streams. And simply not servicing the port won't save you bandwidth; you need to not accept or you need to renegotiate. Separate processes: You _can_ demux data off to separate processes regardless of whether the mux point is port, PT, or SSRC; it may be "cleaner" to mux at the transport level, but it can be done easily almost anywhere. In any case, I do agree a transport-level mux is cleaner (ala 'PLEX' or equivalent). 5.2 was written in a time when NAT was unusual at best, note, so there are issues that didn't exist then (like time to open ports via ICE/etc, resources used by TURN servers, etc). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 12:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGdF-00032Z-2f; Fri, 15 Sep 2006 12:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGdD-00030t-OY for avt@ietf.org; Fri, 15 Sep 2006 12:33:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGdB-0000t4-NV for avt@ietf.org; Fri, 15 Sep 2006 12:33:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8FGXTlc010753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2006 09:33:30 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8FGWlBZ016666; Fri, 15 Sep 2006 09:33:28 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 09:33:26 -0700 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] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent Date: Fri, 15 Sep 2006 09:33:24 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4A9E8@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent Thread-Index: AcbY2SB9A/QEWEwbSWqwDF85+aF1mAAChLLA From: "Desineni, Harikishan" To: "Randell Jesup" X-OriginalArrivalTime: 15 Sep 2006 16:33:26.0025 (UTC) FILETIME=[AB089F90:01C6D8E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Gunnar Hellstrom , Colin Perkins , AVT WG 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 How about this approach of signaling the common RTP port using "a=3Drtp-mux"? a=3Drtp-mux: 20000 m=3Daudio 20000 RTP/AVP 0 m=3Dvideo 40000 RTP/AVP 99 a=3Drtpmap:99 H263/90000 This would solve issue 3 and does not require another round trip time if the answerer does not support rtp muxing. Issue 2 does not look like a problem if we make sure that PT field of RTCP and PT field of RTP do not conflict as stated in the draft. Here each media stream would use a different SSRC. So, points 1,2,3 from Sec 5.2, RFC 3550 do not apply for this case. And I agree with you that point 4 and 5 may not be real issues. - - - - - - - - - - - - - - - - - - Harikishan Desineni Qualcomm Inc., mailto:hd@qualcomm.com > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Friday, September 15, 2006 8:08 AM > To: Desineni, Harikishan > Cc: Gunnar Hellstrom; Colin Perkins; AVT WG > Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux- > 00.txt- multiplexing to what extent >=20 > "Desineni, Harikishan" writes: > >What if you allow the following? Both RTP streams will arrive on 20000 > >and the receiver will demux based on payload type. Wouldn't this work as > >long as the payload type for both media streams is not the same? > > > >m=3Daudio 20000 RTP/AVP 0 > >m=3Dvideo 20000 RTP/AVP 99 > >a=3Drtpmap:99 H263/90000 > > > >This draft is proposing that a payload type be used for de-multiplexing > >RTP and RTCP. This might just work to de-mux RTP streams as well. The > >above SDP signaling approach looks much simpler than PLEX proposal (if > >you choose to use PT as demux point). >=20 > I agree it *appears* simpler (though you're more limited due to available > payload values). >=20 > A few issues though: > 1) To share media streams using the same codecs you'd need to use > different > payloads, even for "standard" codecs like PCMU. Not a big deal. > 2) RTCP doesn't specify payload types, only SSRCs. This could be a > problem, even for UAs/etc that know about this idea. > 3) I guarantee this WILL break/crash/confuse existing UAs, SBCs, etc. >=20 > Trying to shoehorn in something like this using existing signalling is > simply dangerous; it will cause problems in practice. >=20 > Now, you could try to come up with a signalling approach for initiating > a PLEX connection without requiring another round-trip if the called UA > didn't understand it; something like the capability stuff being discussed. >=20 > I think also architecturally a PLEX-style transport-layer makes more sense, > and isolates that complexity at that level. >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 12:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGrP-0001N9-70; Fri, 15 Sep 2006 12:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGrN-0001Kq-Eq for avt@ietf.org; Fri, 15 Sep 2006 12:48:13 -0400 Received: from porter.east.isi.edu ([65.114.168.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGrL-0004Sv-Bb for avt@ietf.org; Fri, 15 Sep 2006 12:48:12 -0400 Received: from [65.114.168.149] (java.east.isi.edu [65.114.168.149]) by porter.east.isi.edu (Postfix) with ESMTP id 370661BE0; Fri, 15 Sep 2006 12:48:11 -0400 (EDT) In-Reply-To: References:

Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B50F9AB-04F0-4770-AC44-AC08167A8F52@ISI.EDU> Content-Transfer-Encoding: 7bit From: Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.txt Date: Fri, 15 Sep 2006 12:54:06 -0400 To: Colin Perkins X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: IETF AVT Working Group 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 Sep 15, 2006, at 8:18 AM, Colin Perkins wrote: > Ladan, Hi Colin: thank you for the feedback please see my comments inline Ladan > > On 8 Sep 2006, at 22:13, Ladan Gharai wrote: > >> Dear AVT'ers: >> >> A new revision of the "RTP Profile for TCP Friendly Rate Control" >> is now available. >> >> There are a number of changes since the previous version of the >> draft. Most notably that the profile is now an extension of the >> AVPF profile and defines a new AVPF feedback packet for the TFRC >> algorithm. >> >> An alternative approach to defining a new profile is to use header >> extensions per draft-ietf-avt-rtp-hdrext-04. There was a general >> extensive discussion of the merit of each approach (new profile >> vs. use of header extensions) at the last IETF. However, I am not >> sure if a conclusion was gained? >> > > Defining a new profile, with extensions to the fixed RTP header, is > somewhat more bandwidth efficient than using the mechanisms in rtp- > hdrext, but is not backwards compatible (and hence there might be > deployment challenges). Which is best is a design trade-off, with > no single correct answer, although my personal opinion is that > backwards compatibility and deployability are more important than > saving a few octets per packet. the other point that came up at the last AVT session was that using defining a profile is more inline with RTP design principles but, as you point out, it essentially boils down to tradeoffs and I would be interested in hearing from other AVTers and RTP users on their thoughts on the tradeoff - and which design, profile vs. extensions, they would be more likely to use/implement > > >> The draft also discusses the issues of RTCP bandwidth for AVPFCC >> flows with relatively small (say less than 20 ms) round trip >> times. The draft recommands abiding by the AVP 5% constraint, >> however this can preclude certain flows with small RTTs. >> > > We have mechanisms for signalling a different RTCP bandwidth > fraction [RFC 3566]. I'm curious why they're not used, rather than > precluding certain flows from using congestion control? my text was badly worded we can certainly use mechanisms that signal using a higher RTCP bandwidth on feedback but what is the breaking point for too much feedback? 5% 10% 15% ... 50%? for TFRC at small RTTs with RTCP packets things can get out of hand quickly while this is more a TFRC mechanism issue (does anyone know how dccp addresses this?) I do believe that the AVPFCC profile should provide some guidelines > > Colin > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Sep 15 13:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOH3x-0006YY-9w; Fri, 15 Sep 2006 13:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOH3v-0006YT-EN for avt@ietf.org; Fri, 15 Sep 2006 13:01:11 -0400 Received: from porter.east.isi.edu ([65.114.168.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOH3s-0006FE-5m for avt@ietf.org; Fri, 15 Sep 2006 13:01:11 -0400 Received: from [65.114.168.149] (java.east.isi.edu [65.114.168.149]) by porter.east.isi.edu (Postfix) with ESMTP id F01CD1C58; Fri, 15 Sep 2006 13:01:07 -0400 (EDT) In-Reply-To: References:

Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-06.txt Date: Fri, 15 Sep 2006 13:07:02 -0400 To: Randell Jesup X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Colin Perkins , IETF AVT Working Group 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 Sep 15, 2006, at 11:41 AM, Randell Jesup wrote: > Colin Perkins writes: > >>> The draft also discusses the issues of RTCP bandwidth for AVPFCC >>> flows >>> with relatively small (say less than 20 ms) round trip times. >>> The draft >>> recommands abiding by the AVP 5% constraint, however this can >>> preclude >>> certain flows with small RTTs. >>> >> >> We have mechanisms for signalling a different RTCP bandwidth >> fraction [RFC >> 3566]. I'm curious why they're not used, rather than precluding >> certain >> flows from using congestion control? >> > > I can't say, but one guess (alluded to in a different context in > the last > day) is that RTCP is not ... small. When being used for this type of > realtime feedback, as opposed to the original usage (primarily > reporting), > it rapidly starts eating up a disproportionate percentage of your > bandwidth. It seems odd to me to spend 10 or 15% (or more! I think > it can > end up going over 50%) of my bandwidth just for congestion control > (and in > the process making congestion worse...). right - the issue at hand is how much feedback is too much feedback? especially as the feedback path is not congestion control for the AVPFCC profile, the problem arises at small RTTS (under 20ms - which really is not that small) and the need for feedback at least once every RTT, so as you point out, you can get into situations where the feedback bandwidth is 50% of the actual data flow! while RTCP packets are not small, modifying them to be smaller, would not really solve the problem for the AVPFCC profile and would just push it to down to lower RTTs the real question (which is out of the scope for the draft) here is do rate based congestion control schemes really, really need feedback once per RTT (at small RTTs) in order to be fair to other flows and react to congestion in a timely manner > > Just a guess. > > As an aside: I wouldn't be shocked (Hadriel?) if some existing > B2BUAs and > SBCs (and QoS setups on cable CMTSes) limit RTCP to 5% regardless of > signalling... :-( That's not a reason to avoid trying, though. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.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 Fri Sep 15 13:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHAc-0001MX-Uq; Fri, 15 Sep 2006 13:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHAb-0001LQ-MV for avt@ietf.org; Fri, 15 Sep 2006 13:08:05 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOHAa-000710-9t for avt@ietf.org; Fri, 15 Sep 2006 13:08:05 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8FH7xZd021760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2006 10:08:00 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8FH7ae3007897; Fri, 15 Sep 2006 10:07:58 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 10:06:08 -0700 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] VoIP Shim for RTP Payload Formats Date: Fri, 15 Sep 2006 10:06:07 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01F4AA0F@NAEX01.na.qualcomm.com> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E024@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] VoIP Shim for RTP Payload Formats Thread-Index: AcbIU0AZUT+Jg2XDSrqj4REQuDMfowJmJW+QABc2nkAAyiKd8ACfhPeQABfzDmAAER94cAAUsixQ From: "Desineni, Harikishan" To: "Ingemar Johansson S $LU/EAB$" , "Even, Roni" , "Colin Perkins" X-OriginalArrivalTime: 15 Sep 2006 17:06:08.0527 (UTC) FILETIME=[3CC6A9F0:01C6D8E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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:

University Degree