FCSDK Architecture Guide

YRP1-508, 3-4 Hikari-no-Oka Yokosuka-Shi, Kanagawa, 239-0847, Japan

tel.: + 81-(0) 46-821-3362 | cba-japan.com
This document contains confidential information that is proprietary to CBA. No part of its contents
may be used, disclosed or conveyed to any party, in any manner whatsoever, without prior
written permission from CBA.
© Copyright 2023 CBA.

All rights reserved.

Updated: 2022-05-02

Document version: 3.3/1

iOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used
under license by Apple Inc.

Java is a registered trademark of Oracle and/or its affiliates.

Linux® is a registered trademark of Linus Torvalds, owner of the mark on a world-wide basis.

Microsoft, Lync and Windows are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

Red Hat is a trademark of Red Hat, Inc. in the United States and other countries.

VP8™ and Android™ are trademarks of Google Inc.

CentOS™ is a trademark of the CentOS project.

All other trademarks are the property of their respective owners.

Contact Information

For technical support or other queries, contact CBA Support at:

[email protected]

For our worldwide corporate office address, see:

https://www.cba-japan.com (Japanese) https://www.cba-gbl.com (English)

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 2

Documentation Set
FCSDK Overview Guide

FCSDK Architecture Guide

FCSDK Installation Guide

FCSDK Administration Guide

FCSDK Developer Guide

Related Documentation

Fusion Application Server

FAS Architecture Guide

FAS Installation Guide

FAS Administration Guide

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 3

Contents
Introduction
Network Components
Web Gateway
Requirements
High Availability
Fusion Media Broker
Requirements
High Availability
Web Application
Call Flows
Logging In
Outbound Calling
Inbound Calling
Application Event Distribution
Deployment Options
Deployment Security
Network Components
Reverse Proxy
Media Broker
Gateway
Secure Call Flows
Logging In
Outbound Calling

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 4

Introduction
The CBA Fusion Client SDK allows users to develop web applications which can:

Make and receive voice and video calls directly from a Web browser to telephones and
other browsers, without employing web plugins.

Share application events and data

To achieve this, Fusion Client SDK includes:

The Core SDK, which developers can use to develop browser-based applications

The iOS SDK, which developers can use to develop applications for iOS and OSX based
devices.

The Android SDK, which developers can use to develop applications for Android devices

Fusion Client SDK also includes components which allow the enterprise to deploy the
applications which they develop.

Network Components

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 5

Web Gateway
Most enterprise communications solutions such as VoIP and video systems support the Session
Initiation Protocol (SIP). The Fusion Client SDK solution includes a Web Gateway, which
removes the complexity in the signaling between SIP-based devices and client applications so
the two can communicate together seamlessly.

The Web Gateway communicates with the client using the TCP-based WebSockets protocol,
providing a standard way for the server to send content to the client without being solicited, and
allowing messages to be passed back and forth while keeping the connection open.

For example, with the Web Gateway, users can:

Make voice calls from a native client to desk phones from any PBX vendor

Make calls across the public switched telephone network (PSTN) to phones in the public
domain

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 6

 Initiate video sessions directly to SIP-based video endpoints and other clients.

The primary functions of the Web Gateway are to:

Provide Client-to-SIP signaling conversion

Only allow clients that have been authorized by the Web application to create sessions

Create and manage application collaboration sessions, sharing data and sending messages
to client applications.

The Web Gateway communicates with the Media Broker using the HTTP-based Proxy control
protocol

Requirements

The Web Gateway runs on Fusion Application Server 2.6.x; refer to the Fusion Application
Server Release Notes for details of the supported operating systems.

The Web Gateway can be co-hosted with any other application on Fusion Application Server
or deployed on a Fusion Application Server of its own.

Any Fusion Application Server on which the Web Gateway is installed must have a Load
Balancer installed on it; see the FAS Installation Guide for details.

The Web Gateway must have a domain assigned to it that is DNS resolvable. When installed on
its own Fusion Application Server, the domain can be set to the Fusion Application Server IP
address. For more details, refer to FCSDK Installation Guide.

High Availability

In a high availability (HA) solution, failure of a Web Gateway node will not impact existing voice
and video calls unless the failure occurs mid-transaction. Client applications will attempt to re-
establish a connection in the event of a Web Gateway failure or network outage.

Fusion Media Broker

The Media Broker runs independently of the Fusion Application Server cluster (that is, it does
not run on FAS), and is responsible for media transcoding and RTP routing between the client
applications and the SIP network. Routing is configured based on the SDP passing through the
Web Gateway. For communication into the enterprise, the Media Broker’s role is to simplify the
RTP, limiting it to a form that the users’ SIP devices support. For communication going to the

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 7

client application, it adds the WebRTC-compliant features that are required by the client to the
RTP received from the SIP devices.

As with signaling interworking, it must handle RTP media streams and integrate them with SIP
environments. For example, client applications may use a different video standard (VP8) than
most enterprise video systems (H.264); as a result, applications cannot share video calls with
enterprise-based systems unless there is media transcoding between the two. The Media Broker
provides that service in the network by transcoding between VP8 and H.264 video, and G.729 to
Opus or G.711 audio.

The Fusion Client SDK for iOS supports the H.264 codec, ensuring there is no need for
transcoding with this API.

With the Media Broker, employees and customers can share secure video calls on a wide variety
of devices,and join video conferences from almost any endpoint.

The primary functions of the Media Broker are to:

Convert between client RTP streams and RTP streams compatible with SIP entities.

Change the video frame rate and resolution according to client capabilities.

Encrypt RTP signaling when required.

Requirements

If your Fusion Client SDK installation requires video transcoding, Fusion Client SDK includes a
virtual machine template package containing the OS for the Media Brokers. Refer to FAS
Installation Guide for instructions.

If your Fusion Client SDK installation does not require video transcoding, the Media Broker can
be installed on Linux (RedHat or CentOS).

The Media Broker requires Java SE Development Kit (see FCSDK Release Notes for the
supported versions).

High Availability

Multiple Media Brokers can be deployed to provide service availability for RTP traffic. If a Media
Broker fails, it is possible that the endpoints may tear down the call because they are not
receiving RTP.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 8

Web Application

Fusion Client SDK enables you to develop your own Web Application or integrate with an
existing application.

In integration with Fusion Client SDK, the Web Application:

Manages user data and permissions

Allocates sessions on the Web Gateway for users

Provides the web UI to browser-based client applications

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 9

Call Flows
The following diagrams show how calls are dealt with in the network for different scenarios.

In the diagrams, the different network components are represented by separate boxes, but this
does not mean that they need to run on separate physical hardware.

Logging In

The Web Application allows the user to log in, so that the application can identify and
authenticate the user:

1. The Client connects to the custom Web Application and logs in with user credentials. The
Web Application authenticates the user and determines what services the user can use.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 10

 2. The Web Application asks the Web Gateway to create a session token. The Web Gateway
stores capability information in the session, sets an expiry time for the session, and returns
the token to the Web Application, which passes it to the Client.

3. The Client sends a message to the Web Gateway containing the session token. The Web
Gateway ensures that the targeted Application session is valid (that is, it contains session
information populated when the Web Application requested the token).

4. Depending on the features the Web Application has enabled for the user, the client
communicates with the rest of the network to register externally (for example, sending a SIP
REGISTER request to receive voice and video calls).

Outbound Calling

1. The Client initiates a call to the Web Gateway by passing the required information over
WebSockets.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 11

 2. The Web Gateway validates the token and then checks the capabilities for this user making
a call to the given destination. The Web Gateway communicates with the Media Broker to
reserve a route and negotiate SDP.

3. The Web Gateway issues an INVITE to the SIP network. The call is answered and relevant
SIP signaling occurs.

4. The Web Gateway communicates with the Media Broker to complete the route information.

5. The Web Gateway notifies the client of the progress of the call, and its establishment.

6. RTP is transmitted via the Media Broker, where transcoding occurs if required.

Inbound Calling

1. The Web Gateway receives a call from the SIP network.

2. The Web Gateway communicates with the Media Broker over HTTP/HTTPS to reserve a
route and negotiate SDP.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 12

 3. The Web Gateway notifies the Client of the inbound call.

4. The Client answers the call and notifies the Web Gateway.

5. The Web Gateway completes the route set up on the Media Broker and returns a 200
response to the SIP network.

6. RTP is transmitted via the Media Broker, where transcoding occurs if required.

Application Event Distribution

Application Event Distribution (AED) allows multiple clients to connect to a single session and
set, get, and be notified of, updates to the AED data held in that session.

1. The Client requests to create or look up a collaboration session. The Web Gateway verifies
that the Client has access to AED and links the user to the identified collaboration session.

2. The Client subscribes to updates on the session.

3. The Client requests to set a value in the session identified by a key. The Web Gateway sets
the value and notifies all clients that have subscribed to the session of the update.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 13

A client can request a value by key on a session. The Web Gateway returns the value.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 14

Deployment Options
Fusion Client SDK is very flexible in terms of the deployment options available. You can deploy
Fusion Client SDK in environments from small footprint deployments most suited to
development or testing with a small number of subscribers, to distributed deployments
supporting high availability (HA) and scalability.

HA solutions ensure that if an individual cluster component fails, the service continues.

The simplest deployment available is one where all the network components are hosted on the
same physical (or virtual) machine.

You can make this type of deployment HA by adding more Fusion Application Server instances
and Media Brokers on other hosts:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 15

You may prefer to deploy the Media Broker on a separate host to the Fusion Application
Server cluster, in which case your deployment would look like:

If they are on different hosts, you can scale your Fusion Application Server instances and
Media Brokers independently of each other, depending on the scalability requirements of each
component:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 16

The following diagram shows a distributed HA installation where each component of the Fusion
Client SDK is installed on a separate physical server with redundancy.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 17

Deployment Security
This section describes the security capabilities of Fusion Client SDK. It describes a sample
deployment and the security features of the components within that network.

