Explore The CamberCam Webinar Technical Specifications & Restful API

We have API documentation available for the webinar rooms so that you can develop your own user management integrations. There is also information on technical specifications and how the servers are structured, plus useful network integrations like required ports.

Supported Hardware

Windows

Any camera or video card compatible with the Windows Driver Model (WDM)

USB and FireWire supported

The CamberCam Webinar has been tested and works well with most Logitech Web Cameras. Logitech C920 and later models recommended

Mac

Any camera or video card compatible with the QuickTime driver model

USB and FireWire supported

Linux

USB and FireWire supported

Windows

Any microphone or sound card compatible with the Windows Driver Model (WDM)

USB and FireWire supported

Headsets or echo-cancelling microphones are strongly recommended

Mac

Any microhphone or sound card compatible with the QuickTime driver model

USB and FireWire supported

Headsets or echo-cancelling microphones are strongly recommended

Linux

USB and FireWire supported

Headsets or echo-cancelling microphones are strongly recommended

System Requirements

  • Hardware
  • Operating System & Browsers
  • Mobile Devices
  • Bandwidth
  • Ports

Windows

For participants:

2.0GHz CPU with dual-core processor minimum (Recommended: Quad-core i5 processor or better)

4GB of RAM minimum (Recommended: 8GB or more)

Mac

For participants:

Mac computer with an Intel processor (Recommended: Dual core 2.0GHz or faster)

4GB of RAM minimum (Recommended: 8GB or more)

Linux

For participants:

2.4GHz or faster x86-compatible processor or Intel® Atom™ 1.6GHz or faster processor for netbooks

4GB of RAM minimum (Recommended: 8GB or more)

Windows

Microsoft® Windows 10®
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Microsoft® Windows 8.x®
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Microsoft® Windows 7® SP1
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Mac

Mac OS X v10.8 or higher
Chrome v50 or higher (recommended for best performance), Safari 12.1 or higher, Firefox 49.x or higher

Linux

Red hat® enterprise linux (RHEL) 5 
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Novell SUSE® 9.x or higher
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Ubuntu 10 or later
Firefox 49.x or higher, Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Solaris

Solaris 10
Chrome v50 or higher (recommended for best performance), Firefox 49.x or higher

Android

Chrome

iOS

Safari

Audio

Minimum 50 kbps upload/download
(100 kbps recommended)

Video

Minimum 100kbps upload/download 
(200 kbps recommended)

Video (HQ resolution)

Minimum 500 kbps upload/download 
(1 mbps recommended)

Screen sharing

Minimum 800 kbps upload/download
(1.5 mbps recommended)

WEB SERVER

  • https traffic on port 443.

 

SIGNALLING SERVER

  • https traffic on port 443 (recently changed from port 80).

 

MEDIA SERVER API

  • https traffic on port 443.

 

MEDIA SERVER

The following port options are available to you, in order of decreasing performance.

 

1. Allow RTP Traffic UDP:1024-65535
This will give the best performance, as it provides a direct connection path to our media servers. 

 

2. Allow RTP Traffic UDP:80 or UDP:443 (incoming/outgoing)
This will allow UDP connections to our media servers via a TURN server on port 80. UDP is the preferred transfer protocol for real-time communications. However, the single port could cause performance problems if there is a lot of traffic between our networks. 

3. Allow RTP Traffic TCP:80 or TCP:443 (incoming/outgoing)
This will allow TCP connections to our media servers via a TURN server on port 80. TCP could cause issues, especially when there is a lot of traffic or poor connectivity. Additionally, the single port could cause performance problems if there is a lot of traffic between our networks. 

NOTE: For security reasons, we do not allow direct TCP connections to our media server.

What happens if you only open a few ports to the Media Server?
We require four ports per user for UDP streaming. Ports cannot be shared by users, and ports are assigned in a random fashion from any available server port in the range of 1024-65k. If the ports the service attempts to connect to are not available on the client then the system will fall back to relaying via TCP over the signalling server. So, if you happen to be extremely lucky, and all four ports you are assigned happen to fall into the IP range you opened then you will connect via UDP. This is not recommended.

CamberCam Webinar Restful API Documentation:

QUICKSTART

The CamberCam Webinar API is a RESTful Web Service.

It accepts requests using standard HTTP methods, such as GET, PUT, POST and DELETE. Currently, “Basic HTTP Authentication” is the only available method of authenticating. We are working to additionally provide “Digest HTTP Authentication”.

