RTCOfferOptions in Chrome M51

[Giorgos Rassias]

Hi guys,

I've been playing lately with different call scenarios between two peers (trying to emulate a Skype-like experience), when I came across a strange behavior regarding the createOffer() call. I know it should be possible for the initiator to receive both video and audio from a remote peer, even if the former (who actually called createOffer()) only allowed audio when he made his request via getUserMedia(). This should be taken care of by simply supplying a RTCOfferOptions object:

pc.createOffer({offerToReceiveAudio: 1, offerToReceiveVideo: 1}).

     then(). ...

Instead, the produced offer looks like the attached photo (webrtc-internals-1.jpg) and the values of offerToReceiveAudio and offerToReceiveVideo stay equal to -1. The initiator is able to get only an audio stream from the remote party, even when the latter requests both audio/video via getUserMedia(). The same regarding the offerToReceiveAudio and offerToReceiveVideo values happens when the initiator opts for both audio and video and then calls createOffer() (see webrtc-internals-2.jpg), but, in this case, the resulting connection is successfully established because the offer contained both audio and video info. 

Shouldn't it be possible with the above code to create an offer that specifically asks to receive video data without sharing it - at least until now? I saw that the latest WebRTC draft and the MDN page don't mention anymore these two options in their definition of RTCOfferOptions dictionary. Does it mean they've become deprecated in latest Chrome versions? In that case, is there a workaround to provide the functionality described above?

Tested both in Chrome 51.0.2704.84m (64-bit) and Chrome Canary 53.0.2764.0 (64-bit).

Thanks in advance,

Giorgos

[Philipp Hancke]

I can reproduce that :-(

var pc = new webkitRTCPeerConnection(null);

pc.createOffer({offerToReceiveAudio: 1, offerToReceiveVideo: 1}).then(function(offer) { console.log(offer.sdp); })

yields an offer without m-lines. It looks like the native promise support that comes with M51 does something wrong. Can you file a bug over at crbug.com please?

Until that is fixed try https://github.com/webrtc/adapter -- it enables you to write promise-based code that works (in this case by not using the native promises yet).

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/34dbd60c-1bb8-41d6-a0ab-e97a2fe2a88a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Taylor Brandstetter]

It looks like the promise version of this method only reads "iceRestart" and "voiceActivityDetection", setting offerToReceiveAudio/Video to -1.

Maybe this is because they were removed from the WebRTC draft, in favor of using addTransceiver. However, Chrome is still a long ways away from supporting addTransceiver. In the meantime, it makes sense to me to continue supporting offerToReceiveAudio/Video.

hta@, thoughts?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKi%2B_4mxK0fjWa5hAOOfGms2wsREnvoZOEda_Yq2obQDtMA%40mail.gmail.com.

[Harald Alvestrand]

Yes, existing code should work. This piece is complex due to supporting multiple variations. Thanks for the repro!

[Giorgos Rassias]

Thanks to all of you for your quick responses. Unfortunately, the use of webrtc-adapter doesn't make a difference - at least in latest Chrome versions (>= 51). For the time being, the solution is to use the non-promise createOffer, which seems to be still supported. That is: 

createOffer(offer=>{...}, err=>{...}, {offerToReceiveAudio:1, offerToReceiveVideo:1}).

I hope this issue with the promise-based version will be resolved before the legacy implementation gets removed. Should I proceed with filling a bug just in case?

[Philipp Hancke]

2016-06-11 9:59 GMT+02:00 Giorgos Rassias <geora...@gmail.com>:

Thanks to all of you for your quick responses. Unfortunately, the use of webrtc-adapter doesn't make a difference - at least in latest Chrome versions (>= 51). For the time being, the solution is to use the non-promise createOffer, which seems to be still supported. That is: 

createOffer(offer=>{...}, err=>{...}, {offerToReceiveAudio:1, offerToReceiveVideo:1}).

ah... this still works on https://webrtc.github.io/samples/ but that uses a slightly outdated version of adapter.js.

I made a PR for adapter which disables the native createOffer/createAnswer for now: https://github.com/webrtc/adapter/pull/329 -- will probably hit the road on monday.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3ace53b1-5d6e-461a-b186-a15d879d8297%40googlegroups.com.

[Harald Alvestrand]

Yes, file a bug. That makes it easier to track.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3ace53b1-5d6e-461a-b186-a15d879d8297%40googlegroups.com.

[Giorgos Rassias]

Bug has been filled: https://bugs.chromium.org/p/chromium/issues/detail?id=619289.

@Philipp @Taylor, thx for making clear the exact nature of this issue.

Best regards,

Giorgos