[Webkit-unassigned] [Bug 239882] New: SDP transceivers bug sending tracks asynchronously between peers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 28 18:45:10 PDT 2022


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

            Bug ID: 239882
           Summary: SDP transceivers bug sending tracks asynchronously
                    between peers
           Product: WebKit
           Version: Safari 15
          Hardware: iPhone / iPad
                OS: iOS 15
            Status: NEW
          Severity: Major
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mlopez at videsk.io
                CC: youennf at gmail.com

> More info in this repo: https://github.com/videsk/safari-webrtc-bug

The context is when trying to send tracks between peers async. That means sending tracks from peer 1 and when complete the signaling process to "stable", sending the tracks to peer 2.

```
new => have-local-offer => stable => have-remote-offer => stable
```

The bug only happens when peer 1 is any browser in any OS except iOS and the second one Safari/Firefox/Chrome on iOS, and send tracks async.


>>> How to reproduce it

1. Get user media with audio and video

2. Create RTCPeerconnection on both peers following the perfect negotiation (https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Perfect_negotiation).

3. Execute "peer1.addTrack(track, cameraStream);"

4. Wait to receive the tracks of peer1 on peer2

5. Add mute/unmute listener to both track "track.addEventListener('mute', event => console.log(event.track.kind, 'muted', event));" and "track.addEventListener('unmute', event => console.log(event.track.kind, 'unmuted', event));"

6. Execute "peer2.addTrack(track, stream);"

7. Expect receive tracks **muted**


Point 7 is where weird things happen. You will receive the tracks as muted, only before transceivers exchange and the direction of RTCRtpSender and RTCRtpReceiver will be "recvonly". After transceivers, the tracks will be changed to unmuted, and both transceivers `RTCRtpTransceiver` will change direction value to "sendrecv", but the tracks are still empty (no audio, no video).

A human-readable example is the case when Alice calls Bob. Previous to Bob answering the call we show a preview of Alice's camera, when Bob answer we send the Bob tracks. That use case could be complex if you don't create a new RTCPeerconnection on Alice and Bob, that means starting the signaling process again, which is inefficient.

-- 
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/20220429/8823d488/attachment-0001.htm>


More information about the webkit-unassigned mailing list