W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: No-channel vs some-channel initial offers (Re: Proposal: offerDataChannel in RTCOfferOptions)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 18 May 2015 07:32:24 +0200
Message-ID: <55597968.6090700@alvestrand.no>
To: public-webrtc@w3.org
Den 17. mai 2015 23:40, skrev Cullen Jennings:
> 
> I think it is better to let the JS control what happens instead of magically doing something different than what the JS requested. If the app is one where there can be no a/v in offer, that app can easily add a data channel if that helps. 
> 
> I agree it is odd, but I it is an odd app that does this. I can't think of any use case that would need this. 
> 

I actually found a second case that would have the same odd result in
Firefox:

A sends offer(offerToReceiveVideo)
B sends answer, but adds no tracks.

This leads to an a=inactive m-section, and no candidates being exchanged
- one has to watch the ICE state go to "failed" in order to figure out
that something wrong has happened.

As an user, I found both cases surprising: That negotiation success led
to connection failure when there was no network problem.
Received on Monday, 18 May 2015 05:32:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC