This server allows you to control a Tandberg 1000 Classic video conferencing endpoint using Blue Jeans Relay. Relay does not have built-in support for the Tandberg 1000 Classic because this endpoint is old and outdated, but thanks to the extensible Relay Mesh Control Protocol, anyone can easily extend Relay to support other endpoints like this one.
This repository serves as a reference implementation of the Mesh server interface. It successfully controls a real endpoint from Relay. You may use this repo as a starting point for developing a Mesh server for your own endpoints. This particular server is written in Java, but you can use any language that can run an HTTP server.
Relay is a video conferencing endpoint control system created by Blue Jeans. It lets you synchronize your calendars to endpoints, join scheduled Blue Jeans meetings with one touch, and control the endpoints from a tablet or any API client. It integrates with a bunch of different endpoints already.
Relay Mesh is an HTTP interface that allows Relay to integrate with otherwise unsupported endpoints. If you create and run an HTTP server that implements this interface and controls your endpoints, then Relay will be able to control your endpoints.
See the Relay API docs for precise API specifications and more details about Mesh.
Imagine you're already using Relay to attend your scheduled and ad-hoc meetings on your Cisco, Lifesize, Polycom, StarLeaf, Tely, or Sony video conferencing endpoints using their built-in calendar interface, the Relay Touch Android or iOS apps, or a custom API client integration. Life is good, and joining meetings is easy.
Now you want to do the same thing with a different kind of endpoint, one that Relay doesn't natively support. You could, in theory, write a web server that controlled your endpoint, make it imitate the admin interface of a supported endpoint (Polycom, for example), and then provision it in Relay using a Polycom Control Protocol. Unfortunately, that's not a perfect solution, because it's a large amount of work for you to spoof a Polycom API, and the way a Listener Service controls a Polycom endpoint might change, leaving your fake endpoint broken.
To solve this, Relay allows you to provision an endpoint using a very generic, stable Control Protocol called Mesh. It's not vendor-specific, and it's very easy to implement. All you have to do is create an HTTP server like this one that exposes a few specific REST API methods. Then you make those API methods control your endpoint using whatever remote control interface it offers, whether it's HTTP, SOAP, Websockets, AMF, SSH, Telnet, raw TCP sockets, RS-232 serial, or infrared remote.
- Blue Jeans Relay account and Listener Service
- Java SE Development Kit ≥ 7
- Maven
git clone https://github.com/bluejeans/relay-mesh-tandberg-1000-classic.git
cd relay-mesh-tandberg-1000-classic
mvn compile exec:java
The Mesh web server will compile and run, listening on port 6374. Requests will be parsed and logged.
- Log in to the Relay administrative site
- Create a new Endpoint
- Give the Endpoint a Name
- Choose an existing Listener Service that can connect to your Mesh server
- Set the Control Protocol to Relay Mesh
- Set the Mesh Base URI to the URI of your Mesh server, e.g.
http://192.168.1.100:6374/ - Set the IP Address to your Tandberg 1000 Classic's LAN IP address
- Set the Password to your Tandberg 1000 Classic's IP password, if one is set
Now you should be able to make the endpoint start dialing by clicking the Join link and supplying a meeting ID, like 415123456.
| ⚠ Warning: these steps are silly ⚠ |
|---|
| If all you care about is seeing how Mesh works, and you don't actually need to make a Tandberg 1000 Classic successfully dial into a Blue Jeans meeting with a passcode behind a NAT, then you don't actually have to set up an H.323 gateway. Setting up a gateway for your ancient endpoint is only good for personal satisfaction and bragging rights. |
On its own, the Tandberg 1000 Classic has a few limitations.
- No NAT traversal, so it can't make outbound calls to the WAN if it's behind a NAT.
- Dial strings cannot contain
.in the local part of a URI, so it can't send a meeting passcode to Blue Jeans.
To be fair, it reached end-of-life in 2004, so it's not exactly new.
If you want to, you can solve these problems by putting the endpoint in a DMZ and only dialing into passcodeless meetings, but that solution is insufficiently complex. Instead, we can use an H.323 gateway, such as a Cisco VCS, to solve both of these problems.
- Enable H.323 and interworking.
- Create a DNS zone for
bjn.vc. - Create a dial plan search rule that performs an alias pattern match on meetings with passcodes using the regex
replacing the match with and targeting the DNS zone you created.
^(\d{5,})[\*\.](\d{4,})@(?:sip\.)?bjn\.vc - Make a second copy of this dial plan with the pattern
replacing the match with to handle passcodeless meetings.
^(\d{5,})@(?:sip\.)?bjn\.vc - Register the endpoint to the VCS. You can do this from the on-screen menu or from the endpoint's web interface: under System Configuration › Networks › H.323 Settings, specify the manual gatekeeper IP of your VCS.
- In the Relay administrative site, create a new Dial Style with a Format with Passcode of
and a Format without Passcode of
{meetingid}*{passcode}@{host}{meetingid}@{host} - Set the Tandberg 1000 Classic Endpoint in Relay to use this Dial Style.
- Set the Endpoint in Relay to use Hostname as the Address Style.
After all that shenanigans, you can dial again, and Relay will use an asterisk in the dial string to separate the meeting ID and passcode, instead of a period like standard Annex-O, which allows the endpoint to not barf on the dial string. When the VCS receives the call, it will restore the Annex-O dial string, convert the call signaling from H.323 to SIP, send it to Blue Jeans, and receive inbound traffic even if there is a NAT.
This is the sequence of events that occur when a user commands a Tandberg 1000 Classic to dial into a Blue Jeans meeting using Relay and a Mesh server.
The same path is used for all Mesh methods.
The Tandberg 1000 Classic serves an administrative web interface on port 80, protected by Digest authentication. From this interface, you can join a meeting, check the status, hang up, and perform other configuration tasks. This Mesh server uses the endpoint's web interface to let Relay control the endpoint.
One task that isn't exposed in the endpoint's web interface is muting and unmuting the microphone. However, it is exposed in the Telnet API. Therefore, this Mesh server uses Telnet, but only for muting and unmuting the endpoint's microphone.
$ telnet 10.4.5.104
Welcome to John-Chambers
TANDBERG Codec Release E2.3 NTSC
SW Release Date: 2003-10-20
Password:
OK
mic off
OK
bye
The Mesh server interface is implemented in src/main/java/vc/bjn/catalyst/mesh/tandberg1000classic/api/EndpointControlResource.java. This is the Listener Service's entry point into your server.
The endpoint client is implemented in src/main/java/vc/bjn/catalyst/mesh/tandberg1000classic/dispatcher/Tandberg1000ClassicDispatcher.java. This is what your server uses to control your endpoint.
The Mesh server uses the Jersey REST server framework running on a Grizzly HTTP server. Dependencies are injected using HK2.
The endpoint client uses a Jersey REST client with the built-in HttpURLConnection connector. The client also uses the Apache Commons Net TelnetClient for toggling the endpoint's microphone mute state, which is unavailable from the web interface.
Logging is handled by SLF4J/Logback. JSON is handled by Jackson.
Tests are located in src/test/java and can be run from the Maven command line with mvn test or through your IDE with TestNG.
If you want requests to pass through a debugging proxy like Fiddler or Charles, you can use VM arguments or compile-time properties. See Configure a Java Application to Use Fiddler for details.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent