[Webkit-unassigned] [Bug 191907] New: No audio/video between Samsung Internet 7.4 and Safari 12

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191907

            Bug ID: 191907
           Summary: No audio/video between Samsung Internet 7.4 and Safari
                    12
           Product: WebKit
           Version: Safari 12
          Hardware: iPhone / iPad
                OS: iOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: daginge at confrere.com
                CC: youennf at gmail.com

Created attachment 355471

  --> https://bugs.webkit.org/attachment.cgi?id=355471&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181122/d915935c/attachment.html>