MCU technical comparison

[sadeghi]

Radvision MCU15 ~100: It seams that they have less ISDN capabilities than MGC-!00 and Tandberg's MPS , pleas put your Comments.

[Glen Sykes]

This is misleading:

If you don't put an ISDN card in an MGC, you can't do ISDN calls.

If you don't put an ISDN card in an MPS, you can't do ISDN calls.

The only difference between this type of architecture and Radvision is that the ISDN interface and the rest of the MCU are connected via a physical backplane, whereas with the Radvision solution, the IP network is the backplane. This brings numerous advantages.

What if you need a solution where you need only 1 MCU but you have a widely distributed network of ISDN based systems? By deploying gateways at strategic points within a network, ISDN call costs can be dramatically reduced, as well as improving call resilience (it's well known that the weakest link in ISDN is the interconnect between 2 carriers).

It's fair that on the MGC and Tandberg solutions, the ISDN network interfaces do not have their own capablilities (and thus possibly their own restrictions), but considering the above information, it's not as simple as you make it out to be. There are advantages and disadvantages to both types of solution.

[sadeghi]

What about the QoS support?

[Glen Sykes]

I think that it's fair to say that ISDN outperforms IP when making calls over an uncontrolled IP network. However we are now starting to see service providers gearing up their IP networks to carry this traffic long distances. We are also seeing smaller service providers creating innovative ways of carrying traffic across multiple service providers networks whilst retaining QoS (my own company being one of these :))

Once this happens IP will outperform ISDN significantly and I anticipate that the Radvision style architecture will become the preferable method.

What is the point you are trying to make? Do you beleive that ISDN will remain to be the network of choice?

[Sean Lessman]

This is misleading:

If you don't put an ISDN card in an MGC, you can't do ISDN calls.

If you don't put an ISDN card in an MPS, you can't do ISDN calls.

The only difference between this type of architecture and Radvision is that the ISDN interface and the rest of the MCU are connected via a physical backplane, whereas with the Radvision solution, the IP network is the backplane. This brings numerous advantages.

What if you need a solution where you need only 1 MCU but you have a widely distributed network of ISDN based systems? By deploying gateways at strategic points within a network, ISDN call costs can be dramatically reduced, as well as improving call resilience (it's well known that the weakest link in ISDN is the interconnect between 2 carriers).

It's fair that on the MGC and Tandberg solutions, the ISDN network interfaces do not have their own capablilities (and thus possibly their own restrictions), but considering the above information, it's not as simple as you make it out to be. There are advantages and disadvantages to both types of solution.

The MPS most certainly can do ISDN calls with the use of a gateway. This is exactly the same thing the RADVision MCU is doing.

The RADVision MCU is IP only. They do not make ISDN capable MCUs. To connect an ISDN site, you must use a gateway, either RADVision or other vendor. This means both the gateway and MCU must share the same feature sets or the conference will suffer.

Sean

[Glen Sykes]

Sorry Sean, I was probably being too literal, of course with use of a gateway the MPS and MCU can place ISDN calls.

In some ways the Tandberg MCU architecture takes the best of both the Radvision and MGC type solutions in that it can be configured for distributed ISDN via gateways, as well as centralised ISDN via its own ISDN interface, thus catering for most networked applications.

[Sean Lessman]

Sorry Sean, I was probably being too literal, of course with use of a gateway the MPS and MCU can place ISDN calls.

In some ways the Tandberg MCU architecture takes the best of both the Radvision and MGC type solutions in that it can be configured for distributed ISDN via gateways, as well as centralised ISDN via its own ISDN interface, thus catering for most networked applications.

No problem Glen :) I sometimes forget too.

One thing to also note, in the TANDBERG MCU world (and soon MPS) the media is handled the same way whether it is IP or ISDN. The network related information is 'stripped' and the raw media is mixed. Therefore it is irrelevant if the call is ISDN or IP, all features are present.

In the world where your MCU is IP only (the MPS today, RADVision, Codian etc), the choice in GW is very important. If the gateway is limited in any way, your ISDN capabilities are also limited. You also have to deal with the extra latency added by the gateway as most gateways transcode the video and audio (the TANDBERG GW does not transcode video).

There are pros and cons to both set ups. Having separate GWs allows you to put the GWs where your ISDN calls happen while allowing you to put the MCU where all the IP bandwidth is -- probably not the same place in most instances. However, stand alone GW densities are still rather low today, so you would probably not use them if your primary calls are ISDN. This is where the RADVision/Codian suffers -- in an all ISDN world, it gets very expensive due to all the gateways you have to buy.

In a centralized model, you can include IP and ISDN in the same MCU like the TANDBERG MCU, MPS (soon), and Accord. Drawback here is all ISDN calls have to go to one point, not good if you are a distributed organization (calling London from NY just to get into the conference).

Also, using the one box as the MCU and GW (as promoted by Accord) has its challenges. MCUs are typically scheduled devices, simply because larger meetings mean more people, and you have to schedule people -- hard to have an adhoc meeting with 16 people, most people do not have the same schedules. GWs are typically adhoc devices used by those that want to make an ISDN call from a H323 only device. Now imagine your scheduled call is about the launch, and a few adhoc last minute calls have stolen the ports. Accord does have the ability to 'assign' resources to the GW in the box, but now you have segregated resources so its essentially the same as having a separate GW and MCU. Also, MCU ports are very expensive -- especially ISDN ports in an Accord. Why use them as GWs? Gateways are relatively cheap compared to MCUs.

If you are clever and think outside the box, you can get the solution thats best for you and at the price that fits your budget.

Sean

[Glen Sykes]

Succinctly put!

[sadeghi]

RADVISION Point,
One positive point for RADVISION MCU versus TANDBERG MCU and POLYCOM MGC50/100 is capability of changing layout automatically, when numbers of participants change .

[Kevin]

RADVISION Point,
One positive point for RADVISION MCU versus TANDBERG MCU and POLYCOM MGC50/100 is capability of changing layout automatically, when numbers of participants change .

To be fair (according the to the Tandberg MCU manual) it will change the layout of the conference depending on the number of people in it.

Of course the Codian MCU will also change its layout on the fly too - as well as changing the resolution and bitrates it sends and receives on the fly intelligently ;)