Examples given here are provided for the PHP programming language and uses cURL to make the HTTP requests.

 

IMPORTANT POINTS:

  1. According to the HTTP specification, when making GET requests, all parameters must be passed as URL/querystring parameters.
  2. When making PUT, POST or DELETE requests, all parameters must be passed in the request body; URL/querystring parameters in such requests will be ignored, except for the format variable.
  3. The data format of the request body must contain an input_type and rest_data variable, the former must be set to “json” and the latter must be a valid JSON array, such as input_type=json&rest_data={"id":"1","var2":"val2"}

    The JSON approach is robust as it allows the passing of objects and arrays whilst also being simpler to implement (simply json_encode() your data array before sending it). We provide PHP code examples for how requests are made with each API method below.

    In the future, we may allow for additional input_type (such as XML), but for the time being you must always set this to “json”.

    There is more choice available for return formats – take a look at the section called “Return Formatting” below.

  4. All special characters (+, $, , ect) in rest_data array should be urlencoded. You can use urlencode PHP function, or similar.

 

HOW TO USE HTTP BASIC AUTH WHILE DEVELOPING AND DEBUGGING

To access the CamberCam Webinar API methods you must pass the Authorization header as part of each request, set it to basic and pass the required encrypted string. For example:

Authorization: Basic bWF0dGhpYXM6YWWtaW4=

The encrypted string must be a base64 encoded combination of username and password in the following format:

myUsername:myPassword

In Fiddler you can create this string by opening the Encoder tab, selecting base64 and entering your credentials.

Note when using non-latin usernames: you can use a normal browser to test GET methods. You will be asked to provide username/password in a popup, which is passed to the server as HTTP Basic Auth. Note that not all browsers support non-latin characters during this authentication. Chrome works, Firefox and others do not support it. This is only an issue when testing with a browser. cURL has no such issues.

Essential Tools:

Fiddler2 – HTTP Web Debugger. Allows you to send GET, PUT, POST, DELETE and other HTTP requests, modify headers and request body, and capture the return values. Essential for testing and debugging your API integration.

Essential Reading:

“RESTful Web Services” by Leonard Richardson & Sam Ruby (O’Reilly) – some formulations in this document have been borrowed from this excellent book, in particular for the section on HTTP Error Codes.

 

GENERAL DEFINITIONS

[ver] – The version of the API endpoint, must be defined in each request URL. The current version is 2. Example: GET https://webinar.cambercam.co.uk/api/2/[username]/authverify

[username] – The username of the account which is making the API requests. Example: GET https://webinar.cambercam.co.uk/api/2/johndoe/authverify

 

HTTP ERROR CODES

400 “Bad Request”

Returned when providing input during a PUT operation which would leave the resource in an incomplete or inconsistent state. The provided input is nonsensical or corrupt.

Example: Providing an alphabetic value of “abcd” for an integer parameter, such as “offset”.

401 “Unauthorized”

Returned when trying to operate on a protected resource without providing the proper authentication credentials (either wrong or none at all). The response header WWW-Authenticate describes what kind of authentication the server will accept.

404 “Not Found”

Returned when trying to access a URI that does not correspond to any existing resource. The only possible exception is when a client is trying to PUT a new resource to that URI, see 201.

Example: Trying to retrieve a non-existing user.

405 “Method Not Allowed”

Returned when the client tries to use an HTTP method which this particular resource doesn’t support.

Example: Trying to PUT or DELETE a read-only resource.

409 “Conflict”

Returned when providing input during a PUT operation which would cause the resource state to conflict with some other resource.

Example: Trying to change your username to a name that’s already taken. Trying to delete a folder that is not empty.

410 “Gone”

Returned when the server knows there used to be a resource there, but there isn’t anymore. Also see 404, when the server has no idea about the resource at all.

500 “Internal Server Error”

There is a problem on the server side.

 

HTTP SUCCESS CODES

200 “OK”

Returned when a GET operation is successful, a POST operation to append to an existing resource is successful, and when a DELETE operation is successful.

201 “Created”

When a successful PUT or POST (when creating new) operation is carried out a 201 is returned, along with the new URI in the Location header. See 400 and 409 for related error codes.

301 “Moved Permanently”

Sometimes a PUT operation will change the URI of the resource just modified. In such cases, a 301 is returned, along with the new URI in the Location header. Future requests to the old URI will result in a 301, 404 or 410 return.

 

RETURN FORMATTING

The CamberCam Webinar API supports a number of different return formats.

