Instead of sending using rfc4733 standard, we use INFO message for all transfers
INFO message was used in older SIP.js version. Although this is not a standard for sending DTMF tones, this has more reliability (once it sent over TCP)
This might reduce occurrences of 1008
This is the same behavior we used to have on older sip.js version code
By doing this we reduce errors when user try to perform join/hangup during an websocket reconnection
This happens because FreeSWITCH is not able to parse the "From" header when it has multiple occurrences of ':'. So user is not able to join audio.
To fix, we now changed the "callerId" to use the base64 value of the user name, instead of directly using user's input (the callerId format keeps being a triple like this: <user_id>-bbbID-<base64_encoded_name>).
Once this callerIdName is encoded at the same point it is generated, there shouldn't be server side effects for changing this value; except for those places where the callerName is retrieved by splitting this triple (such as the voice talking-indicator, as described below).
Updated the talking-indicator to retrieve the username from User's object, instead of retrieving from the one username generated by splitting the callerId triple.
This problem also happens in versions <= 2.2.26.
When user joins audio and for some reason an error (such as 1001, 1002,...), happens, the user is not able to click "Mic" and "Listen Only Buttons"; except if the audio window is closed and oppened again.
Fixed two occurrences where the tryGenerateIceCandidates workaround rejected without an error, which borked the callers error handling
Also put it behind a config flag. This workaround used to be important when Kurento didnt infer prflx candidates properly, but that`s no longer the case. With the flag, we can disable the workaround to see if there`s any visible regression and hopefully remove it down the road
This adds the possibility to configure the SIP Via header to plain WS to allow reverse proxying from WSS to WS, internally, to work around a bug in freeswitch where the WSS stack would get deadlocked due to a still unidentified bug in there that has to do with SSL termination
Although Chrome's default is now unified plan, Chrome <-> FreeSWITCH ICE connection fails for some Chrome installations (specially those running on Windows).
FS ICE fails when Chromes's SDP has "a=mid:<index>" (instead of "a=mid:audio").
This fixes Error 1010 and situations where echo test takes too long.
This fixes#6414 regression, once we do the same older version of SIP.js used to do.
We now use both peer's connectionstatechange and iceconnectionstatechange to monitor ICE state for audio sessions.
The same way we did with old sip.js version, we leave iceconnectionstate trigger audio actions , such as connect, disconnect, reconnect.
We still listen for 'failed' state for connectionstatechange event, because chrome triggers this (tested on 86+).
This should reduce the audio error 1010 ocurrences, once some browsers (specially Chrome/Android) don't trigger connectionstatechangeevent.
This might reduce problems reported in #10708, which still needs more investigation though.
Maps WebSocket's 1006 error to BBB's 1002, the same way it was done with old sip.js version
Set user agent's number of reconnection attempts to the same value as older sip.js version
Changed the maximum attempts of the UserAgent reconnection (this should be changed when binding audio's websocket to meteor's connection state).
Added a log to monitor WS reconnect attempts.
When closing/reloading tab with active microphone, audio exits successfully but a wrong log-error (1005) is shown.
We now process closing/reloading tab the same way we do when user hangup the call.
For some reason (still investigating), using turn/coturn on 443/tcp makes firefox's iceGathering process (during echo test) takes 12+ seconds (tested on webrtc's trickle page with multiple instances).
This was found when testing the current default (15s) on production with a private turn/coturn server on port 443/tcp. For default bbb setup (stun only), echo test still runs fast.
To avoid adding extra delay to iceGathering on this scenario (Firefox + turn on 443/tcp), i am just setting the default value back to the 5s (old default).
So , for those who wants to reduce the 1004 occurrences, increasing the iceGatheringTimeout could help (just be aware this adds delay on the mentioned scenario).
Added a default 'MEDIA' option: iceGatheringTimeout. This option allows admin to set a higher ICE gathering timeout, which can help when getting ICE errors during audio negotiation (eg 1004)
Default value set to 15s (current default is 5s).
Sometimes, when user already joined audio session, RTCPeerConnection may
find new ICE candidates, which triggers 'connected' state for peer's
'onconnectionstatechange' event. When this happens we process this
new state the same way when user is not running an audio session, which
makes html5client popup an annoying 'Audio Connected' message.
The audio keeps working fine, but this can make user think that there's a
connection issue, or the audio is reconnecting, while audio is ok.
When getting disconnected with 1001 ("websocket closed unexpectedly" error) we were creating a new SIP session, therefore a new FreeSWITCH channel.
While reconnecting the socket, instead of closing the SIP session, we keep it alive during reconnection (audio should keep working in the meantime). When reconnected we keep using this same session (avoiding the creation of an extra one).
We also better handle WebSocket error codes from SIP.js.
FF immediately closes websocket when unloading page, so we now to stop user agent when 'beforeunload' event is triggered, to avoid leaving open sessions in FreeSWITCH when user leaves page.
Cursor coordinates are calculated using the presentation SVG object
DOMMatrix. When getting this matrix, some browsers (Firefox at least)
responds it as null if the svg object does not have a visible area.
This adds a check before trying to transform the cursor coordinates
using the matrix inverse so we avoid calling a method from a null object.
If there isn't a DOMMatrix to be used as reference, returns a simple out of
bounds SVGPoint (-1, -1)
Users must return their audio to the main room before joining a different one.
Since the audio transfer and the UI state manager doesn't provide a shortcut for
jumping from a breakout room to another, avoid making this opiton available.
When refusing ("thumbs down" button) echo test, user is able to select a different input device. This should work fine for chrome, firefox and safari (once user grants permission when asked by html5client).
For output devices, we depend on setSinkId function, which is enabled by default on current chrome release (2020) but not in Firefox (user needs to enable "setSinkId in about:config page). This implementation is listed as (?) in MDN.
In other words, output device selection should work out of the box for chrome, only.
When selecting an outputDevice, all alert sounds (hangup, screenshare , polling, etc) also goes to the same output device.
This solves #10592
Current sessionDescriptionHandlerModifiers of SIP.js acts before ICE gathering is done. This means we are not able to modify/strip candidates in local SDP.
This modifier acts on local SDP, by allowing user to modify SDP before it is sent on INVITE message.
This considerably changes the way we process audio signaling and start audio elements in user's browser.
We now avoid using AudioContext element for both microphone and listenonly calls, once it is unstable for some iOS devices (cracky audio, user stops hearing audio after a while).
Increased default value for listenOnlyCallTimeout: this avoids activating FreeSWITCH's fallback when ICE negotiation takes longer than 15sec (tested on DO).
Increased listenonly logs.
This fixes#8133#10388
If an ejected user tries to enter in the meeting using the current url
html5 client keep trying to validate that user, but without success
causing a validateAuthToken message spam until the connection times out.
The mic mute is done client side via the track`s enabled flag, which generates silent when false. This still tracks the server/freeswitch mute state, so server-side mutes will be reproduced in the client
We noticed that the mute action button wasn't being consistent when
using muteOnStart as meeting configuration.
Included the addition of the voice user object to the collection as
an event to also be observed.
