WebRTC is not working connecting Safari with Chrome for Android about webrtc-web HOT 28 OPEN

FYI: https://bugs.chromium.org/p/chromium/issues/detail?id=793038
I believe things should improve starting on Chrome Android 65 (now Canary)

from webrtc-web.

@alvestrand much of the pain is caused by not fixing https://bugs.chromium.org/p/webrtc/issues/detail?id=4957 ... I am interested in hearing why this is a P3.

The other issue is profile levels which is described in https://bugs.chromium.org/p/webrtc/issues/detail?id=8584

from webrtc-web.

Thanks for your quick response @hermanfransen. Appreciate it!

from webrtc-web.

Thanks @hermanfransen — looking into this now.

from webrtc-web.

These are scenarios that should be tested by Kite - https://github.com/webrtc/kite
@agouaillard - is this consistent with your tests, alternatively is there material here for better tests?

from webrtc-web.

One obvious problem with the offer cited is that it only offers VP8 and VP9 video.
I believe Apple/Safari still hasn't implemented that part of the spec that mandates VP8; it's H.264 only.

from webrtc-web.

I've fixed the communication between Chrome and Safari by adding "playsinline" inside < video > and changing the methods "handleRemoteStreamAdded(event)" and "gotStream(stream)"

<div id="videos">
  <video id="localVideo" autoplay muted playsinline></video>
  <video id="remoteVideo" autoplay playsinline></video>
</div>

function handleRemoteStreamAdded(event) {
    console.log('Remote stream added.');
    try{
        remoteVideo.srcObject = event.stream;
    }catch (error){
        remoteVideo.src = window.URL.createObjectURL(event.stream);
    }
    remoteStream = event.stream;
}

function gotStream(stream) {
    console.log('Adding local stream.');
    try{
        localVideo.srcObject = stream;
    }catch (error){
        localVideo.src = window.URL.createObjectURL(stream);
    }
    localStream = stream;
    sendMessage('got user media');
    if (isInitiator) {
        maybeStart();
    }
}

from webrtc-web.

I've hosted an example here for testing proposes:
I've commented out these lines like @kekeoki said in the issue #14

// if (location.hostname !== 'localhost') {
//   requestTurn(
//     'https://computeengineondemand.appspot.com/turn?username=41784574&key=4080218913'
//   );
// }

And i've uncommented this line for getting a room name from the user

// var room = 'foo';
// Could prompt for room name:
var room = prompt('Enter room name:');

@hermanfransen you can try it and tell me if it works because i'm not able to test all the cases that you mention. I've tested in these cases:

• Desktop/Chrome <> Desktop/Safari
• Desktop/Chrome <> iPhone/Safari (iPhone SE)

from webrtc-web.

@seiyuricardohiga - Thanks for helping in this issue. I tested the following three cases with your hosted example, but unfortunately your fix didn't solve the problem.

• Android/Tab/Chrome <-> iPad/Safari
• Android/Tab/Chrome <-> iPhone/Safari
• Android/Tab/Chrome <-> Desktop/Safari

It is giving the same error as reported before:

Unhandled Promise Rejection: OperationError (DOM Exception 34): 
Failed to set remote offer sdp: Session error code: ERROR_CONTENT. 
Session error description: Failed to set remote video description send parameters..

I'm pretty sure it has to do with this bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=8584

Since upgrading from iOS 11.1.2 to iOS 11.2.2 the other problem Desktop/Chrome <-> iPhone/Safari is solved. So it is working right now.

Read this and this for the original bug report.

I updated the issue, also Desktop/Chrome <> Desktop/Safari was and is no problem. It's just a problem between Chrome for Android and Safari.

from webrtc-web.

@samdutton @fippo

Conclusion of this Issue:

There seam to be a bug #8584: Chrome Android does not offer/answer H.264 Constrained Baseline Profile.

This is causing Chrome for Android not to connect to Apple Safari. Also because Apple only supports H264.