By appending /format/[value]/ to the URLs of the API method calls, or by passing the correct MIME-type, you can choose the format of the returned data. These may differ for each call, so, for example you may wish to obtain a list of users in XML format, but get a list of invitees returned in JSON.

Available formats and how to request them:

FormatURL ParameterSample return
xmlnone (default) or /format/xml
<?xml version="1.0" encoding="utf-8"?>
<xml>
  <item>
    <id>1</id>
    <login>username</login>
    <email>[email protected]</email>
    <first_name>First Name</first_name>
    <last_name>Last Name</last_name>
    [...]
  </item>
</xml>
json/format/json
[
    {
            "id": "1",
            "login": "username",
            "email": "[email protected]",
            "first_name": "First Name",
            "last_name": "Last Name",
            [...]
    }
]
serialize/format/serialize
a:1:
{
    i:0;a:5:
    {
     s:2:"id";
     s:1:"1";
     s:5:"login";
     s:8:"username";
     s:5:"email";
     s:16:"[email protected]";
     s:10:"first_name";
     s:10:"First Name";
     s:9:"last_name";
     s:9:"Last Name";
     [...]
    }
}
php (can be used in eval)/format/php
array (
  0 =>
  array (
    'id' => '1',
    'login' => 'username',
    'email' => '[email protected]',
    'first_name' => 'First Name',
    'last_name' => 'Last Name',
    [...]
  )
)
html/format/html
<table border="0" cellpadding="4" cellspacing="0">
    <tr>
     <th>id</th>
     <th>login</th>
     <th>email</th>
     <th>first_name</th>
     <th>last_name</th>
     <th>[...]</th>
    </tr>
    <tr>
     <td>1</td>
     <td>username</td>
     <td>[email protected]</td>
     <td>First Name</td>
     <td>Last Name</td>
     <td>[...]</td>
    </tr>
</table>
csv/format/csv
id,login,email,first_name,last_name,[...]
1,"username","[email protected]","First Name","Last Name",[...]

s

Authentication

 

GET /authverify 

{{API_EndPoint}}/api/2/{{user_name}}/authverify

Use to test if the auth credentials passed with HTTP Basic are valid.

 

RETURN ARGUMENTS

authenticated (bool)If 1/true, credentials are valid..
 
 
AUTHORIZATION Basic Auth
 
HEADERS

Authorization
Basic YWRtaW46c2FtYmEyMDAy

Users

 

GET /user/id/[int] 

{{API_EndPoint}}/api/2/{{user_name}}/user/id/1

Get user account info by given ID#.

 

ARGUMENTS

Requiredid (int)The user account ID number.

 

RETURN ARGUMENTS

id (int)User account ID number.
login (str)The username of the user, used to login.
email (str)The email address of the user.
first_name (int)The first name of the user.
last_name (str)The last name of the user.
company (str)The company of the user.
country (str)The user’s country of residence.
timezone (str)The timezone of the user. See section “Timezones” below for more.
language (str)The language chosen by the user.
last_login (datetime)The datetime string the user logged in the last time.
profile_pic_url (str)URL to user profile image
 

AUTHORISATION Basic Auth

 
HEADERS

 
Authorisation
Basic YWRtaW46c2FtYmEyMDAy
 

GET /users

{{API_EndPoint}}/api/2/{{user_name}}/users

Get list of user accounts.

 

ARGUMENTS

Optionalcount (int)Specify number of returned results. Default is 100.
 offset (int)Specify to move the cursor through the recordset. Default is 0.
 order (str)Return results in ascending or descending order of recording ID. Default is asc.
Accepted values: asc, desc

 

RETURN ARGUMENTS

See GET /user/id/[int]

 
AUTHORISATION Basic Auth
 
HEADERS

Authorisation
Basic YWRtaW46c2FtYmEyMDAy
 
Example Request
Response
curl --location --request GET '{{API_EndPoint}}/api/2/{{user_name}}/users' \
--header 'Authorization: Basic YWRtaW46c2FtYmEyMDAy'
Example Response
200 OK

GET /user_id 

{{API_EndPoint}}/api/2/{{user_name}}/user_id/login/admin

Get one or many user id(s) by given email address or account username

 

ARGUMENTS

Requiredemail (str) or login (str)Email address or username (login) of specific user.

 

RETURN ARGUMENTS

id (int)The id of this resource (session id).
activated (bool)Boolean whether the user account is enabled or not.
is_guest(bool)Boolean whether the user account is guest or not.
deleted (bool)Boolean whether the user account is deleted or not.
 
