|
8 yıl önce | |
---|---|---|
.. | ||
README.md | 7 yıl önce | |
RTCPeerConnection.js | 7 yıl önce | |
RTCSessionDescription.js | 7 yıl önce | |
errors.js | 8 yıl önce | |
utils.js | 7 yıl önce |
The modules/RTC/ortc
folder contains a RTCPeerConnection
shim for Edge based on ORTC among with other shims (such as RTCSessionDescription
) and some utilities/helpers to deal with both, SDP and ORTC objects.
ortc
folderExports a RTCPeerConnection
shim. The interface is based on the W3C specification of 2015, which matches (mostly) the current implementation of Chrome.
It also implements Plan-B for multi-stream.
rtcp-mux
is assumed (not a real problem nowadays).createOffer()
is not implemented, so P2P mode is not supported (RTCBrowserType.isP2PSupported()
returns false
).setRemoteDescription()
with a SDP answer with mangled SSRC values is currently unsupported (those new SSRC values will not be used for sending media).createAnswer()
, mangles SSRC values, and applies by calling setLocalDescription()
, those new SSRC values are currently ignored.maxFramerate
per encoding but it does not support maxBitrate
, resolutionScale
or framerateScale
, so it’s not worth it).RTCDataChannel
not supported (Edge does not implement it).addIceCandidate()
not supported (it’s never called anyway, at least in non P2P mode). Edge does not support Trickle-ICE which means that, after reading all the remote ICE candidates from the remote SDP and applying them, an “empty” candidate must be immediately applied (otherwise the RTCIceTransport
never enters the “completed” state) and, after that, new remote candidates cannot be added.Exports a RTCSessionDescription
shim.
The interface is the same as in the WebRTC specification (although internally it also handles a Object representation of the SDP generated by the sdp-transform library).
Exports some Error
based classes needed in WebRTC (such as InvalidStateError
).
Some utilities related to SDP and ORTC.
Randomly, ICE Binding Requests from Edge are replied with WRONG MESSAGE-INTEGRITY error by the bridge. It seems that Edge, sometimes, adds a extra byte in the USERNAME
attribute producing such an issue.
When VP8 rewriting is enabled in the bridge, VP8 video produced by Edge is wrongly rendered in Chrome/Firefox.
Randomly, sending a new track or receiving a new track fails with InvalidStateError
. The issue reported in Edge tracker includes a way to reproduce it.
As per conversations with Edge developers, it seems that Edge has some kind of limitation in the number of VP8 streams it can encode/decode at the same time. However, in my tests I’ve been able to send a VP8 stream and receive 5 VP8 streams at the same time.
The problem happens much more often when calling rtpSender.stop()
or rtpReceiver.stop()
and then creating a new RtpSender
or RtpReceiver
and calling send()
or receive()
on it.
WebRTC stats produced by Edge don’t provide enough information to determine resolution, framerate or bitrate.
In Edge, the device selector UI shows grayed drop down lists for mic and webcam.
Those issues/bugs in Edge do not affect lib-jitsi-meet because the code avoids them. However, for future changes, it’s important to consider them:
RtpReceiver.track
returns a different MediaStreamTrack
every time: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12399497/