Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

Cullen Jennings <fluffy@iii.ca> Sat, 08 June 2013 04:11 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDAF21E804B for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 21:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 pd4b6nEFlH0Z for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 21:11:48 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3021F93D2 for <mmusic@ietf.org>; Fri, 7 Jun 2013 21:11:38 -0700 (PDT)
Received: from [10.70.232.148] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9891922E1FA; Sat, 8 Jun 2013 00:11:31 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51B20CD1.5090002@alum.mit.edu>
Date: Sat, 8 Jun 2013 11:11:28 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <51AF6490.1040409@alum.mit.edu> <CD0D36C1-25C5-4222-B37E-D02AE2331E8B@iii.ca> <51B20CD1.5090002@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1503)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jun 2013 04:11:54 -0000

On Jun 7, 2013, at 11:39 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 6/6/13 1:41 AM, Cullen Jennings wrote:
>> 
>> On Jun 5, 2013, at 11:17 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> 
>>>>  And it is likely to receive RTP packets before it receives an answer in some important scenarios.
>>> 
>>> You keep saying that. But is it really true when ICE is used?
>>> Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable.
>> 
>> I'm assuming that some applications will bring up a data channel (using ICE), as soon as the far end starts alerting the user so this will be done by the time the far end users agrees to send media. At that point it would be nice to start sending media with no clipping. That allows all the ICE setup time to disappear from the media clipping latency problem.
>> 
>> I realize lots of applications will not work this way.
> 
> We're mixing apples and oranges here I think.
> 
> In a pure sip environment there probably won't be a data channel, except for CLUE. But perhaps CLUE is what we should be considering when we are talking about bundle in a pure sip environment.
> 
> Even webrtc won't always be using a data channel.
> 
> In cases where there is a data channel, I don't know how much data will be exchanged over it before the "alerting" is done and the connection acknowledged. I certainly want that to be very constrained. So I'm not sure what the relevance of the data channel is to this discussion.

I don't think it is constrained. A JS app can bring up the data channel and never alert or get any consent from the end user if there is no camera or microphone involved. People are thinking of using this to do P2PLive  style video distribution among other things. If you go back to my high /  mid / low path slides from a way back, you can see I want to bring up a data channel than use that data channel to pass back and forth any updated offer / answers so that they are direct and don't add extra load to the web server. All of this could happen before any alerting even started.