Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

[Paul Kyzivat <[e-mail]>]

On 5/9/13 11:39 AM, Adam Roach wrote:
> On 5/9/13 10:18, Paul Kyzivat wrote:
>> On 5/8/13 5:18 PM, Adam Roach wrote:
>>>
>>> What I was trying to say above is that the only information you would
>>> need to convey is literally one, two, or three <mediatype,ordinality>
>>> pairs. You don't say what you're planning to do with them, just that you
>>> need them.
>>
>> How is that possibly enough? What codecs and codec parameters/optons?
>> What bandwidth? What bundling options? The list goes on.
>
> I apologize. I must have done a really poor job in the prose in my
> draft, since I clearly didn't communicate the fundamental mechanism that
> I had in mind at all.
>
> Let me try with a ladder diagram to see whether that helps illuminate
> what I'm proposing.
>
>
> Offerer                             Answerer
>     |                                    |
>     |<----------Solicitation-------------|
>     |  (I need 1 new audio 1 new video)  |
>     |                                    |
>     |                                    |
>     |-------------SDP Offer------------->|
>     | (Contains two more m-line sections |
>     | than the current session; one      |
>     | audio, one video. Both recvonly.)  |
>     |                                    |
>     |                                    |
>     |<------------SDP Answer-------------|
>     | (Makes use of the two new m-line   |
>     | sections by populating them with   |
>     | codec parameters, options, ssrc    |
>     | bandwidth, bundling, etc, etc.)    |
>

Yeah, I figured that from the last message. But the answer is 
constrained by the offer. So the answer may only have codecs that are 
listed in the offer.

I guess the offerer can just include everything it is capable of 
supporting. But that would be especially unpleasant if the goal is to 
use payload type demux, because it will use up a bunch of PT numbers.

Also, I guess you presume that the answerer wants to send, not receive. 
But if this were to be used for CLUE, it could well be that the answerer 
wants to receive, and will be using the clue channel to indicate what it 
wants to receive over that m-line.

The bandwidth in the offer is what the offerer wants to receive, but it 
doesn't know the intent of the stream yet, so it doesn't really know 
this. So presumably it would need to put the maximum it can handle. With 
more than one m-line, it could be difficult to apportion bw if there is 
concern about the total. The bandwidth in the answer applies to media 
from offerer to answerer, which is irrelevant if media is assumed to 
only flow the other way.

You also mention bundling. But as currently proposed bundling must be 
proposed in the offer and accepted or rejected in the answer. But the 
offerer won't know what to propose. If there is already a single bundle 
I suppose it could propose that the new m-lines be in that one, and the 
answerer could agree or not. But if there is more than one bundle that 
won't work.

This just goes on and on. To make this work in general is going to 
require sending the moral equivalent of a delta to the last offer.

Token passing to negotiate who is offerer would not have these problems. 
For something to offer up that doesn't require any standardization, that 
would make more sense.

	Thanks,
	Paul