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

[Paul Kyzivat <[e-mail]>]

On 5/10/13 12:54 PM, Cullen Jennings wrote:
>
> On May 9, 2013, at 8:21 PM, Paul Kyzivat <[e-mail]> wrote:
>
>> 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
>
> it seem to me that we all the same problems in the initial offer. The whole idea of an Offer/Answer is the offer has more or less has everything you support or are willing to do so I don't really see that being a big problem here.

The existing O/A only works reasonably when variations from the norm are 
small. As long as it was just codecs on a single audio m-line it wasn't 
a big deal. Add one video m-line and it still has a reasonable chance of 
working.

But in a case like CLUE, where each side has a mass of things available 
to send it doesn't work well at all. And some of the rtcweb cases have a 
lot of similarity to that.

But this particular discussion is a little silly, because passing an 
"offer token" around doesn't have any of these problems.

	Thanks,
	Paul