Re: [rtcweb] draft on media multiplexing submitted to AVTCORE
"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Mon, 04 June 2012 20:04 UTC
Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9311E80C9 for <rtcweb@ietfa.amsl.com>; Mon, 4 Jun 2012 13:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.822
X-Spam-Level:
X-Spam-Status: No, score=-9.822 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 B0SbGjWg4j+z for <rtcweb@ietfa.amsl.com>; Mon, 4 Jun 2012 13:04:01 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54111E80BA for <rtcweb@ietf.org>; Mon, 4 Jun 2012 13:04:00 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q54K3wrG025162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 22:03:58 +0200
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 22:03:58 +0200
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 16:03:54 -0400
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE
Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAxVnAAAAcX3SA=
Date: Mon, 04 Jun 2012 20:03:51 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no>
In-Reply-To: <4FCD0198.2040307@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.11]
Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92FC55AUS70UWXCHMBA05zamal_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2012 20:04:06 -0000
Harald, While ideally we should be able to maintain the entire SSRC space for use by an RTP session, the current concept of BUNDLE breaks the model by mixing what are otherwise different RTP sessions together. The scope of an RTP session is beyond just the transport connection on which bundling is occurring (see the RTP session topology diagrams in RFC 3550). Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values cannot be independently assigned per m line with the current BUNDLE scheme since RTCP packets can be identified only using SSRC values (payload type is not a field in RTCP packets). So the bundled m lines have to share a single SSRC space, thus increasing the likelihood of SSRC collision and preventing use of the same SSRC value across m lines and ports (as some applications require). To avoid these problems, translators implementing the current BUNDLE will generally need to do SSRC mapping anyway, so BUNDLE cannot take full advantage of the "randomness and flatness of the SSRC space". I have read your draft and should have referenced it in my paper. I agree that different media types should be able to share the same transport connection. But I also see a need to be able to apply differential treatment of media types within the network. You disagree with the need to separate packets associated with different media lines for differential treatment in the network. Nevertheless, this issue has been raised in RFC 3550 and numerous drafts since then as a legitimate issue in certain deployments. While I agree with you that there are significant use cases in which such differential treatment is not necessary, there are others in which it can be very beneficial. It would be really unfortunate if there were no way to support such use cases in rtcweb. Richard ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, June 04, 2012 1:43 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details. - When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach. On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote: Please see the mail attached below that I just sent to avtcore announcing a personal ID I just submitted on the topic of media multiplexing. I am sending this notice to rtcweb since this is the group that triggered recent work on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present this work at next week's interim meeting if there is time on the agenda. It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org<mailto:avt@ietf.org>' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration. There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org<mailto:rtcweb@ietf.org> https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] draft on media multiplexing submitted to… Ejzak, Richard P (Richard)
- Re: [rtcweb] draft on media multiplexing submitte… Christer Holmberg
- Re: [rtcweb] draft on media multiplexing submitte… Ejzak, Richard P (Richard)
- Re: [rtcweb] draft on media multiplexing submitte… Christer Holmberg
- Re: [rtcweb] draft on media multiplexing submitte… Ejzak, Richard P (Richard)
- Re: [rtcweb] draft on media multiplexing submitte… Christer Holmberg
- Re: [rtcweb] draft on media multiplexing submitte… Ejzak, Richard P (Richard)
- Re: [rtcweb] draft on media multiplexing submitte… Christer Holmberg
- Re: [rtcweb] draft on media multiplexing submitte… Harald Alvestrand
- Re: [rtcweb] draft on media multiplexing submitte… Ejzak, Richard P (Richard)
- Re: [rtcweb] draft on media multiplexing submitte… Harald Alvestrand
- Re: [rtcweb] draft on media multiplexing submitte… Christer Holmberg
- Re: [rtcweb] draft on media multiplexing submitte… Colin Perkins
- Re: [rtcweb] draft on media multiplexing submitte… Harald Alvestrand
- Re: [rtcweb] draft on media multiplexing submitte… Timothy B. Terriberry
- Re: [rtcweb] draft on media multiplexing submitte… Timothy B. Terriberry
- Re: [rtcweb] draft on media multiplexing submitte… Harald Alvestrand