Re: [payload] Progressing draft-ramalho-payload-g7110-00
"Michael Ramalho (mramalho)" <mramalho@cisco.com> Wed, 17 August 2011 12:43 UTC
Return-Path: <mramalho@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0D021F8B52; Wed, 17 Aug 2011 05:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level:
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wozkN9NeEVUL; Wed, 17 Aug 2011 05:43:41 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 807B721F8ACA; Wed, 17 Aug 2011 05:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=3398; q=dns/txt; s=iport; t=1313585073; x=1314794673; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FGV5eQZRT0g3NPtz1eMCcX2xxESXMDALJwQBeKKepDk=; b=W18k0JOLFWcryNqkxwq2ad6k2LmrjDOOGkQGtxI/+1iBpJvlbzI+SAe4 p0TPtuZrXcQhWdPE4O0y1oLO+59PwLGyQa1uuuYGAUDCPKz8+rqmHpbKC qe3E8uEU0NzcBl1XjCG1YOsANoskV57nqT5KpG51oSb3wEzlU5Wz+A1rM 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EADy3S06tJXHA/2dsb2JhbABCqGd3gUABAQEBAgESAR0KRAsCAQgiBhgGAVYBAQQBGhqHTpcuAZ8ohWlfBIdgkEiLfg
X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208";a="13912696"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Aug 2011 12:44:32 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7HCiWA5005875; Wed, 17 Aug 2011 12:44:32 GMT
Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 07:44:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2011 07:44:25 -0500
Message-ID: <999109E6BC528947A871CDEB5EB908A0046EEA0E@XMB-RCD-209.cisco.com>
In-Reply-To: <20110817011050.DA5D.24F8F98F@lab.ntt.co.jp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Progressing draft-ramalho-payload-g7110-00
Thread-Index: AcxcLxOQZAnxkQWQSrOgR18a8L6KQAAC6HaQ
References: <20110814104721.2013.24F8F98F@lab.ntt.co.jp> <999109E6BC528947A871CDEB5EB908A0046EE5BB@XMB-RCD-209.cisco.com> <20110817011050.DA5D.24F8F98F@lab.ntt.co.jp>
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: payload@ietf.org, avtext@ietf.org, harada.noboru@lab.ntt.co.jp
X-OriginalArrivalTime: 17 Aug 2011 12:44:31.0976 (UTC) FILETIME=[6937CE80:01CC5CDB]
Subject: Re: [payload] Progressing draft-ramalho-payload-g7110-00
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 12:43:42 -0000
Hi Noboru, Thanks for your comments. Michael Ramalho <snip> > MAR: There are some applications (e.g., acceleration of real-time > protocols > over WANs) whereby "multiplexing multiple G.711 flows" is desired. > Granted > there are few, if any, products AT PRESENT doing this. However, for > those > applications, I think a "standardized method" to put multiple channels > in one payload is desirable. If there was any strong need for the function, someone who desires the functionality would better propose a standardized method for "multiplexing multiple G.711 flows" within the G.711 payload first. MAR: There are companies that are doing this (or planning to do this) type of multiplexing today for WAN acceleration. A characteristic of this type of product is to transport everything over UDP (yes, even TCP streams) in a tunnel and then congestion control the totality of UDP packets in the tunnel. The manner in which they do this is definitely "non-standard" in that they do things to "fake-out" the ends of the connections. In the case of TCP, they fake-out the state machines at the ends - thus the sequence numbers are even different in the TCP socket ends! [Although the basic end-to-end congestion control mechanisms of TCP - window sizes - are the same.] See next comment. Then we can discuss how to reflect the function in the G.711.0 payload based on the defined multiplexing multiple G.711 flows payload. This way, we can make sure what is the real requirements for the functionality. MAR: What I envision is that the association between the "channels" and the "RTP session endpoints" will be done in proprietary ways in this type of product. The capability we could give those designers is at least a standardized way to put multiple G.711.0 channels in one RTP payload. MAR: If there is an additional desire to standardize this application (multiplexing multiple G.711 or G.711.0 flows), we could go to mmusic to get input. The second draft I proposed (the "compression in the middle draft") could propose a particular method via header extensions ... but I have not thought that part out yet. MAR: IS there anyone out there on the avtext or payload lists have a comment here? <snip> Note that this channel example proposed here is slightly different from what is described in RFC 3551 when any of channels contains more than one G.711.0 frames. MAR: Not really ... as you state ... if the ptime of all the channels is identical ... then even if there are multiple G.711.0 frames per ptime for a given channel ... we should be OK. > MAR: If channels > 1, the buffers in the G.711 decoding process may > need to be larger ... but that is easily accomplished with some #defines > in the given application. The G.711 decoding process does not require larger buffer size though buffer size for the decoded G.711 samples shall be large enough to accommodate the decoded samples, such as, "ptime octets" for each channels ("ptime * channels" octets in total). MAR: Yep. That is what I meant to say. Therefore, we don't have to change the processing buffer size which the current G.711.0 reference software implementation uses. The bintstream can be processed frame by frame from the first frame to the last regardless if the bitstream contains multi-channel stream or not. MAR: OK.
- [payload] Progressing draft-ramalho-payload-g7110… Michael Ramalho (mramalho)
- Re: [payload] Progressing draft-ramalho-payload-g… Noboru Harada
- Re: [payload] Progressing draft-ramalho-payload-g… Michael Ramalho (mramalho)
- Re: [payload] Progressing draft-ramalho-payload-g… Noboru Harada
- Re: [payload] Progressing draft-ramalho-payload-g… Michael Ramalho (mramalho)