The reference network architecture is distributed across three zones:

Internet (red zone)

The Client Application, whether it is based in the browser or on a mobile device, is situated in the
public internet.

DMZ (amber zone)

The Reverse Proxy and Media Broker are based in a DMZ, which is protected from the public
internet by a firewall.

Internal (green zone)

The Web Application and Web Gateway are on the enterprise’s internal network, as is the SIP
telephony network. The internal network is protected from the DMZ by a firewall.

This section also lists the secure protocols supported by Fusion Client SDK, and details the
connections over which they are used.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 18

Network Components

Reverse Proxy
A Reverse Proxy deployed in the DMZ can act as a proxy to components in the internal network,
hiding their topology. The Reverse Proxy can serve up static and dynamic content on behalf of
the application, reducing the amount of traffic that has to enter the internal network, and the
amount of processing required by the Fusion Application Server.

The Reverse Proxy can also perform user authentication on behalf of the Web Application,
ensuring that only authenticated connections can reach the internal network. It can also take
advantage of hardware SSL accelerators to provide SSL termination, decrypt the data on behalf
of the application, and establish a secure context with the client.

Once the secure context has been established, all subsequent communication between the
client and the server is within that context. This allows the administrator to set up rules on the
Reverse Proxy to stop it establishing WebSocket connections with the Web Gateway if they are
not part of an already established security context.

The Reverse Proxy must support WebSockets.

Media Broker

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 19

The Media Broker sits in the DMZ and provides edge server functionality between the external
network and the internal network. The Media Broker only allows authenticated traffic from a
known client, with a route through the Media Broker allocated by the Web Gateway, through to
the internal network. It authenticates this traffic using the SSRC, of which only the client
application and Media Broker have a record.

The Media Broker segregates its traffic, so that it communicates with the external network on a
different network interface to the Proxy Control Protocol traffic between itself and the Web
Gateway, and to the RTP traffic with the internal network. The network administrator can restrict
access to the internal-facing network interfaces to only servers in the internal network, and
ensure that no external traffic can try to access any other network port. Additionally, the Media
Broker uses RTP multiplexing and SSRC identifiers to ensure that only a single port is required
on the external firewall to forward all RTP traffic to the Media Broker. Only RTP packets that
conform to the limits set for packet size and throughput rate are allowed into the Media Broker
(see FCSDK Administration Guide for details on setting these limits).

Fusion Client SDK secures the media stream between the client and the Media Broker using
SRTP.

The WebRTC specification mandates that this media stream is secure.

Gateway
The Web Gateway exists in the internal network, and the only non-internal network components
with which it communicates directly are the Web Application and the Reverse Proxy.

The Web Application communicates with the Web Gateway over HTTPS, and the Web Gateway
only establishes sessions that the Web Application has requested on behalf of client
applications. Client applications can only communicate with the Web Gateway through the
Reverse Proxy, which manages the security context into the network. Client applications which
do not have the correct session token will not be able to connect to the Web Gateway.

The Web Gateway connects to the Media Broker in the DMZ using the details configured for the
control protocol; the Media Broker does not need to establish a connection into the Web
Gateway.

Secure Call Flows

The following diagrams show how the Fusion Client SDK security features are used in the
Logging in (see the Logging In section on page 8) and Outbound Calling (see the Outbound

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 20

Calling section on page 9) call flows.

Logging In
With the Web Gateway residing in the internal network, Fusion Client SDK uses the Reverse
Proxy to ensure that there is no way to access the Web Gateway outside of the secure context
that is established between the client application, Reverse Proxy, and Web Application.

1. The client application calls into the DMZ, via the Reverse Proxy. The Reverse Proxy
establishes a secure context by authenticating the user.

2. The Reverse Proxy forwards the login to the Web Application.

3. In the internal network, the Web Application creates a session on the Web Gateway.

4. The Web Gateway returns a session token over the secure context to the client, via the Web
Application and Reverse Proxy. This session token cannot be viewed or intercepted by any
malicious entities.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 21

 5. The client application initiates the WebSockets connection using the secure context
established in step 1. The Reverse Proxy would reject any connections which are not part of
the secure context.

6. The Reverse Proxy establishes the WebSockets connection with the Web Gateway. The
Web Gateway validates that the session, identified by the session token, exists. If the
session does not exist, connection is rejected.

Outbound Calling

1. The client application generates SDP, containing an SSRC, and passes it to the Web
Gateway via the secure WebSocket established during login.

2. The Web Gateway communicates out of the internal network, configuring the route to the
Media Broker, on the port configured for the control protocol. The Media Broker records the
information in the SDP, including the SSRC, and returns the SDP describing its own media
capabilities.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 22

 3. The Media Broker receives SRTP from the client application on the port configured for the
WebRTC client.

The Media Broker will only process SRTP packets with a valid SSRC and a route defined on the
Media Broker. It will discard SRTP packets with an invalid SSRC, along with any packets which
do not conform to the limits set on packet size and throughput rate.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 23