ArchitectureClient SDKsZebra APISIP FeaturesScalabilityCalls Flows

Call Flows

Client Server Communication

The client (Flash or HTML) can perform any of the following operations, all of which have different bandwidth and client/server CPU utilisation characteristics. This section describes the main operations and gives a summary of the resource utilisations.


The client communicates with the Load Management Service (LMS) using HTTP or HTTPS, passing any session or machine identification, and based on a GOIP lookup of the client, it is provided with the RTMP/T/S or HTTP connection details of a Gateway with the lowest capacity in its area.


The client communicates with the Gateway's ZAS using HTTPS, passing login credentials in order to obtain a session ID. This session ID is used in all future communication between client and server to authenticate the session. This means further communication can be over HTTP or HTTPS as required and can also be restricted to the IP address of the login. The session ID can be configured to expire after any amount of time, though the default expiry time is 24 hours. When the session expires, the client is told so, and it is free to auto-login again if configured to do so and holds the authentication details in memory.


The client communicates with the Gateway's ZAS to find an available Media & Notification (M&N) server to connect to.

Server Connection

The client then connects with an M&N using the RTMP protocol on port 14041, unless a firewall prevents connection. In this case it will use RTMPT which is the same as RTMP but wrapped in HTTP packets which will be transmitted through any firewall on port 80. RTMP provides about 10% more data for the same amount of bandwidth used, and is therefore preferable. Over 90% of users will have RTMP available. HTTP clients will use port 80.

Bandwidth Detection

In order to ensure optimum call quality without latency, video bit rates are controlled in real-time to ensure maximum throughput without compromising quality or delays.

Waiting for Calls

When the client is idle, it maintains an ultra low CPU and bandwidth connection with the server. The CPU for this operation is very low on each side and bandwidth usage is zero for RTMP or just 1.5Kbps for RTMPT. RTMP makes use of a TCP socket where no data is passed in wait mode. For RTMPT, which is the minor use case and is usually only required for some corporate firewalls, the client has to initiate every request to the server in order to maintain keep-alives with the server. Once per second is optimal and the HTTP message contains just 1 byte of interest, however the HTTP header and packet take up 360B. It is possible to improve on this if necessary by having the "polling" request not return immediately but instead hold the request open much like Ajax.


At the point of making a call, the client again communicates with the CLS over HTTP(S) allowing the CLS to warn the client that it does not have sufficient funds, place a call as Third Party Call Control, and check calling limits.


When the client is in a call, audio and video is transferred between client and server. This is the most resource-hungry state. Audio requires up to 32kbps at 16KHz and video can be anything up to a configurable max of say 3000kbps.

Full Call Flow Diagram

Media Flow for Voice and Video Calls

This section shows how media can flow P2P despite call control going via the server.