IETF Logo Mail Archive

Re: [clue] comment on draft-lennox-clue-rtp-usage-0

Jonathan Lennox <jonathan@vidyo.com> Mon, 13 February 2012 16:08 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7458521F8510 for <clue@ietfa.amsl.com>; Mon, 13 Feb 2012 08:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 igMZbI3zv7aT for <clue@ietfa.amsl.com>; Mon, 13 Feb 2012 08:08:19 -0800 (PST)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id A285821F8508 for <clue@ietf.org>; Mon, 13 Feb 2012 08:08:18 -0800 (PST)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C24A8416F10; Mon, 13 Feb 2012 11:08:17 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 13DC9416F1F; Mon, 13 Feb 2012 11:08:16 -0500 (EST)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 13 Feb 2012 11:07:53 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Roni Even <ron.even.tlv@gmail.com>, "clue@ietf.org" <clue@ietf.org>
Date: Mon, 13 Feb 2012 11:08:13 -0500
Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0
Thread-Index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQ
Message-ID: <C3759687E4991243A1A0BD44EAC823034DD493CBC2@BE235.mail.lan>
References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com>
In-Reply-To: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034DD493CBC2BE235maillan_"
MIME-Version: 1.0
Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 16:08:20 -0000

Hi, Roni -

I don't think my draft discusses "codec information" at all, at least as I understand the term, so I'm not sure quite what you mean by it.

As for BUNDLE, I think it'll emerge that it doesn't work or scale well for complicated cases (e.g., cases where you have many potential captures, or where a source moves between captures, or where a single source could be sent for more than one capture simultaneously).

Also, to avoid confusion, when you say "stream," what do you mean?  The term (unfortunately) means very different things in SDP and in RTP - in the former case, it's the thing identified by an m= line (and thus, pre-BUNDLE, a transport flow), whereas in the latter case, it's the thing identified by an SSRC.  So I'm not quite sure what your draft, and this e-mail, is discussing.

-
Jonathan Lennox
jonathan@vidyo.com

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Monday, February 13, 2012 6:21 AM
To: clue@ietf.org
Subject: [clue] comment on draft-lennox-clue-rtp-usage-0

Hi,
My view is that there are two separate problems that the draft discusses:


1.       The co-relation between the media capture and the codec information in the offer answer

2.       Multiplexing multiple media streams.

I think that the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00
As for the mapping I have a proposal to use a capture set group in the SDP for the ampping
Roni

v2.23.0 | Report a Bug | By Email