Tandberg TCEP Day 2

Todays topic is Bandwith and call control

There will also be a test today.

To be able to call out on the internet on the VCS, you need to add the DNS Zone. It should only be added on the Express, not on the control. It will not be there by default. On the Gatekeeper/BorderController this is not necessary.

If you are neighboring gatekeepers, you need to use a pattern type to reach the endpoints on another gatekeeper. It will work fine without, but if you plan to use bandwith control the call will not be in the correct link if you don’t use a pattern. This is possibly a bug, and will probably be fixed in version X3.

SIP <-> H.323 interworking will also work when contacting an endpoint on the outside, but it will consume 1 ekstra traversal license because of the interworking, so it will use 2 traversal licenses.

And I passed the TCEP as well 🙂

Tandberg TCEP Day 1

Todays topic is Call Control Components – GK, VCS-C, VCS-E

When you factory reset these units, all option keys will disappear.

When a CCC is in routed mode, RAS. Q931 and H.245 info will go through the device, as opposed to non-routed mode, where only RAS will pass through the device. In SIP, all calls are in routed mode, but with H.232 this is optional. The VCS is always in routed mode though.

The VCS has a SIPH.232 interworking feature. Note that using this interworking feature will count as 1 traversal call.

For the sake of redundancy, there is a possibility to set up alternate Gatekeepers. When using this, the endpoint will recieve a list of alternate gatekeepers. If the gatekeeper the endpoint is registered to goes down, the endpoint will connect to the next endpoint on the list. Be sure to set the H.323 TTL down to something shorter than 1800 seconds if the environment demands faster recovery from an outage. Note that a gatekeeper can only be alternate to another gatekeeper, and a bordercontroller can only be alternate to another bordercontroller, a gatekeeper can not be alternate to another bordercontroller and the other way around. This also applies to VCScontrol/express.

Tandberg TCAP Day 3

Todays topic is The Tandberg Codian MCU 4500 series

I do not know anything about the codian at all, so today will be purely lecture notes. The references to pages are pages in the course material.

The main difference between the 4500 series and the 4200 series is the amount of DSP chips. Also the 4200 has no support for Tandberg Codian ClearVision and if you want to have a higher resolution than CIF, you need to order an upgrade option.

ClearVision is described on page 16, but allows video media to be enhanced by up to 4 times the original resolution.

The 4200 uses an additional port for streaming. The 4500 does not. See amount of ports on page 22.

The codian MCU has two types of prefixes, a service prefix which is the same as on the MPS, but it also has a prefix that will register the full number on the gatekeeper. This can be used if you have a border controller and are allowing calls from the outside, by denying outside callers to call your internal conferences that are using your service prefix, but allow calls to external conferences which uses the GK registration prefix.

All conferences need to have a unique name, and it cannot be the same as old conferences either. It is therefore important to purge old conferences from time to time.

On versions 2.0 and older, you have to do a factory reset to recover a lost password, see page 88. On version 2.1 and newer, there is a reset password command on the console interface, see page 86.

And I passed the test 😀 I am now Tandberg TCAP!

Tandberg TCAP Day 2

Tandberg MPS is the topic of the day

The MPS is a gateway and a MCU in the same box. Comes in two versions, MPS 200 and 800. The 200 is a 3U box with 2 module spaces. The 800 is a 9U box with 8 module spaces.

It supports transcoding, which is translation between different codecs. If one system uses H.264 with G.722 and the other uses H.263+ G.722, the MPS will translate this.

It will also do ratematching, so in a multiconference, users can connect with different speeds. One can be 384kbps, one can be 512kbps and another one can be 768kbps. One conference can only use 2 different speedgroups, so if one user connects with 384kbps, and the next connects with 768kbps, a user that connects with 512kbps will get 384kbps back. He will send with 512kbps though. The two groups of speeds will always be the highest and the lowest of the speeds connected. This means that if you have one group with 768kbps and one with 512kbps, if a user connects with 384kbps, the user with 512kbps will be downgraded to 384kbps.
There is also a third group, but this is reserved for cellular systems.

Use chart on slide 37 for MPS capacity and scaling information.

Even though the MPS is 10/100 capable and has autosensing, it is smart to force switch and MPS media cards to 100 full duplex. This is due to different implementations of the autosensing feature from different switchmanufacturers. With normal computers, this is normally not noticed, because you seldomly use realtime traffic, but with videoconferencing, more or less all traffic is realtime and because of this duplex mismatch problems are more severe.

When creating a conference where the MPS/MCU will call out to a TCS-4 system, put the main number in the number field, and the extension in the SubAddress field.

It is important to create a good numberplan before implementation begins. You need several prefixes for functions as conferences and outgoing connections, and they cannot crash with each other.

In the gateway settings, do not set the “percent of total bandwith” to zero. This will obviously render the gateway useless.


The MPS has two modes on commandline. In addition to the commandline that exists on all Tandberg systems, it has also got a UNIX subsystem that contains files and folders, where the eventlog will be as txtfiles. To enter the UNIX system, use ‘root’ as a username in stead of ‘administrator’.

In an environment where there are a lot of different systems, when users experience problems with the conferencing system, check Fast Update Requests, FUR. The MPS will not handle them very well.

We managed to get in a bit of TMS at the end of the day as well

To manage Tandberg classic endpoints, you need to run version B4 and later.

Fun fact: On an endpoint, press the phonebook key 10 times, and you will get a menu filled with games 😀

Tandberg TCAP Day 1

Day 1 is going through the basics of Tandberg endpoints.

If you want to connect to an LCS server, do not upgrade to F6.3. If you want to connect to OCS, tou must upgrade to F6.3

External services
Through the TMS you have the opportunity to create XML services, much like on the Cisco CallManager. There is an API, but you’ll have to make all services yourself. There might be partners that have premade services…

Number recognition
The Tandberg endpoints doesn’t have any mechanisms to recognize an H.323 number from an H.320 number, so you will have to define this explicitly under net on the callscreen. It prioritizes H.320 before H.323 when using auto. The same applies to SIP vs H.323 URLs. The H.323 is prioritized. It is possible to mark any setting as default.

The standard is called H.239, but Tandberg also has a proprietary protocol. H.239 is only used when calling non-Tandberg endpoints. Polycom f.ex. also has their own proprietary protocol, so H.239 will have to be enabled on all endpoints that will be using DuoVideo with other types of endpoints.

When upgrading an endpoint, it may be a good idea to view the progress through the telnet interface to view errors and progress that might not be shown via web or the screen on the endpoint. Also, upgrading via ftp is also possible, but you’ll have to use the installation key as username. Password will be the administratorpassword on the endpoint.

Use http://egil.frontbase.no/ to check if your DNS SRV records are pointing correctly to your gatekeeper!

Great day 1! Learned a lot, and looking forward to the next two days of TCAP.