Created attachment 355471 [details] dump of iPhone side of call with issue The issue we are seeing is a peer to peer call between Samsung Internet 7.4 on Android 8.0.0 to Safari 12.0 on iOS 12.x/macOS (any version), where the Samsung side can see and hear the Safari side, but the Safari side cannot hear nor see the Samsung side. In addition, when using Safari on macOS, the video is corrupted on the Samsung device (see attached). There is no issue with this on iOS 11. Switching to Chrome on Samsung resolved the issue. We have tested the case on Confrere (https://confrere.com), AppRTC (https://appr.tc) and appear.in (https://pwa.confrere.com) with the same result. Data is as far as we can tell flowing, bytes are received and sent on both sides (see attached dumps and directions to view them below). There are a few differences in the SDP which might point to the error: iOS sends the following config for h264 in the offer: a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f Samsung responds with the following config in the answer: a=fmtp:96 packetization-mode=1;profile-level-id=42e01f Note that profile-level-id is the same, but Samsung does not respond with level-asymmetry-allowed=1. This shouldn't matter in principle, as per the spec: level-asymmetry-allowed: This parameter MAY be used in SDP Offer/ Answer to indicate whether level asymmetry, i.e., sending media encoded at a different level in the offerer-to-answerer direction than the level in the answerer-to-offerer direction, is allowed. The value MAY be equal to either 0 or 1. When the parameter is not present, the value MUST be inferred to be equal to 0. If level-asymmetry-allowed is equal to 0 (or not present) in either the offer or the answer, level asymmetry is not allowed. In this case, the level to use in the direction from the offerer to the answerer MUST be the same as the level to use in the opposite direction. Source: https://tools.ietf.org/html/rfc6185#section-6.1 (see section on level-asymmetry-allowed). However, something in the media pipeline fails. I suspect this might be the same underlying issue as with Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1492038), but in this case video doesn't freeze, it never starts playing, and neither does audio (!?). Attachments: Open the attachments in https://fippo.github.io/webrtc-dump-importer/rtcstats. It will give you a webrtc-internals like view of the call data as it happened in Confrere. The iPhone side has the actual call between the two parties. Look at PC2 to see the event log and graphs. Samsung side only has our loopback relay tests, but I added it as reference as well of a successful connection on the device. The image corruptionissue.jpg contains an image of the corruption bug itself. Sorry for the weird formatting, I had issues transferring the image from our test device.
Created attachment 355472 [details] Samsung side of call, sadly just the loopback test
Created attachment 355473 [details] Image of corruption issue between Samsung and Safari on macOS
<rdar://problem/46255216>
This problem has been fixed with Samsung browser 9.x. It was most likely caused by issues with the new H264 encoder (VCP) in iOS released in iOS 12, as well as Samsung just releasing their own H264 pipeline in Samsung browser 7.x. Asking users to upgrade their Samsung browser seems to be the best course of action right now.
OK, closing issue then. Please reopen if needed.