AUTHORISATION Basic Auth
HEADERS

Authorisation
Basic YWRtaW46c2FtYmEyMDAy
 
 

PUT /user 

{{API_EndPoint}}/api/2/{{user_name}}/user
 Create a new user. Requires admin access rights.
 

RETURN ARGUMENTS

id (int)The id of the added entity.
message (str)Text message.

ARGUMENTS

login (int)The username of the user, used to login. 
password (str)The password for this user’s account.
email (str)The email address of the user.
first_name (str)The first name of the user.
last_name (str)The last name of the user.

 

RETURN ARGUMENTS

id (int)The id of the added entity.
message (str)Text messsage.
 
AUTHORISATION Basic Auth
HEADERS

Authorisation
 
Basic YWRtaW46c2FtYmEyMDAy
 

POST /user 

 
{{API_EndPoint}}/api/2/{{user_name}}/user

Edit an existing user. Requires admin access rights.

Requiredid (int)The id of the user to be edited..
Optional See params of PUT /user method.

 

RETURN ARGUMENTS

id (int)The id of the updated entity.
message (str)Text messsage.
 
AUTHORISATION Basic Auth
HEADERS

Authorisation
Basic YWRtaW46c2FtYmEyMDAy
 

DEL /user 

 
{{API_EndPoint}}/api/2/{{user_name}}/user

Delete user account.

ARGUMENTS

Requireduser_id (int)The id of the user account to be deleted. Note: the id may also be appended to the URL (…/id/xxx) instead of in the request body.

RETURN ARGUMENTS

id (int)ID# of user account.
message (str)Text message.
 
AUTHORISATION Basic Auth
 
HEADERS

Authorisation
Basic YWRtaW46c2FtYmEyMDAy
 

Usage Statistics

 
GET /statistics 
{{API_EndPoint}}/api/2/{{user_name}}/statistics

GET statistics and GET admin_statistics can potentially return a very large amount of date. In addition to limiting the /days parameter, we recommend that you:

1. limit type of data by using the /return option to define a subset of data fields, 2. use the /count and /offset options to page through the results.

 

ARGUMENTS

Requireddays (int)Number of days to retrieve stats for. A high number may yield a very large return set.
Optionalcount (int)Specify number of returned results. Default is 100.
 offset (int)Specify to move the cursor through the recordset. Default is 0.
 return(str)

Choose which fields should be returned by adding a list of semi-colon delimited field names eg

.../statistics/days/5/return/id;login;email;last_name

If not defined, a pre-defined subset of fields is returned

 

RETURN ARGUMENTS

aid (int)Account ID.
ahfn (str)Account Holder First Name.
ahln (str)Account Holder Last Name.
ahl (str)Account Holder Login.
sid (int)Session ID.
sn (str)Session Name.
pfn (str)Participant First Name.
pln (str)Participant Last Name.
pe (int)Participant Email.
jt (datetime)Join Time.
lt (datetime)Leave Time.
d (time)Duration.
st (str)Session Timezone.
sp (str)Session Password.
sac (int)Session Access Code (for phone dial-in).
 
AUTHORIZATION Basic Auth
HEADERS

Authorization
Basic YWRtaW46c2FtYmEyMDAy

Live User Statistics

 
GET /statistics_live 
{{API_EndPoint}}/api/2/{{user_name}}/statistics_live

Get live connection statistics for the user’s account. (Available in v4.3.7)

 

ARGUMENTS

Optionalcount (int)Specify number of returned results. Default is 100.
 offset (int)Specify to move the cursor through the recordset. Default is 0.
 return(str)Choose which fields should be returned by adding a list of semi-colon delimited field names eg
.../statistics_live/days/5/return/id;login;email;last_name
If not defined, a pre-defined subset of fields is returned

 

RETURN ARGUMENTS

aid (int)Account ID.
ahfn (str)Account Holder First Name.
ahln (str)Account Holder Last Name.
ahl (str)Account Holder Login.
sid (int)Session ID.
sn (str)Session Name.
pfn (str)Participant First Name.
pln (str)Participant Last Name.
pe (int)Participant Email.
jt (datetime)Join Time.
lpt (datetime)Last Ping Time.
d (time)Duration.
st (str)Session Timezone.
sp (str)Session Password.
sac (int)Session Access Code (for phone dial-in).
 
AUTHORIZATION Basic Auth
HEADERS

Authorization
Basic YWRtaW46c2FtYmEyMDAy