Re: [rtcweb] draft on media multiplexing submitted to AVTCORE

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 04 June 2012 13:54 UTC

Return-Path: <christer.holmberg@ericsson.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 670FA21F85EA for <rtcweb@ietfa.amsl.com>; Mon, 4 Jun 2012 06:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.206
X-Spam-Level:
X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 IKvb7kDjzTLt for <rtcweb@ietfa.amsl.com>; Mon, 4 Jun 2012 06:54:03 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6B21F8698 for <rtcweb@ietf.org>; Mon, 4 Jun 2012 06:54:02 -0700 (PDT)
X-AuditID: c1b4fb30-b7f606d0000002be-01-4fccbdf9e4d3
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.10.00702.9FDBCCF4; Mon, 4 Jun 2012 15:54:02 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 4 Jun 2012 15:54:01 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Mon, 04 Jun 2012 15:54:00 +0200
Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE
Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAQuY+wAAyIPyAAAVD9EA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se>
References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6vvWf8DRr6GS16G8It1v5rZ3dg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGffPn2Ar+G5QsffvY7YGxgMaXYycHBICJhKP 1y9mgbDFJC7cW8/WxcjFISRwilFi7p3/zCAJIYEFjBLnz0R3MXJwsAlYSHT/0wYJiwhkSXz9 PAWshEVAReJ92xtGkBJhAXeJheelIUo8JH5smcMOYTtJzJi4G6ycVyBc4tKT5SwQ078ySrw4 rA5icwpESszrmcAEYjMCnfP91Bowm1lAXOLWk/lMEGcKSCzZc54ZwhaVePn4HytEvajEnfb1 jBD1ehI3pk5hg7C1JZYtfA21V1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxSicm5iZk15u rpdalJlcXJyfp1ecuokRGB0Ht/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhgjRBuchftNir/s2v1MX2WXUT+nqGD9t/7cshe2r89NYv/sWuwrPiHaqFrn /3fxxav3pm5OzeX5tJLzY3i68Yrd82N631YqyNbG2fQ3ab5Ib/35wfSzkF3n16hOk61TVtkW Hdxlr74962CHQV5LtNxphYP7L3gtm7+JZ9qHc6fXSprvET/d8F6JpTgj0VCLuag4EQAaapzc XAIAAA==
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 13:54:04 -0000

Hi,

> I agree that BUNDLE in its current form would be consistent with the RTP subsessions proposal, but it would also be technically redundant.  I'm not sure exactly which comments in the paper you object to.  I agree with you about the purpose of BUNDLE 
> and that it works (with limitations) for its intended purpose.  My understanding is that BUNDLE is primarily intended for the case where a single RTP session is shared across m lines.

That is not true. That is only the "default" that we chose, and the limitations in the draft are related to the case when you use a single RTP session - they are not related to the BUNDLE mechanism as such.

> There is no need for BUNDLE (and specifically the constrained PT assignment) when you use another mechanism such as SHIM or RTP subsessions to segregate the 
> flows associated with each m line.  Whether the grouping framework is applicable is open for discussion.

You still need something in order to use identical IP address:port values for multiple m- lines.

> So perhaps we should separately discuss the grouping framework and constrained PT assignment procedures associated with BUNDLE to be sure we understand one another. 
> The source of our disagreement may be more what is meant by "BUNDLE" than anything else.  I have no problem redefining it if there is agreement to do so!

We should separate the discussions on how the multiplexing is done on the RTP level (which I think your draft mostly focuses on) and how it is signaled in SDP.

Regards,

Christer



________________________________________
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Monday, June 04, 2012 2:23 AM
To: Ejzak, Richard P (Richard); rtcweb@ietf.org
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

I will not comment on the RTP aspects of your proposal, but I don't understand your comments regarding BUNDLE.

The core purpose of BUNDLE is to allow the usage of identical IP address:port information for multiple m- lines.

It is true that BUNDLE defines that, by default, all media belong to the same RTP session. But, nothing prevents you from using BUNDLE also with multiple RTP sessions, RTP "subsession" etc. You simply need an extension mechanism  to indicate/negotiate such usage (in your case the ssrc-prefix could perhaps be used for that).

Regards,

Christer

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: 4. kesäkuuta 2012 2:10
To: rtcweb@ietf.org
Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE

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'
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] 
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