Re: Additional requirement - audio-only communication

On 8/24/2011 4:36 AM, Harald Alvestrand wrote:
>
> I think that:
> a) this doesn't make sense - it's a completely new SDP/RTP practice, 
> and we should not depart from established practice without a good 
> reason; it also flies against the "keep the number of RTP sessions as 
> low as we can" conclusion that came out of all the discussions about ICE.
> b) it's not consistent with section 4.1.2 step 7.
>
> I think step 16 of section 4:
> "If connection's ICE started flag is still false, start the 
> PeerConnection ICE Agent and send the initial offer. The initial offer 
> must include a media description for the PeerConnection data UDP media 
> stream, marked as "sendrecv", and for all the streams in localStreams 
> (marked as "sendonly")."
>
> is neither correct nor complete.

I agree that "this doesn't make sense" and it is just yet another reason 
that I think SDP offer-answer is entirely inappropriate for WEBRTC.

The web user agent should do what the web site's HTML and cooperating 
Javascript tell it to do. It should not be engaged in direct negotiation 
with the far end such that the outcome is either indeterminate or even 
unexpected, except where direct negotiation is explicitly required to 
meet a security requirement (the initial ICE handshake to determine that 
it is permitted to send data to that endpoint).

Note that any perceived gains by doing this negotiation (like "what if 
my browser is on a slow connection and only wants to receive audio") are 
immediately negated the moment the site changes the SDP enroute to add 
"wants HD-resolution video" for you.

In addition, because the spec is currently written with offer-answer, a 
wide array of use cases that would be possible if capabilities were 
instead exposed via Javascript become impossible. As an example, it 
should be possible for me as a web site developer to create a page that 
can determine, without prompting you to use your camera, whether or not 
a camera is available and if so what codecs it supports. That way I can 
put "I see you have a high-resolution camera and can encode H.264 
video... click here to call a live agent who can help you find the exact 
replacement part" for users who have that, and not if they don't have a 
codec that works with my call center or a camera with sufficient 
resolution to examine the parts I sell.


Matthew Kaufman

Received on Thursday, 25 August 2011 15:56:40 UTC