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

[Harald Alvestrand <[e-mail]>]

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.