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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 09 June 2013 17:03 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C026121F826B for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 10:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.397
X-Spam-Level:
X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 ShKkORnwACIs for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 10:03:35 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6576E21F8613 for <mmusic@ietf.org>; Sun, 9 Jun 2013 10:03:33 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id mGyQ1l0030vyq2s55H3ZC6; Sun, 09 Jun 2013 17:03:33 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id mH3Y1l0143ZTu2S3RH3Y72; Sun, 09 Jun 2013 17:03:33 +0000
Message-ID: <51B4B564.5050503@alum.mit.edu>
Date: Sun, 09 Jun 2013 13:03:32 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <fluffy@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> <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca>
In-Reply-To: <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370797413; bh=F/MF6aNity7Led8tSVNW/MnIdXF0CHsBdPbo7cE2wyo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NyY8sXT4e/ZVHoCnP/uh9PZ9TWvF8Ix4zReDkiGSAhpPWASN8OcgkNthPW1ezVIES txWJcydX9wdJMAC04DBoKevlxI23rthrY+okkCXbU8o7w3p9My0gj4zgKdjUwcyWOJ NHo5KBMYfpQfLrzfMqB/O7beYuLZGVgDX9QgtKkrO0hVnH2Mx1GUooNFyfprxf/41e ko1KZVNds92VApgqn3cn3aP7nE3EnkIehkcS6P+AXfYk3RoEDF0VjF7Eh5OW62DXsW qbA67cEzwyhFu9JOJfSELRRdrw4nhLVtGIeWuUv9+l5cbrUFocz9xiNOFEEm6n+GsM QdeD1vaIwT91A==
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: Sun, 09 Jun 2013 17:03:40 -0000

On 6/8/13 12:11 AM, Cullen Jennings wrote:
>
> 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.

I agree its not technically constrained.

But still I think the app needs to be circumspect in the sort of data it 
passes prior to getting some sort of confirmation from the user.

Stuff that is just used to finish setup of communication is probably 
innocuous. But even that ought to be subject to policy control.
I may wish to appear unavailable until I answer the alert.

	Thanks,
	Paul