Re: [rtcweb] Additional requirement - audio-only communication

[Dzonatas Sol <[e-mail]>]

On 08/25/2011 09:24 AM, Randell Jesup wrote:
> 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"?


"Streaming ads" already exist, so there is this more common usage.


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



If we redirect the discussion back to web-browsers (and not composition 
over the network) then we can merely point out the activity of multiple 
tabs, or why should each tab have equal bandwidth, and why should tabs 
not actively-viewed have more bandwidth than those actively viewed.

Magic solution would be uPNP negotiates frame rate.


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


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant