Re: [rtcweb] ROAP Example Application

[Randell Jesup <[e-mail]>]

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)).

> 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).

What you describe is simply a way for the JS App to do "renegotiations" 
without using the "high path" through the servers.  Eminently doable, 
but not fundamentally different.  It may make renegotiations faster.  No 
reason an app can't do that, and I have some services built on WebRTC in 
mind that may depend on this usage.

> -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
>>


-- 
Randell Jesup
[e-mail]