Verto JS libs allow passing an attachStreams array of MediaStream objects, which are then supposed to be added to the peer connection in the order they are supplied in the array.
However, there is a faulty logic check prior to actually adding the streams, where 'options.attachStream' is checked for length instead of 'options.attachStreams'.
addStream() is a deprecated WebRTC API method, and only works via shimming on some platforms. Internally, it is inconsistent in building an offer SDP in the order which FreeSWITCH expects it, which is audio m-lines first.
This can result in intermittent m-line ordering errors on the client.
Instead addTrack() can be used to force the media tracks to be added to the peer in the order FreeSWITCH expects.
* commit '71599a8552363d1fee1be2f4e3e1e80983d55f0b':
FS-11591 [verto_communicator] update adapter.js to prevent safari error due to undefined constraints
Chrome is beginning to default their SDP semantics to the WebRTC standard
'Unified Plan', and Verto does not currently construct its SDP according
to this standard. For now, force the browser to use 'Plan B' semantics.
The verto.clientReady event calls the onMessage callback function passed in
the Verto object. We should check for the existence of this callback function
before trying to call it.
The Verto libs currently have total control over the streams associated with
placing any kind of call, handling both their creation and teardown
automatically.
This patch provides the option for a developer to instead pass pre-created
MediaStream objects when instantiating the Verto object, or when calling
Verto.newCall(), and the library will bypass the work of creating those
streams, and of destroying those streams when the call is torn down.
This is particularly useful if the application wants to manage its own streams,
such as re-using them in other non-Verto aspects of the application.
The patch also creates some internal convenience functions for managing the
video element related to a local video stream.
This patch adds an onRemoteStream callback, which can be specified on the Verto
instance, or per dialog. The callback is fired when the remote stream from a
call is received, and receives two arguments, the first is the remote stream,
the second is the Verto dialog object.
As described at https://bugs.chromium.org/p/chromium/issues/detail?id=862325,
some Android devices using Chrome fail a getUserMedia() request when
frameRate.min is specified.
This is due to a bug in both the device (reporting a 0 min frameRate), and
Chrome, which fails to catch this and set a reasonable fallback value.
While a fix has gone into Chrome, it might be awhile before this fix makes it
into their stable release, so filing this with my quick hack to prevent the
error on Android devices.
Note this fix could certainly be more robust (maybe detect Chrome version, or
some test to see if min frameRate from the device returns 0), and it gets the
job done as a start.
getMediaParams() was using a legacy version of the video constraint param to
specify a deviceId.
checkRes() was incorrectly setting video constraints such that it was not
properly testing specific video devices.
$.verto.unloadJobs queue leverages the 'beforeunload' event to perform work
prior to browser page unload.
However, iOS does not support that event. Its equivalent event is 'pagehide'.
This patch uses the pagehide event on iOS, and beforeunload for all others.
iOS requires a 'playsinline' attribute to be added to video tags, however a
'controls' attribute was erroneously added, and is unneeded.
See https://github.com/webrtc/samples/issues/929#issuecomment-330816567 and
following comments for confirmation.
Removing this attribute reduces UI noise and 'click contention' on video
elements.
Verto.newCall() permits passing custom callback functions per call that
override the default dialog callbacks inherited from the Verto object.
However, they are currently set after calling the invite() function, and it's
possible that some of these callbacks could be called during the invite()
function's execution.
To avoid a race condition, move setting these custom callbacks on the dialog
to happen before calling invite().
Currently the 'permissionCallback' object is only available at the Verto
instance level. This is problematic in multi-call scenarios, where an
individual call dialog needs access to the onGranted/onDenied callback
functions.
The patch adds a check for existence of onGranted/onDenied callback functions
at the dialog level, with a fallback to the original behavior of calling
onGranted/onDenied from the Verto instance if it's not available on the dialog.
This preserves backwards compatibility while allowing per-dialog overrides
going forward.
Assigning the speedTest callback funtion to a local variable and unsetting
the this.speedCB instance variable prior to calling the callback function
allows the rpcClient.speedTest functionality to be used more creatively
(such as calling it recursively for multiple runs) without affecting existing
functionality.
Mike Jerris