This is a rework of the audio join procedure whithout the explict listen
only separation in mind. It's supposed to be used in conjunction with
the transparent listen only feature so that the distinction between
modes is seamless with minimal server-side impact. An abridged list of
changes:
- Let the user pick no input device when joining microphone while
allowing them to set an input device on the fly later on
- Give the user the option to join audio with no input device whenever
we fail to obtain input devices, with the option to try re-enabling
them on the fly later on
- Add the option to open the audio settings modal (echo test et al)
via the in-call device selection chevron
- Rework the SFU audio bridge and its services to support
adding/removing tracks on the fly without renegotiation
- Rework the SFU audio bridge and its services to support a new peer
role called "passive-sendrecv". That role is used by dupled peers
that have no active input source on start, but might have one later
on.
- Remove stale PermissionsOverlay component from the audio modal
- Rework how permission errors are detected using the Permissions API
- Rework the local echo test so that it uses a separate media tag
rather than the remote
- Add new, separate dialplans that mute/hold FreeSWITCH channels on
hold based on UA strings. This is orchestrated server-side via
webrtc-sfu and akka-apps. The basic difference here is that channels
now join in their desired state rather than waiting for client side
observers to sync the state up. It also mitigates transparent listen
only performance edge cases on multiple audio channels joining at
the same time.
The old, decoupled listen only mode is still present in code while we
validate this new approach. To test this, transparentListenOnly
must be enabled and listen only mode must be disable on audio join so
that the user skips straight through microphone join.
Providing just "120" as a jitterbuffer is not a good idea, because it just specifies the initial size of the jitter buffer. We changed it to "100:250" which uses 100ms jitterbuffer as a default, but 250ms as a maximum jitterbuffer size. This is big enough even for bad internet connections. However it is also small enough to always provide minimum delay.
Providing just "120" as a jitterbuffer is not a good idea, because it just specifies the initial size of the jitter buffer. We changed it to "100:250" which uses 100ms jitterbuffer as a default, but 250ms as a maximum jitterbuffer size. This is big enough even for bad internet connections. However it is also small enough to always provide minimum delay.
Use the presence_data field to annotate channels with a filterable
identifier that allows us to differentiate SIP.js channels from SFU
ones.
The motivation: allow metrics exporters/instrumentations/etc to
generate comparison metrics (eg.: mediaStats, usage) between the default
bridge and the experimental one without having to do multiple or overly
verbose json_api or mod_command/fs_cli calls to filter channels out.
This new dialplan rule filters calls originating from bbb-webrtc-sfu via SIP
user agent parsing. The default bbb-webrtc-sfu UA is "bbb-webrtc-sfu".
A new dialplan rule is needed to force RTP auto-adjustment for calls originating
in bbb-webrtc-sfu (rtp_manual_bugs=ACCEPT_ANY_PACKETS).
That is due to the fact that bidirectional mediasoup bridging is done via an
RTP/AVPF endpoint which does not use ICE. FreeSWITCH arbitrarily blocks off auto
adjustment for AVPF profiles (presuming ICE), so it needs to be forced otherwise
the bridge won't work properly in all environments.
Bridging mediasoup and FS via WebRTC (which would circumvent that) is currently
not an option due to the fact that FreeSWITCH doesn't handle STUN role conflicts
properly (and there will always be a conflict since the initiator is controlled
and FS always defaults to controlled)
Briding mediasoup and FS via plain RTP/AVP (which would also circumvent that) is
not an option right now due to the fact that FreeSWITCH doesn't make ssrcs
public in signaling for RTP/AVP profiles. mediasoup needs the remote ssrcs.
This could work by pre-generating a ssrc in bbb-webrtc-sfu, signaling it via a
SIP header and then specifying it in the rtp_use_ssrc channel variable in FS,
which would allow us to shim the ssrc in FS's answer in bbb-webrtc-sfu.
Maybe in the future.
- switch SIP ports in vars.xml:
- Internal to port 5090 from port 5060. 5060 is assigned to external sip profile
as bbb-voice only connects to 5060. Tried fixing bbb-voice but can't figure it out.
- Use 5090 instead of 5080 since 5080 is used by Red5.
