Re: [rtcweb] ROAP Example Application

[Matthew Kaufman <[e-mail]>]

On 10/21/11 8:25 PM, Randell Jesup wrote:
> On 10/21/2011 9:12 PM, Hadriel Kaplan wrote:
>> I think what you're getting at is: if we threw out SDP and 
>> re-designed how/what devices indicated/negotiated media-plan stuff, 
>> we wouldn't end up with SDP again - neither in syntax nor semantics 
>> nor even architecture, as we'd likely separate the higher-layer info 
>> portion, transport portion, and the pure codec-type negotiation stuff 
>> into separate components; and we'd probably move the codec 
>> negotiation into the media-path itself potentially, for example.  Is 
>> that what you mean?
>
>
> Actually, I think Matthew is thinking of something else entirely 
> (though you're right that SDP is not what we'd do with a clean piece 
> of paper - but that would be a multi-year effort, and in the end 
> unless there was a major driving adopter, it would fall by the wayside 
> like SDP-ng (and for that matter, cap-neg)).

Yes, I was thinking of something other than re-creating SDP.

>
>> I don't disagree with that, and it's been raised many times in the 
>> SIP-related working groups over the years.  We know SDP isn't "clean" 
>> in terms of either syntax or semantics, but obviously in the SIP 
>> world it was way too late to change, and folks now use the info all 
>> being together in the SIP signaling-plane to their advantage.
>>
>> I think though you can sort of emulate the separation in RTCWeb, even 
>> with the SDP offer/answer and ROAP.  You create a MediaStream with a 
>> track of "data" type, put it in a PeerConnection, and issue the SDP 
>> Offer.  Then when the data connection is open to the peer 
>> Browser/device, you create your audio/video tracks/streams and add 
>> them in, and when the new Offer is issued by the Browser you send the 
>> ROAP over the data connection to the peer, who does likewise for the 
>> Answer.  That might work.
>
>
> This isn't what Matthew was thinking of - he wanted to know if with 
> these tools, it would ease negotiating codecs that didn't exist when 
> the web-app was written (especially with a low-level API to the 
> browser and its codecs).

Approximately yes. What I want to know is, with the tools we have (SDP), 
would it be possible to solve the negotiate-a-codec-that-didn't-exist 
problem while *NOT* impacting the underlying transport... and, 
separately, would it be possible to solve the 
negotiate-a-transport-session problem while *NOT* impacting the codec 
selection.

My original thought experiment from October 21st has, to date, not been 
addressed by anyone other than myself I'm afraid.

Matthew Kaufman


>
>> -hadriel
>>
>>
>> On Oct 21, 2011, at 7:32 PM, Matthew Kaufman wrote:
>>
>>> On 10/21/2011 12:01 PM, Ted Hardie wrote:
>>>> On Fri, Oct 21, 2011 at 10:37 AM, Matthew 
>>>> Kaufman<[e-mail]>  wrote:
>>>> Thought experiment:
>>>>
>>>> If one had a connection object that supported an underlying 
>>>> protocol that could send one or more encrypted flows of both 
>>>> real-time media and reliable data, what information would you need 
>>>> to exchange between the two browser endpoints in order to ensure 
>>>> that any pair of browsers with any future audio or video codec 
>>>> could use the best mutually-supported codecs?
>>>>
>>>>
>>>> I think I am missing your point slightly.  Do you mean the 
>>>> connection object talks to an abstraction layer that manages how 
>>>> the flows are sent, and the swapping occurs in what it manages, or 
>>>> do you mean the connection object should be able to swap out 
>>>> whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP 
>>>> transparently?  or something else?
>>> I mean "what if the connection object was sitting on top of 
>>> something like RTMFP", in other words a protocol that can trivially 
>>> be asked to open a secure (encrypted and authenticated) 
>>> NAT-traversing session between your browser and another browser and 
>>> then can deliver multiple parallel flows of partially-reliable media 
>>> and fully-reliable data (prioritized appropriately)  to the far end.
>>>
>>> Then the next question I asked is, IF you had a connection object 
>>> like that, what is the minimum you need to get the 
>>> latest-and-greatest-codec-just-works behavior that Cullen, et. al. 
>>> have described?
>>>
>>> Matthew Kaufman
>>>
>
>