Re: Additional requirement - audio-only communication

On 8/25/2011 11:55 AM, Matthew Kaufman wrote:

> On 8/24/2011 4:36 AM, Harald Alvestrand wrote:

Re: negotiate offer/answer separately in each direction


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

Ok, so that's a bad web-app - don't use it.


Are you really suggesting "send video to someone who doesn't want it anyways"?


"perceived gains" - sending me video at (say) 500K or more plus audio at<50K,
when I'm on a 128K link will kill my connection until I can somehow get the
other side to back off.  Horrid user experience.  Remember people without
broadband or with limited broadband will be using this.  What if I have 768
down, 128 up - but Johnny in the his bedroom is watching youtube videos or
downloading torrents, etc?


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

In what way is that use-case blocked by offer-answer?  Access to the video
needs user confirmation; access to capabilities info shouldn't.  And so the
page can generate an offer with audio and video, or just audio if they have
no camera.  A user declining to send video doesn't necessarily mean you
don't negotiate it - they advertise receive-only for video (if the web app
wants to).


You state above there are major possibilities blocked by offer-answer (I can
think of some minor issues that with O-A require a second O-A pass) - can you
detail some use-cases so we can see the benefit and not just the assertion?
Then we could balance that against the advantage of O-A being well-speced and
known and implemented.  (And the issues surrounding how well and how
interoperably web-app developers can implement their own capability
negotiations/etc)


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 25 August 2011 16:27:26 UTC