[rtcweb] Combining attributes (Re: Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt)

Harald Alvestrand <harald@alvestrand.no> Fri, 12 August 2011 15:23 UTC

Return-Path: <harald@alvestrand.no>
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 6C59621F8A4D for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.468
X-Spam-Level:
X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, 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 cEy+gMM1Qk-D for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:23:32 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 788EA21F88A5 for <rtcweb@ietf.org>; Fri, 12 Aug 2011 08:23:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CEEF639E148; Fri, 12 Aug 2011 17:22:57 +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 BrLW6Ll7ILLC; Fri, 12 Aug 2011 17:22:57 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0318B39E091; Fri, 12 Aug 2011 17:22:56 +0200 (CEST)
Message-ID: <4E454598.2010907@alvestrand.no>
Date: Fri, 12 Aug 2011 17:24:08 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <4E43BDB3.8000504@alvestrand.no> <4E4423A7.2000501@alum.mit.edu> <4E44CC15.3030004@alvestrand.no> <4E453EE9.7030102@alum.mit.edu>
In-Reply-To: <4E453EE9.7030102@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: [rtcweb] Combining attributes (Re: Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt)
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: Fri, 12 Aug 2011 15:23:33 -0000

On 08/12/11 16:55, Paul Kyzivat wrote:
> On 8/12/11 2:45 AM, Harald Alvestrand wrote:
>> On 08/11/11 20:47, Paul Kyzivat wrote:
>>> On 8/11/11 7:32 AM, Harald Alvestrand wrote:
>>>
>>
>>> 2) The draft only shows this mechanism being used to combine one audio
>>> and one video. Do you also imagine it being used to represent multiple
>>> audio and/or multiple video streams that might otherwise be handled
>>> independently? (I see no reason why it couldn't be used that way.)
>>> This would allow description of different properties for each one.
>> I certainly think that any number of m= sections could be combined this
>> way, but in other discussions, I've seen people tend towards thinking of
>> sections as "one m= section for all the audio channels, one m= section
>> for all the video channels". Can you give an example of the usage you're
>> thinking of?
>
> If there was an intent to have multiple streams with different 
> properties, then this would provide a way to describe those, that 
> isn't otherwise available. For instance, if you wanted one hi-res 
> video stream and one low-res video stream.
>
> I'm also thinking ahead to what might be coming from CLUE 
> (telepresence). It isn't far enough along to yet be able to predict 
> how it will set up its multi-stream calls, but it will probably want 
> to multiplex them over a lesser number of RTP streams. And so I'm 
> shopping for potential mechanisms that might be exploited there.
>
>> I'm worried that we may get too many special rules about how parameters
>> from sections are to be combined - multiple codecs with different PT
>> numbers are fine, but other parameters could be confusing, so I'd like
>> to see examples.
>
> Maybe its premature. But no matter what, rules will need to be written 
> on how attributes are combined. So IMO its worthwhile to at least 
> start thinking about how to write those in general, rather than 
> writing a few special case hacks. It may turn out that the rules that 
> are to be followed for combining one audio and one video will also 
> "just work" for combining two audio or two video, etc.
That's why I'm urging you to come up with concrete examples; I think 
it's easier to work out the general principles when we have worked 
through more than one example.

At the moment we have the "ICE way" (take the first), the "bandwidth 
way" (add the numbers), and the "codec way" (use them all, but require 
that they don't conflict).

If you have a good example-from-real-life of an SDP offer where you 
would like to use TOGETHER, let's see whether there are more cases.