[sadeghi]

Hi Kevin,
Tanks for your comments.I mean TANDBERG MCU 16 and TANDBERG MPS does not support continuous presence layout changes due to speaker activity, Like CNN Continuous Presence View

[sadeghi]

TANDBERG MCU does not support conference creation prior to conference start; therefore .It cold not support Ad-hoc Dialing

[sadeghi]

TANDBERG ,Media Processing System (MPS):Security Issues

If you dialed into a password protected conference with the TANDBERG MPS, it request for a password. And then if you dialed out to a second endpoint, the MCU did not request a Password. It means that this security feature worked for dial in connections but not for dial out connections. But both Polycom MGC-100 and RADVISION MCU will requested for a password in both cases.

[Sean Lessman]

TANDBERG ,Media Processing System (MPS):Security Issues

If you dialed into a password protected conference with the TANDBERG MPS, it request for a password. And then if you dialed out to a second endpoint, the MCU did not request a Password. It means that this security feature worked for dial in connections but not for dial out connections. But both Polycom MGC-100 and RADVISION MCU will requested for a password in both cases.
This is correct. From the feedback we have received from the service providers, dial outs do not require passwords because you have control of who enters the call, you dial them. We have not heard overwhelming requests to introduce this feature, however we are open to understanding the needs.

Sean

[trapehzoid]

TANDBERG ,Media Processing System (MPS):Security Issues

If you dialed into a password protected conference with the TANDBERG MPS, it request for a password. And then if you dialed out to a second endpoint, the MCU did not request a Password. It means that this security feature worked for dial in connections but not for dial out connections. But both Polycom MGC-100 and RADVISION MCU will requested for a password in both cases.

If someone has administrative control of the MCU.. why do you worry about passwords for the conference? The guy initiating the dial has full control of the MCU!

Rad is different because through the dial string, the conference initiator can dial out to other sites. But show me any average user who can figure that out and you're a lucky man.

Plus.. if memory serves.. the conference password in a Rad conference is pre-defined, not set by the user (not talking conference ID, but conference password). So that limits its usability