Is there any workaround for this issue?

from webrtc-web.

Thanks @seiyuricardohiga!

@nitobuendia — we should add the playsinline fix suggested. Could you do a PR at some stage? We should make sure to use only srcObject() throughout, since this is now well supported and URL.createObjectURL() is deprecated.

@hermanfransen

Is there any workaround for this issue?

Not that I'm aware of, but @fippo may well know more.

from webrtc-web.

SDP munging -- I still wonder in what flakes @alvestrand got his magic profile level decoder ring...

from webrtc-web.

@hermanfransen you're right. I'm using video services from tokbox and i didn't realize that they have the same issue here
Now I've tried with Android/Tab/Chrome <-> iPhone/Safari and I think they did a little workaround because everything works fine on Android but i'm not able to receive the video stream on Safari, just audio.

from webrtc-web.

@seiyuricardohiga - In my test it was working. What Android device did you use?

May be you bumped into the second issue?

At present H.264 video codec is limited to Qualcomm (Kitkat and later) and Samsung Exynos (Lollipop and later) chipsets. As there is no software H.264 encoder implementation, only the aforementioned chipsets are supported.

from webrtc-web.

@samdutton On it.

from webrtc-web.

FYI: Another issue with Chrome Android H264 in close relation: https://bugs.chromium.org/p/monorail/issues/detail?id=3424
HW H264 from the device I tested fails to work well with SFUs as the encoder is not inserting SPS (NALU 7) with IDRs (NALU 5) except for the very first IDR. In P2P works because the latter.

from webrtc-web.

I just tested it with Chrome Canary 66.0.3334.0 but still same error I am getting

from webrtc-web.

Hello @hermanfransen , I would like to know if you have any update ? I got same issue. Thanks!

from webrtc-web.

Hi @huynhquocmy , when I reed this the bug is fixed and they say it will probably be merged into Chrome M65.

You should be aware there are two different issues (that are often mixed up) making a WebRTC connection between Chrome on Android and iOS/Safari not working. See here for more info.

from webrtc-web.

is there any new about this? still getting the same issue on version 67

from webrtc-web.

@jlberrocal: I haven't checked since 5 months ago. please help to verify again!

from webrtc-web.

well in fact i have been working this week in a tool for use camera to take a picture and seems that chromium based browsers are failing on android they just display a black screen instead of the stream with no errors on console

from webrtc-web.

This issue seems to exist still even in Canary version 69.

Still getting...

Unhandled Promise Rejection: OperationError (DOM Exception 34): 
Failed to set remote offer sdp: Session error code: ERROR_CONTENT. 
Session error description: Failed to set remote video description send parameters..

On android chrome when using h264.

I've looked into all the sdp mundge options but have not found a resolve for this yet

from webrtc-web.

I am able to run the following example on browsers of Linux computer. But the remote video is not displaying when I run this example between Google-chrome 69 of Window 10(desktop) and Safari of iPad 11.4.1.

It displays only local stream not remote stream. However each user has getting remote stream and when I debug this stream, it has the property muted with true value. While in example-working case, it has value false.

Following is the screen shot of remote media stream when video is not displaying.

Remote Media stream

from webrtc-web.

@bogatisuman got the same thing

from webrtc-web.

Hi, all. I see the samples work on https, and I just deploy on http, the samples works on Android phones, but faile on ios 11. Do the samples need https on ios??

from webrtc-web.

i have same problem Video format not supported, i follow

from webrtc-web.

I am also experiencing similar issue on ios 12/13. I do have added code for onunmute event like

e.track.onunmute = () => { console.log('onunmute called for',e) if (!remoteVideo.srcObject) { remoteVideo.srcObject = e.streams[0]; remoteVideo.setAttribute('playsinline', true); } }

In case this works, the track's muted state is false, and when this doesn't work, even inside the onunmute event the track's muted state is true.

Has anyone found a solution getting the iOS working with more than 3-4 peers?

from webrtc-web.