Reference14r1:MyApps Plugin for Virtual Desktops
This product is currently in Beta. It is not officially released yet.
Description
A softphone running at a terminal server (Citrix, Windows, ...) has the problem that audio and video streams start and terminate at the server.
Received audio from remote peer at the server must be transmitted to the local client for playback and audio delivered by the audio device must be also transmitted from the local client to the server for transmission to remote peer.
This transmission of the audio stream between server and client adds a delay which makes the communication impossible.
Video suffers from the same limitations.
Innovaphone provides a solution for this problem with the RCC-App but there are still some limitations:
- Admin must configure a Softphone and a RCC-App for the user.
- myApps must be installed at the terminal client for the Softphone App which the RCC-App will control and the user must log in at the terminal client too.
- Configuration of the Softphone (Call-Waiting, Video, ...) happens at the terminal client.
- Management of the audio devices takes place at the terminal client.
- RCC-App does not support video. The Softphone App does. If the user wants video, he starts or receives the call with the RCC-App but he must switch to the Softphone App.
- RCC-App does not support appSharing. User could share a local application with the Softphone App or even the local desktop in order to show the remote desktop.
A new innovaphone product called myApps Plugin is being developed to provide offloading of the media data to the local client and to offer a solution for the limitations of the RCC-App.
Applies To
- innovaphone PBX from version 14r1
Requirements
- innovaphone PBX
- innovaphone myApps V14r1
- innovaphone myApps Plugin V14r1
- Firmware V14r1 final
Concept
The myApps Plugin at the client is in charge of all tasks related to the media streams and the management of the Audio/Video devices. For instance:
- start or stop an audio/video device
- gathering of the ICE candidates
- connect to a remote peer with the ICE protocol
- start a ringing device
- rendering of video
But we now need a way of communicating between the myApps running at the terminal server and the myApps plugin running at the terminal client in order to carry out all these actions.
Main VDI Platforms (Citrix, Windows, WMware) provide a way of communicating between server and client through Virtual Channels:
https://support.citrix.com/article/CTX116890/citrix-ica-virtual-channels-overview
https://learn.microsoft.com/en-us/windows/win32/termserv/using-terminal-services-virtual-channels
Configuration
The myApps Plugin must be installed or deployed at the terminal client but it does not require any configuration.
The Softphone App at the terminal server does not require any additional configuration.
How it works
User starts the VDI software (Citrix Workspace App or Windows Remotedesktop) needed to connect to a remote server.
This software automatically starts the myApps Plugin. No user action required.
The user starts myApps at the server for the Softphone App. myApps discovers that it is running in terminal server environment and will connect to the plugin which was already started by the VDI software.
The user does not need to have any knowledge about the myApps Plugin.
Licensing
Known issues
- Webcam and remote videos must be rendered over the Softphone App but for the time being a native window is opened at the terminal client.
- Connecting to a conference or 3rd party conference does not transmit video as video starts in the Javascript code of the Softphone App and Javascript has no access to the local webcam at the remote server.
Video is displayed but with delay due to the rendering process.
Citrix may provide access to the local webcam internally and the webcam may be available but remote peer will probably experience delay of the received video.
- Start of AppSharing remains at the terminal server but the transmission of the media now starts at the local client.
We need to implement an exception for appSharing in the future as the transmission must happen at the server.
For the time being the appSharing is transmitted to the client and forwarded to the remote peer adding some delay due to this tranmission between server and client.