Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt
Harald Alvestrand <harald@alvestrand.no> Tue, 05 June 2012 06:52 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9567321F86FD for <avt@ietfa.amsl.com>; Mon, 4 Jun 2012 23:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.359
X-Spam-Level:
X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100]
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 5SwwvZU51Sh8 for <avt@ietfa.amsl.com>; Mon, 4 Jun 2012 23:52:18 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFB621F86F7 for <avt@ietf.org>; Mon, 4 Jun 2012 23:52:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DD3339E0A3 for <avt@ietf.org>; Tue, 5 Jun 2012 08:52:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtR9Qh+bTXN9 for <avt@ietf.org>; Tue, 5 Jun 2012 08:52:11 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 764C939E089 for <avt@ietf.org>; Tue, 5 Jun 2012 08:52:11 +0200 (CEST)
Message-ID: <4FCDAC9B.1040705@alvestrand.no>
Date: Tue, 05 Jun 2012 08:52:11 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: avt@ietf.org
References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2012 06:52:19 -0000
On 06/04/2012 01:07 AM, Ejzak, Richard P (Richard) wrote: > 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. Since this draft is destined for AVTCORE, I'll repeat my comments from the RTCWEB discussion here, and encourage people to keep the discussion on 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. > > Richard > > -----Original Message----- > From: 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 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >
- [AVTCORE] multi session draft-ejzak-avtcore-rtp-s… Ejzak, Richard P (Richard)
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Harald Alvestrand
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Christer Holmberg
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Ejzak, Richard P (Richard)
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Harald Alvestrand
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Ejzak, Richard P (Richard)
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Harald Alvestrand
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Marshall Eubanks
- Re: [AVTCORE] multi session draft-ejzak-avtcore-r… Ejzak, Richard P (Richard)