Subject: Re: [rtcweb] ROAP Example Application

From: Matthew Kaufman <[email-masked]>
Date: Mon, 07 Nov 2011 15:38:45 -0800

(Leaving the trailing included text below in case context must be 
re-established... my travel schedule has precluded answering all threads 
promptly)

On 10/21/11 6: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?

That isn't what I was getting at, but it is also a valid point. We would 
certainly separate the higher layer info, the transport, and the codec 
negotiation into separate components. Whether or not we would change 
where the information flows, I don't know.

But what I was getting at was actually whether or not we could use *what 
we actually have* to build a better-decomposed system, not what we would 
do if we were starting from scratch.
>
> 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.

Exactly, it is "way too late to change", so I'm trying to determine if 
there's a path forward that has at least some of the advantages without 
throwing out the past.

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

The above is only about moving where the message goes to the media plane 
from the signaling plane, and that's not the part that is important.

Matthew Kaufman

>
>
> 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<[email-masked]>  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
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 07 Nov 2011 15:42:39 -0800

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 Fri, Oct 21, 2011 at 10:37 AM, Matthew 
>>>> Kaufman<[email-masked]>  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
>>>
>
>