WebRTC is not working connecting Safari with Chrom

WebRTC is not working connecting Safari with Chrome for Android. From Chrome on Desktop to Safari there is no problem. Also Safari - Safari gives no problems.

Apple is natively supporting WebRTC since iOS 11 and Safari 11 on the desktop.

As a base, I used the code of google codelab where I have a basic video chat app between two browsers. For the test I used both devices within the same WiFi network, just to make sure.

It works WELL in these cases (see specifications devices):

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

It's NOT working in these cases:

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

Specifications of the devices:

Desktop/Chrome
- Macbook MacOS 10.12.6
- Chrome 63.0.3239.132

Desktop/Safari
- Macbook MacOS 10.12.6
- Safari 11.0.2

Android/Tab/Chrome
- Samsung Galaxy Tab3 8.0 inch (SM-T310)
- Android 4.4.2
- Chrome 63.0.3239.111

iPad/Safari
- iPad mini 2 (A1489)
- iOS 11.2.2
- Safari

iPhone/Safari
- iPhone 6 (A1586)
- iOS 11.2.2
- Safari

1) Android/Tab/Chrome <-> iPad/Safari

Android/Tab/Chrome sends an offer, then iPad/Safari receives it, but then giving an error:

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

The sdp offer:

v=0
o=- 7644883235956031763 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:mXxq
a=ice-pwd:T4vRjmDaHYES+J3WJ8NAx65S
a=ice-options:trickle
a=fingerprint:sha-256 B1:36:E3:06:6E:6F:73:59:96:BB:74:95:79:20:64:F6:45:AD:99:1A:43:78:AD:CA:CA:7A:D9:23:2C:D8:C5:07
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1841783350 cname:RdL9LRY2OCXO8jbB
a=ssrc:1841783350 msid:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm e1a0f1a7-66bf-4921-9677-30e5e838ad02
a=ssrc:1841783350 mslabel:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm
a=ssrc:1841783350 label:e1a0f1a7-66bf-4921-9677-30e5e838ad02
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:mXxq
a=ice-pwd:T4vRjmDaHYES+J3WJ8NAx65S
a=ice-options:trickle
a=fingerprint:sha-256 B1:36:E3:06:6E:6F:73:59:96:BB:74:95:79:20:64:F6:45:AD:99:1A:43:78:AD:CA:CA:7A:D9:23:2C:D8:C5:07
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 red/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 ulpfec/90000
a=ssrc-group:FID 659734980 914875391
a=ssrc:659734980 cname:RdL9LRY2OCXO8jbB
a=ssrc:659734980 msid:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm 53ce1350-e2ef-426e-9023-e91e4ea08dc6
a=ssrc:659734980 mslabel:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm
a=ssrc:659734980 label:53ce1350-e2ef-426e-9023-e91e4ea08dc6
a=ssrc:914875391 cname:RdL9LRY2OCXO8jbB
a=ssrc:914875391 msid:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm 53ce1350-e2ef-426e-9023-e91e4ea08dc6
a=ssrc:914875391 mslabel:Yiel2ebiIcKBPDaLuAqKaFpR93Mbz1tSsNRm
a=ssrc:914875391 label:53ce1350-e2ef-426e-9023-e91e4ea08dc6

If iPad/Safari first sends an offer, same error message on the Android/Tab/Chrome.

2) Same error in case

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

Uncaught (in promise) DOMException: Failed to set remote offer sdp: 
Session error code: ERROR_CONTENT. Session error description: 
Failed to set remote video description send parameters..

UPDATE:

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

Read this and this for the original bug report.

回答1:

There are two different issues making a WebRTC connection between Chrome on Android and iOS/Safari not working:

1) No H.264 implementation on device

Chrome for Android has only a hardware implementation for H.264 and there is no software implementation. At this moment H.264 works only with devices with a processor of Qualcomm (Kitkat and later) or Samsung Exynos (Lollipop and later). Since Apple only supports H.264 other Android devices can't connect with iOS and Safari.

2) There is bug in Chrome for Android:

Chrome Android does not offer/answer H.264 Constrained Baseline Profile

Because Apple only supports H.264, Android/Chrome can not connect with iOS at this moment.

This problem will be solved in Chrome Android 65 (now Canary). See this for more information.

In my case the problem was the bug, but I think people should be aware of both problems.

回答2:

There are several issues:

iOS only supports H264 (profile 42e01f)
your offer only contains VP8 & VP9 video codecs which Safari can decode but will not encode (blame politics)
android devices seem to support H264 but with profile 42001f... hence a profile mis-match

The upshot is that you may have to do some SDP-munging in order to get H264 running on all your devices.