SlideShare una empresa de Scribd logo
1 de 74
Descargar para leer sin conexión
December 2004
                                                                            www.veritest.com • info@veritest.com




Multipoint Conferencing Unit Comparative
Study
Test report prepared under contract from Polycom, Inc.

Executive Summary
Polycom commissioned VeriTest to
conduct an independent comparative                               Key Findings
analysis of four Multipoint
Conferencing Unit (MCU) products
                                                Overall, the Polycom MCU demonstrated the most complete
used for video conferencing systems.
                                                set of security and authentication, as well as, administration
We performed a series of tests on
                                                operation and control feature capabilities of all MCU products
each product that was consistent with
                                                in our review.
the typical product usage.
                                                We found that the Polycom MCU offered the most flexibility
We evaluated the following four MCU             within its feature set of all of the MCU products.
systems:
                                                Based on the results from our three use case scenarios, we
    • Polycom MGC-100                           found that the Polycom offered the largest and most flexible
    • RADVISION viaIP 400 MCU                   set of options to complete the use cases successfully.
    • TANDBERG MCU 16+16
    • TANDBERG Media
       Processing System (MPS)

Polycom and VeriTest worked together to create a test methodology to measure the capability of each
product in this study. This methodology covered a wide spectrum of real-user MCU product capabilities and
was designed to examine how effective each product was when subjected to real-world operational settings.
The 71 test cases that we used measured the capability of each product across the following feature set:

    1. Security and Authentication
          a. Conference Security
          b. System Security
    2. Versatility
          a. Transcoding
          b. Data and Content
          c. Continuous Presence
          d. Conference Routing
          e. Conference Types
          f. Resource Management
          g. Customization
    3. Operation and Control
          a. System Management
          b. User Control

In summary, we found that the Polycom MGC-100 MCU successfully passed 63 of the 63 test cases,
compared to 14 passed test cases for the RADVISION viaIP 400 MCU, 5 for the TANDBERG MCU 16+16,
and 7 for the TANDBERG MCU MPS. Additionally, for tests that were quantitative in nature and did not
generate a simple pass/fail response, the Polycom MCU consistently demonstrated a significantly wider range
of capabilities and more flexibility than the other manufacturers. One example that showed this flexibility was
the Polycom approach to transcoding. Their ability to mix 62 video connections in a single conference, each
with separate connection parameters was significantly more than the other manufacturers could do and would
be of significant benefit in a video network deployment.

The Polycom MCU also demonstrated the most complete set of security and authentication capabilities as
well as the most powerful administration operation and control features of all MCU products in our review. An
example of this is the consistently high pass rate of the Polycom MCU on security issues such as multiple
administration levels and password protection, when compared to the other manufacturers’ products.

Overall, we found that the Polycom MCU offered by far the greatest flexibility within its feature set across all
three key areas of security, versatility and operational management of all of the MCU products tested.

In addition, we used three use case scenarios to determine how each product would behave when deployed
as the target MCU within different real-world scenarios.

For the first use case, we used the following scenario:
    Company XYZ hosts multiple conferences on the behalf of clients and billed according to usage. As such,
    they need to provide secure conferencing with strong password and conference protection. Every client is
    provided with a unique, randomly generated password for chair and participant access. It is critical that all
    passwords comply with their in-house password policy.
Based on our test case results, the Polycom MCU was able to complete all required tasks. The RADVISION
MCU was able to complete two of the required tasks, and both TANDBERG MCU products did not pass on all
tasks.

For the second use case, we used the following scenario:
    Company XYZ has implemented on-demand conferencing throughout their company. Each functional
    work group has their own entry queue, conference identifier, and set of passwords for security. To
    conserve resources, the director of IT only wants the conference to start once the chairperson is
    participating. In addition, to minimize the amount of time spent on conference management, the director
    wants the ability for the chairperson to control his or her own conference, identifying who is present, the
    duration, and the screen layouts.
Based on our test case results, the Polycom MCU was able to complete all required tasks. The other MCU
products did not pass on all tasks.

For the third use case, we used the following scenario:
    Service Provider XYZ business model is to host multiple conferences for their enterprise-based clients. As
    such, they provide premium high touch services as a way to differentiate themselves from their
    competition. One area they wish to excel at is for their clients to have a high quality experience with the
    expectation to connect right away, request help when needed and the audio quality to be superb. This
    service provider has set up each of their clients with their own call in number with multiple conference ID’s
    for each number, customized IVR, operator services and a Service Level Agreement. Since they host
    thousands of hours of conferencing per month, scalability is required and multiple operators to monitor on
    going conferences.
Based on our test case results, the Polycom MCU was able to complete all required tasks. The other MCU
products did not pass on all tasks.

Based on the results from our use case scenarios, we found that the Polycom offered the largest and most
flexible set of options to complete the use cases successfully.




              Multipoint Conferencing Unit Comparative Study                                                       2
Test Results
Polycom commissioned VeriTest to conduct a comparative analysis of four MCU products. We performed a
series of tests on each of the four products that was consistent with the typical product usage.

We evaluated the following four systems:
   • Polycom MGC-100
   • RADVISION viaIP 400 MCU
   • TANDBERG MCU 16+16
   • TANDBERG MPS

Polycom and VeriTest worked together to create a test methodology to measure the capability of each
product in this study. This methodology covered a wide spectrum of real-user product capabilities. The test
methodology that we used measured the capability of each product across the following feature set:

   1. Security and Authentication
         a. Conference Security
         b. System Security
   2. Versatility
         a. Transcoding
         b. Data and Content
         c. Continuous Presence
         d. Conference Routing
         e. Conference Types
         f. Resource Management
         g. Customization
   3. Operation and Control
         a. System Management
         b. User Control

Although we tested discrete features of the MCUs in this study, some of the tests that we ran have common
methodologies. See the section on Test Methodology for a complete description of the test methodology that
we used in this study.




             Multipoint Conferencing Unit Comparative Study                                                  3
Results Summary

The following set of tables includes a summary of the test cases that we performed in this study.

 Test #       Test Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                      100        400 MCU           16+16
    1     Conference                 Passed       Passed        Did not pass Did not pass
          Password
          Call-in and Call-
          out
    2     Password                  Passed          Did not pass        Did not pass       Did not pass
          Hierarchy
    3     Privilege Profiles        Passed          Did not pass        Did not pass       Did not pass
    4     Automatic                 Passed          Did not pass        Did not pass       Did not pass
          Password
          Generation
    5     Password Integrity        Passed          Did not pass        Did not pass       Did not pass
          Validation
    6     Conference                Passed             Passed           Did not pass       Did not pass
          Password String
          Validation
    7     Change                    Passed          Did not pass        Did not pass       Did not pass
          Conference
          Password During
          A Conference
   8      Conference Lock           Passed            Passed              Passed             Passed
   9      Conference Hide           Passed          Did not pass        Did not pass       Did not pass
   10     Automatic                 Passed            Passed            Did not pass       Did not pass
          Conference
          Termination – no
          show
   11     Automatic                 Passed             Passed           Did not pass       Did not pass
          Conference
          Termination – after
          last person
   12     Automatic                 Passed          Did not pass        Did not pass       Did not pass
          Conference
          Termination – after
          chairperson 
          leader profile exits
   13     Conference                Passed          Did not pass        Did not pass       Did not pass
          Termination –
          During A
          Conference
   14     Conference                Passed          Did not pass        Did not pass       Did not pass
          Requires
          Chairperson or
          leader To Start
   15     Participant               Passed          Did not pass        Did not pass       Did not pass
          Identification –
          Entering a
          conference
   16     Participant               Passed          Did not pass        Did not pass       Did not pass

             Multipoint Conferencing Unit Comparative Study                                               4
Identification –
          Leaving a
          conference
   17     Automatic              Passed         Did not pass   Did not pass   Did not pass
          Participant
          Identification By
          Name
   18     Roll Call              Passed         Did not pass   Did not pass   Did not pass
   19     Automatic Dial Out     Passed         Did not pass   Did not pass   Did not pass
   20     Operator Assisted      Passed         Did not pass   Did not pass   Did not pass
          Routing
Figure 1. Security and Authentication Test Results




            Multipoint Conferencing Unit Comparative Study                                   5
Test #        Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100        400 MCU           16+16
   21     Request Private        Passed     Did not pass    Did not pass Did not pass
          Operator
          Assistance
   22     Secure Breakout         Passed        Did not pass     Did not pass     Did not pass
          or Sidebar
          Session
   23     Decreasing              Passed        Did not pass     Did not pass     Did not pass
          Password
          Attempts
   24     Failed Conference       Passed        Did not pass     Did not pass     Did not pass
          Access
   25     Secure Non              Passed        Did not pass     Did not pass     Did not pass
          Password
          Conference
   26     Administration         3 levels of     2 levels of       1 level of       1 level of
          Hierarchy            administration  administration    administration   administration
   27     Administration             Passed     Did not pass      Did not pass     Did not pass
          Login Identification
   28     Conference              Passed        Did not pass     Did not pass     Did not pass
          Countdown To
          Termination
Figure 2. Security and Authentication Test Results (continued)


 Test #        Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100        400 MCU          16+16
   29     Transcoding           12 of 12      3 of 12         2 of 12      2 of 12
          Bandwidths
   30     Transcoding Video        3 of 3            2 of 3          2 of 3           2 of 3
          Protocols
   31     Transcoding Video        3 of 3            1 of 3          2 of 3           2 of 3
          Formats
   32     Transcoding Audio        6 of 6            6 of 6          4 of 6           4 of 6
          Algorithms
   33     Transcoding All         62 of 62          3 of 62         2 of 62          2 of 62
   34     Mixed Protocol            Passed       Did not pass    Did not pass     Did not pass
          Conference
          Application Layer
   35     Mixed Conference          Passed       Did not pass    Did not pass        Passed
          Presentation Layer
Figure 3. Versatility - Transcoding Test Results

 Test #        Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100        400 MCU           16+16
   36     T.120 Support           Passed      Passed        Did not pass Did not pass
          Datasheet
          comparison
   37     Standard H.239            Passed          Passed       Did not pass        Passed
          Support Datasheet
          comparison
Figure 4. Versatility – Data and Content Test Results

            Multipoint Conferencing Unit Comparative Study                                         6
Test #         Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                   100        400 MCU           16+16
   38     Configurable             Passed    Did not pass    Did not pass Did not pass
          Automatic Layout
          Selection
   39     Private Layout            Passed       Did not pass     Did not pass      Did not pass
   40     Chairperson               Passed       Did not pass     Did not pass      Did not pass
          Layout Change
   41     Virtual Classroom         Passed       Did not pass     Did not pass      Did not pass
   42     Broadcast Mode            Passed       Did not pass     Did not pass      Did not pass
   43     CNN CP View               Passed         Passed         Did not pass      Did not pass
Figure 5. Versatility – Continuous Presence Test Results

 Test #         Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                   100        400 MCU          16+16
   44     Conference DID           Passed      Passed          Passed      Passed
          Number Routing
   45     Different Number          Passed       Did not pass     Did not pass      Did not pass
          Conference ID
          Routing
   46     Participant               Passed       Did not pass     Did not pass      Did not pass
          Number Routing
Figure 6. Versatility – Conference Routing Test Results

 Test #         Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                   100        400 MCU           16+16
   47     Operator                 Passed    Did not pass    Did not pass Did not pass
   48     Scheduled                Passed      Passed          Passed       Passed
   49     Ad-hoc Dialing           Passed      Passed        Did not pass Did not pass
   50     Ad-hoc Predefined        Passed    Did not pass    Did not pass Did not pass
          Dialing
Figure 7. Versatility – Conference Type Test Results

 Test #         Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                   100        400 MCU           16+16
   51     Music On Hold            Passed    Did not pass    Did not pass Did not pass
          Detection
   52     Resource                  Passed       Did not pass      Did not pass      Did not pass
          Management
   53     Resource Reset            Passed       Did not pass      Did not pass      Did not pass
   54     Multi System View 3 of 3 parameters 0 of 3 parameters 1 of 3 parameters 1 of 3 parameters
   55     Integrated                Passed       Did not pass      Did not pass      Did not pass
          Gateway
   56     Simultaneous              Passed          Passed         Did not pass      Did not pass
          Conferences
Figure 8. Versatility – Resource Management Test Results




             Multipoint Conferencing Unit Comparative Study                                           7
Test #        Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100        400 MCU           16+16
   57     IVR Variations          Passed    Did not pass    Did not pass Did not pass
   58     Multi-language         Passed    Did not pass    Did not pass Did not pass
          Company 
          Greeting Entry
          Queue
Figure 9. Versatility – Customization Test Results

 Test #        Name          Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100        400 MCU           16+16
   59    Administration           Passed    Did not pass    Did not pass Did not pass
         Login Identification
   60    Multiple Admin         3 levels of    2 levels of      1 level of      1 level of
         Profiles             administration administration  administration   administration
   61    Multi-language            Passed    Did not pass    Did not pass     Did not pass
         Company 
         Greeting Entry
         Queue
   62    Single                     Passed    Did not pass    Did not pass    Did not pass
         Management
         Interface
   63    Conference                 Passed    Did not pass    Did not pass    Did not pass
         Filtering – Faulty
         Connection
   64    Conference                 Passed    Did not pass    Did not pass    Did not pass
         Filtering –
         Participants
         Requesting
         Assistance
   65    Conference                 Passed    Did not pass    Did not pass    Did not pass
         Filtering – Noisy
         Line
   66    Automatic Mute             Passed    Did not pass    Did not pass    Did not pass
         On Music
         Detection
   67    View Individual            Passed    Did not pass       Passed          Passed
         Capabilities
Figure 10. Operation and Control – System Management Test Results

 Test #        Name         Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS
                                  100            400 MCU        16+16
   68    Ad-hoc Dialing           Passed          Passed     Did not pass Did not pass
   69    Single Number per        Passed          Passed       Passed       Passed
         Conference
   70    Single Number For        Passed        Did not pass Did not pass Did not pass
         All Conferences
   71    Personalized             Passed        Did not pass Did not pass Did not pass
         Conference
Figure 11. Operation and Control – User Control Test Results




            Multipoint Conferencing Unit Comparative Study                                     8
Security and Administration Testing
The Security and Administration test cases focus on determining the product’s ability to provide a maximum
level of conference security through the set of features provided by the MCU under test. Additionally, these
tests address the set of features provided by the MCU to perform administrative control remotely.

Test case 1 - Conference Password
In this test case, we determined if the MCU illustrated increased conference security by protecting entry to a
conference by the use of a password. To prove this capability, we created a conference definition with a
conference password. We then dialed into and out of the conference checking to ensure that the MCU
prompted us for a password for each type of connection.

Polycom MGC-100 - Passed
Using the administration console, we were able to create a conference that was password protected. We
dialed into the conference and the Polycom MCU prompted us for a password. We then dialed out to a
second endpoint and once again, the MCU prompted us for a password. This test proved that this security
feature worked for both dial in and dial out conditions.

RADVISION viaIP 400 MCU - Passed
Using the administration console, we were able to create a conference that was password protected. We
dialed into the conference and the RADVISION MCU prompted us for a password. We then dialed out to a
second endpoint and once again, the MCU prompted that endpoint for a password. This test proved that this
security feature worked for both dial in and dial out conditions.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we were able to create a conference that was password protected. We
dialed into the conference and the TANDBERG 16+16 MCU prompted us for a password. We then dialed out
to a second endpoint; however, when that participant answered the endpoint, the MCU did not request a
password. The MCU placed the endpoint into the conference regardless. This test proved that this security
feature worked for dial in connections but not for dial out connections.

TANDBERG MPS - Did not pass
Using the administration console, we were able to create a conference that was password protected. We
dialed into the conference and the TANDBERG MPS prompted us for a password. We then dialed out to a
second endpoint; however, when that participant answered the endpoint, the MCU did not request a
password. The MCU placed the endpoint into the conference regardless. This test proved that this security
feature worked for dial in connections but not for dial out connections.


Test case 2 - Password Hierarchy
In this test case, we determined if the MCU illustrated increased conference security by facilitating entry into a
conference using a password hierarchy. Permitting access into a conference using multiple passwords allows
the MCU to provide greater conference security by granting or denying access to additional services based on
the password profile supplied to enter the conference. To prove this capability, we created a conference
definition granting additional privileges to the chairperson or leader password profile to that of the participant
password profile. We then dialed into the conference using each password profile to confirm that entry was
possible using a password hierarchy and that each profile afforded differing levels of functionality.

Polycom MGC-100 - Passed
Using the administration console, we were able to create a conference with a chairperson and a participant
password. Using the MCU configuration menu we selected an IVR Message Service that we used for this
test. We then dialed into the conference using the participant password from one endpoint and then dialed
into the same conference using the chairperson password from another endpoint. To ensure that we had
dialed into the conference with differing levels of permissions, we were able to mute all endpoints using DTMF
codes from the endpoint where the chairperson’s password was entered and were unable to do this on the
endpoint where the participant’s password was entered. This test proved that this password hierarchy test
passed successfully.

              Multipoint Conferencing Unit Comparative Study                                                     9
RADVISION viaIP 400 MCU - Did not pass
Using the administration console, we were able to create a conference with a chairperson and a participant
password. However, when we dialed into the conference, we were able to log in as the participant only. When
we attempted to dial into the conference as the chairperson, the RADVISION MCU generated an operator
recording stating that we had entered an invalid password. We later found that the chairperson password is to
be used to enter the administration console with special permissions, not to enter a specific conference with
chairperson privileges. This test proved that this password hierarchy test did not pass.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we found that the TANDBERG MCU 16+16 allowed us to create only one
password per conference. This test proved that this password hierarchy test did not pass.

TANDBERG MPS – Did not pass
Using the administration console, we found that the TANDBERG MPS allowed us to create only one
password per conference. This test proved that this password hierarchy test did not pass.



Test case 3 - Privilege Profiles
In this test case, we determined if the MCU illustrated increased conference security being capable of
assigning multiple instances of contrasting levels of in-conference functionality or privilege profiles using a
single conference definition. To prove this capability, we created a single conference definition and confirmed
that the chairperson or leader received different in-conference capabilities to that of the participant. Using the
same conference definition, a second conference was created that used a different privilege profile. We then
connected another chairperson or leader and participant to confirm that a completely different set of in-
conference privileges were available.

Polycom MGC-100 - Passed
Using the administration console, we were able to create a conference with a chairperson and a participant.
We were able to make these changes by going to the MCU configuration menu and selecting IVR Msg
Services, and then a specific IVR Message Service that we used for this test. We dialed into the conference
as a participant using one endpoint and then dialed into the conference as a chairperson using another
endpoint. To ensure that we had dialed into the conference with different permissions, we were able to mute
all endpoints using DTMF codes on the chairperson endpoint, and unable to do this on the participant
endpoint. We then created a second conference using the same conference definition and confirmed that a
different profile was active. This test proved that this privilege profile test passed successfully.

RADVISION viaIP 400 MCU - Did not pass
Using the administration console, we were able to create a conference with a chairperson and a participant.
However, when we dialed into the conference, we were able to log in as the participant only. When we
attempted to dial into the conference as the chairperson, the RADVISION MCU generated an operator
recording stating that we had entered an invalid password. We were unable to mute all other participants from
an endpoint for two reasons: 1.) all of the conference endpoints did not have sufficient privileges to mute all
other participants, and 2.) we were unable to find DTMF codes that would allow an endpoint to mute all other
endpoint in a conference. However, we found that all endpoints could be muted by using the RADVISION
MCU administration console. The inability to pass this test proved that the privilege profile test did not pass.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we created a conference with one level of password hierarchy (See Test 2).
We then dialed into the conference and were unable to find functionality to enable or restrict differing levels of
functionality. We found that we were required to have access to the TANDBERG MCU 16+16 administration
console to perform chairperson privileges, such as muting other participants. The inability to pass this test
proved that the privilege profile test did not pass.

TANDBERG MPS - Did not pass


              Multipoint Conferencing Unit Comparative Study                                                    10
Using the administration console, we created a conference with one level of password hierarchy (See Test 2).
We then dialed into the conference and were unable to find functionality to enable or restrict differing levels of
functionality. We found that we were required to have access to the TANDBERG MPS administration console
to perform chairperson privileges, such as muting other participants. The inability to pass this test proved that
the privilege profile test did not pass.


Test case 4 - Automatic Password Generation
In this test case, we determined if the MCU illustrated increased conference security being capable of
automatically generating passwords. Automatic password generation increases conference security ensuring
that every conference is password protected, complies with password integrity checks, and ensures password
uniqueness. To prove this capability, we created a conference with no password and validated whether a
password was automatically generated based on the condition of no password supplied.

Polycom MGC-100 - Passed
Using the administration console, we were able to create a password-protected conference. When we
attempted to create a conference with no password, the Polycom MCU overrode this option and automatically
assigned randomized passwords for both the chairperson and participants

RADVISION viaIP 400 MCU - Did not pass
Using the administration console, we were able to create a password-protected conference. The RADVISION
MCU did not generate a random password, so we were required to enter a password. The MCU allowed
single character passwords, so there did not appear to be any password integrity checks on the entered
password. The inability to pass this test proved that the automatic password generation test did not pass.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we were able to create a password-protected conference. The MCU did not
generate a random password, so we were required to enter a password. The MCU allowed single character
passwords, so there did not appear to be any password integrity checks on the entered password. The
inability to pass this test proved that the automatic password generation test did not pass.

TANDBERG MPS - Did not pass
Using the administration console, we were able to create a password-protected conference. The MCU did not
generate a random password, so we were required to enter a password. The MCU allowed single character
passwords, so there did not appear to be any password integrity checks on the entered password. The
inability to pass this test proved that the automatic password generation test did not pass.


Test case 5 - Password Integrity Validation
In this test case, we determined if the MCU illustrated increased conference security by applying a password
integrity check, checking that all passwords meet a minimum or maximum password length specified by the
MCU. To prove this capability, we validated whether or not the MCU under test checked, validated, or
rejected passwords entered from the endpoint. We dialed into a password-protected conference and
attempted to enter a password.

Polycom MGC-100 - Passed
Upon creation of conference, we got a dialog that stated “status =
STATUS_ILLEGAL_PASSWORD_LENGTH”. The conference required four or more numeric characters for a
valid password.

RADVISION viaIP 400 MCU - Did not pass
Created a conference with a service that had password required. When password required was enabled, we
were able to enter with passwords of only one character in length. There appeared to be no custom minimum
limit to the password size.

TANDBERG MCU 16+16 - Did not pass
We were able to create a conference with a password with only one character.

              Multipoint Conferencing Unit Comparative Study                                                   11
TANDBERG MPS - Did not pass
We were able to create a conference with a password with only one character.


Test case 6 - Conference Password String Validation
In this test case, we determined if the MCU illustrated increased conference security by validating the
password as a complete string. To prove this capability, we created a conference with a password of “12345.”
We then entered the conference with the password of “1234567” and reported whether or not we could
connect to the conference.

Polycom MGC-100 - Passed
Using the administration console, we created a password-protected conference using a password of “12345.”
We then used an endpoint to dial into the conference. The Polycom MCU prompted us to enter the
conference password, followed by a “#” sign. Requiring the endpoint to terminate the password with the “#”
sign allows the Polycom MCU to match exact string matches. We entered a password of “1234567” and the
MCU denied our entry into the conference due to providing the wrong password. The rejection of the incorrect
password string proved that the conference password string validation test passed.

RADVISION viaIP 400 MCU - Passed
Using the administration console, we created a password-protected conference using a password of “12345.”
We then used an endpoint to dial into the conference. The RADVISION MCU prompted us to enter the
conference password, followed by a “#” sign. Requiring the endpoint to terminate the password with the “#”
sign allows the RADVISION MCU to match exact string matches. We entered a password of “1234567” and
the MCU denied our entry into the conference due to providing the wrong password. The rejection of the
incorrect password string proved that the conference password string validation test passed.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we created a password-protected conference using a password of “12345.”
We then used an endpoint to dial into the conference. The TANDBERG MCU prompted us to enter the
conference password. The TANDBERG MCU did not prompt us to terminate the password with the "#" sign,
or some other termination key. We entered a password of “1234567” and the MCU connected us to the
conference. Additionally, when we dialed "9871234567" as the password, we were connected to the
conference apparently because the password string "12345" exists somewhere in the string we entered. We
found that the MCU remains open accepting password characters. If any substring is entered that matches
the expected password string, then the endpoint is entered into the conference. The ability to enter a
conference with an incorrect password proved that the conference password string validation test did not
pass.

TANDBERG MPS - Did not pass
Using the administration console, we created a password-protected conference using a password of “12345.”
We then used an endpoint to dial into the conference. The TANDBERG MCU prompted us to enter the
conference password. The TANDBERG MCU did not prompt us to terminate the password with the "#" sign,
or some other termination key. We entered a password of “1234567” and the MCU connected us to the
conference. Additionally, when we dialed "9871234567" as the password, we were connected to the
conference apparently because the password string "12345" exists somewhere in the string we entered. We
found that the MCU remains open accepting password characters. If any substring is entered that matches
the expected password string, then the endpoint is entered into the conference. The ability to enter a
conference with an incorrect password proved that the conference password string validation test did not
pass.


Test case 7 - Change Conference Password during a Conference
In this test case, we determined if the MCU illustrated increased conference security by allowing a password
assigned to a conference to be changed by an endpoint during an ongoing conference. To prove this
capability, we created a conference with a password of “2222.” We then entered the conference and changed
the password to “3333.” We then attempted to have a new endpoint join. We validated failure by typing “2222”

             Multipoint Conferencing Unit Comparative Study                                               12
to ensure that we could not connect to the updated conference and also validated success by typing “3333” to
ensure that we could connect to the conference.

Polycom MGC-100 - Passed
Using the administration console, we created a password-protected conference with a password of “2222.”
We used an endpoint to dial into the conference and entered “2222” when prompted for the password. We
then entered *77, the DTMF code to change the conference password, and changed the password to “3333.”
We then had a second endpoint dial into the conference. We tried entering the conference by entering the
password “2222,” were rejected from the conference, and asked to re-enter the password. We entered “3333”
this time and were connected to the conference. The rejection of the incorrect password string and
acceptance of the updated password proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
Using the administration console, we created a password-protected conference with a password of “2222.”
We used an endpoint to dial into the conference and entered “2222” when prompted for the password. We
were unable to use DTMF codes at the endpoint to change the password. Although the RADVISION MCU
manual says that the MCU can use DTMF codes, we were unable to get a response from the MCU using
DTMF codes. We were unable to find a parameter setting in the administration console to change this
features. The inability to change the password within a conference proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU documentation, we were unable to find any information
regarding using DTMF codes to administer the TANDBERG 16+16 MCU from an endpoint. We confirmed that
DTMF codes, with the exception of password provision, are not supported on the TANDBERG MCU. We were
unable to connect to the conference since it was locked. We were also unable to change the conference
password during the conference via the administration console; however, the password string field was
disabled. The inability to support DTMF codes to support this feature proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MCU documentation, we were unable to find any information
regarding using DTMF codes to administer the TANDBERG MPS from an endpoint. We confirmed that DTMF
codes, with the exception of password provision, are not supported on the TANDBERG MCU. We were
unable to connect to the conference since it was locked. We were also unable to change the conference
password during the conference via the administration console; however, the password string field was
disabled. The inability to support DTMF codes to support this feature proved that this test did not pass.


Test case 8 - Conference Lock
In this test case, we determined if the MCU illustrated increased conference security by allowing an on going
conference to be locked to deny access to any further connections. To prove this capability, we created a
conference, then entered and locked the conference to stop further participants joining. We then attempted to
dial into the conference to confirm that further entry was not allowed.

Polycom MGC-100 - Passed
Using the administration console, we created a conference. We used an endpoint to dial into the conference.
We then locked the conference using DTMF codes (*70) and then, using a second endpoint, we dialed into
the conference. We were unable to connect to the conference since it was locked. The inability to connect to
a locked conference proved that this test passed.

RADVISION viaIP 400 MCU - Passed
Using the administration console, we created a conference. We used an endpoint to dial into the conference.
We then locked the conference using the administration console and then, using a second endpoint, we
dialed into the conference. We were unable to connect to the conference since it was locked. The inability to
connect to a locked conference proved that this test passed.

TANDBERG MCU 16+16 - Passed


             Multipoint Conferencing Unit Comparative Study                                                13
Using the administration console, we created a conference. We used an endpoint to dial into the conference.
We disabled the Allow Incoming Calls checkbox using the administration console and then, using a second
endpoint, we dialed into the conference. The inability to connect to a locked conference proved that this test
passed.

TANDBERG MPS - Passed
Using the administration console, we created a conference. We used an endpoint to dial into the conference.
We disabled the Allow Incoming Calls checkbox using the administration console and then, using a second
endpoint, we dialed into the conference. The inability to connect to a locked conference proved that this test
passed.


Test case 9 - Conference Hide
In this test case, we determined if the MCU illustrated increased conference security by allowing an on going
conference to be secured so that it cannot be monitored by any application or interface. To prove this
capability, we created a conference, then entered the conference and secured the conference so that it
cannot be monitored any application or interface. We then attempted to view the conference in the
administration console.

Polycom MGC-100 - Passed
Using the administration console, we created a conference. We used an endpoint to dial into the conference.
We then locked the conference using DTMF codes (*71). We then attempted to view the conference in the
Polycom MCU administration console and could not see any information related to this call. The inability to
view this hidden conference proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
Using the administration console and the RADVISION MCU documentation, we were unable to find any
information to suggest that allowed us to hide conferences on the RADVISION MCU. The lack of a hide
conference feature proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
Using the administration console and the TANDBERG 16+16 MCU documentation, we were unable to find
any information to suggest that allowed us to hide conferences on the TANDBERG 16+16 MCU. The lack of a
hide conference feature proved that this test did not pass.

TANDBERG MPS - Did not pass
Using the administration console and the TANDBERG MPS documentation, we were unable to find any
information to suggest that allowed us to hide conferences on the TANDBERG MPS. The lack of a hide
conference feature proved that this test did not pass.


Test case 10 - Automatic Conference Termination – no show
In this test case, we determined if the MCU illustrated increased conference security by terminating a
conference if no connections are made within a set number of minutes from the start of the conference. We
created a conference to terminate after two minutes before the first connection. We then used the
administration console to confirm that conference terminated after two minutes had elapsed.

Polycom MGC-100 - Passed
We created a conference definition with Auto-termination enabled. We set the termination time to be two
minutes. We created the conference and let it sit idle for two minutes. We observed the conference terminate
via the MGC Manager console. The confirmation of the terminated conference proved that this test passed.

RADVISION viaIP 400 MCU - Passed
We created a conference with termination after no show using the advanced options. We set the termination
time to be two minutes. We created the conference and let it idle for two minutes. We observed the
conference terminate via the RADVISION administration console. The confirmation of the terminated
conference proved that this test passed.

             Multipoint Conferencing Unit Comparative Study                                                 14
TANDBERG MCU 16+16 - Did not pass
We created a conference with the Max Call Duration set to one minute. The conference displayed this
information in the conference summary window. Once a participant called into the conference, a timer was set
to allow a conference of 1-minute maximum. After one minute, the participant was silently disconnected. The
conference remained created. If another participant called into the conference, the clock would reset and
allow that participant to join that conference for one minute. The TANDBERG MCU is designed to terminate
the conference call, but to leave the conference running for future connections. Regardless, the only manner
to terminate a conference is by manually terminating it with the administration console. The inability to have a
conference terminate by conference timeout confirms that this test did not pass.

TANDBERG MPS - Did not pass
We created a conference with the Max Call Duration set to one minute. The conference displayed this
information in the conference summary window. Once a participant called into the conference, a timer was set
to allow a conference of 1-minute maximum. After one minute, the participant was silently disconnected. The
conference remained created. If another participant called into the conference, the clock would reset and
allow that participant to join that conference for one minute. The TANDBERG MPS MCU is design to
terminate the conference call, but to leave the conference running for future connections. Regardless, the
only manner to terminate a conference is by manually terminating it with the administration console. The
inability to have a conference terminate by conference timeout confirms that this test did not pass.


Test case 11 - Automatic Conference Termination – after last person
In this test case, we determined if the MCU illustrated increased conference security by terminating a
conference after the last person leaves the conference. We created a conference to terminate one minute
after the last person leaves the conference. We then used the administration console to confirm that
conference terminated one minute after the last person left.

Polycom MGC-100 - Passed
We created a conference definition with Auto-termination enabled. We set the termination time to be one
minute after the last person leaves. We created the conference, dialed into it, disconnected from it, and then
let it sit idle for one minute. We observed the conference terminate via the MGC Manager console. The
confirmation of the terminated conference proved that this test passed.

RADVISION viaIP 400 MCU - Passed
We created a conference with the administration console setting to terminate after last participant leaves. We
created the conference, dialed into it, disconnected from it, and then let it sit idle for one minute. After one
minute, the conference terminated on its own. The confirmation of the terminated conference proved that this
test passed.

TANDBERG MCU 16+16 - Did not pass
We created a conference with the administration console. We noticed that the TANDBERG MCU only allowed
the overall length of a conference call to be pre-determined. After reviewing the product and the TANDBERG
MCU documentation, we determined that we must terminate all conferences manually. The failure to
terminate the conference automatically proved that this test did not pass.

TANDBERG MPS - Did not pass
We created a conference with the administration console. We noticed that the TANDBERG MCU only allowed
the overall length of a conference call to be pre-determined. After reviewing the product and the TANDBERG
MCU documentation, we determined that we must terminate all conferences manually. The failure to
terminate the conference automatically proved that this test did not pass.


Test case 12 - Automatic Conference Termination – after chairperson profile exits
In this test case, we determined if the MCU illustrated increased conference security by terminating a
conference after the chairperson profile exits the conference. We created a conference to terminate after the
chairperson profile exits the conference. We then dialed into the conference as the chairperson, and dialed in

              Multipoint Conferencing Unit Comparative Study                                                  15
with a separate endpoint as a participant. We then had the chairperson exit the conference. We used the
administration console to confirm that conference terminated after the chairperson exited the conference.

Polycom MGC-100 - Passed
We created a conference definition with Terminate after Chairperson Exits enabled. We created the
conference, dialed into it as the chairperson, and dialed into it as a participant. We then disconnected the
chairperson from the conference and waited to ensure that the conference terminated. The confirmation of the
terminated conference proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we determined that the first
participant into a conference creates the conference instance. Therefore, when this participant exits the
conference, the conference terminates. We also found no distinction between participant and chairperson in
the conference. Based on the previous reasons, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any
information regarding establishing a hierarchy of conference privileges; therefore, it cannot detect the
difference between a chairperson dialing into a conference versus a participant dialing into a conference. We
also determined that all conferences must be terminated manually. Based on the previous reasons, we
proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any
information regarding establishing a hierarchy of conference privileges; therefore, it cannot detect the
difference between a chairperson dialing into a conference versus a participant dialing into a conference. We
also determined that all conferences must be terminated manually. Based on the previous reasons, we
proved that this test did not pass.


Test case 13 - Conference Termination – during a conference
In this test case, we determined if the MCU illustrated increased conference security by allowing a conference
to be instantaneously terminated during an ongoing conference. To prove this capability, we created a
conference and had three endpoints dial into the conference as participants. From one of the endpoints, we
entered the DTMF code to terminate the conference. We used the administration console to confirm that
conference terminated.

Polycom MGC-100 - Passed
Using the administration console, we created a conference. We used three endpoints to dial into the
conference as participants. Using one endpoint, we then terminated the conference using DTMF codes (*87).
We monitored the conference in the Polycom MCU administration console. The Polycom MCU deleted the
conference from the console. The termination of this conference from the console proved that this test
passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we determined that there were
no DTMF commands that allow an endpoint to terminate the conference. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we determined that this product
did not support DTMF codes with the exception of password provision. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass




             Multipoint Conferencing Unit Comparative Study                                                 16
After a thorough search of the TANDBERG MCU product and documentation, we determined that this product
did not support DTMF codes with the exception of password provision. Based on this lack of feature
capability, we proved that this test did not pass.


Test case 14 - Conference Requires Chairperson to Start
In this test case, we determined if the MCU illustrated increased conference security by allowing a conference
to start only when the chairperson present. To prove this capability, we created a conference that requires the
chairperson to start. From one of the endpoints, we dialed into the conference as a participant. If the endpoint
was put on hold, we then used another endpoint and dialed into the conference as a chairperson. If both
endpoints entered the conference, then we would know that the conference required a chairperson to start

Polycom MGC-100 - Passed
We created a conference with Start Conf Requires Chairperson enabled. We dialed into the conference as a
participant and were put on hold. We then used a separate endpoint and dialed into the conference as the
chairperson. At this point, the conference started, and thus proved the start of this test.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we determined that this product
was unable to create a conference where participants are put on hold until the chairperson enters the
conference. Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
The TANDBERG MCU does not support a chairperson or leader privileges; therefore, the conference cannot
detect when a chairperson or leader enters the conference. Based on this lack of feature capability, we
proved that this test did not pass.

TANDBERG MPS - Did not pass
The TANDBERG MPS does not support a chairperson or leader privileges; therefore, the conference cannot
detect when a chairperson or leader enters the conference. Based on this lack of feature capability, we
proved that this test did not pass.


Test case 15 - Participant Identification – entering a conference
In this test case, we determined if the MCU illustrated increased conference security by prompting each
connection to a conference to record their name which will be replayed to announce their entry in to the
conference. To prove this capability, we created a conference with identification required. From one endpoint,
we dialed into the conference and verified that it prompted for our name upon entering a conference.

Polycom MGC-100 - Passed
We created a conference with IVR settings set to rollcall enabled. We dialed into the conference with one
endpoint and were prompted for our name before entering the conference. At this point, the conference
started, and thus proved the start of this test.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we were unable to create a
conference that prompted us for our name upon entering the conference. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
The TANDBERG MCU does not support prompting for participant names. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass
The TANDBERG MPS does not support prompting for participant names. Based on this lack of feature
capability, we proved that this test did not pass.


              Multipoint Conferencing Unit Comparative Study                                                 17
Test case 16 - Participant Identification – leaving a conference
In this test case, we determined if the MCU illustrated that when a connection to a conference is terminated,
the name recorded prior to entry will announce its departure. To prove this capability, we created a
conference with identification required. From two endpoints, we dialed into the conference and when
prompted, we announced our name. We then disconnected one endpoint from the conference and verified
that the other conference connection received the announcement of leaving the conference.

Polycom MGC-100 - Passed
Using the administration console, we created a conference with Roll Call enabled in the IVR settings. We
connected to the conference using two endpoints. Upon entering the conference, we were prompted for our
names, which we entered as instructed. We then had one of the endpoints disconnect for the conference. The
name of the disconnecting endpoint was then announced to the conference as was heard by the remaining
endpoint. The ability to hear the disconnecting endpoint proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
Using the administration console, we created a conference. However, we were unable to create conference
that would prompt for participant identification upon entering the conference call. Since participant
identification is not taken during the conference, the RADVISION MCU is unable to provide automatic
participant identification upon leaving the conference. Based on this lack of feature capability, we proved that
this test did not pass.

TANDBERG MCU 16+16 - Did not pass
Using the administration console, we created a conference. However, we were unable to create conference
that would prompt for participant identification upon entering the conference call. We were able to find a
capability for a tone upon exiting the call. Since participant identification is not taken during the conference,
the TANDBERG MCU is unable to provide automatic participant identification upon leaving the conference.
Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass
Using the administration console, we created a conference. However, we were unable to create conference
that would prompt for participant identification upon entering the conference call. We were able to find a
capability for a tone upon exiting the call. Since participant identification is not taken during the conference,
the TANDBERG MPS is unable to provide automatic participant identification upon leaving the conference.
Based on this lack of feature capability, we proved that this test did not pass.


Test case 17 - Automatic Participant Identification by Name
In this test case, we determined if the MCU illustrated increased conference security by identifying each
participant by name when entering a conference. To prove this capability, we created a conference and
connected one endpoint to the conference. Using the administration console, we monitored the connection of
a participant into a conference and confirmed that the identification of the participant by name and was
consistent with the actual endpoint that entered the conference.

Polycom MGC-100 - Passed
Using the administration console, we created a conference. We then used an endpoint to dial into the
conference. The Polycom MCU prompted us to enter the conference identification and password. Once
accepted into the conference, the MCU detected and identified the connection by name. The Polycom MCU
performs this function by storing information about the participant in a local Access database managed by the
Polycom administration console. The ability to provide this information proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we were unable to find any
information regarding the ability to use a conference ID and password to identify the endpoint participant.
Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass

              Multipoint Conferencing Unit Comparative Study                                                        18
After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any
information regarding the ability to use a conference ID and password to identify the endpoint participant by
name. Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MPS - Final
After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any
information regarding the ability to use a conference ID and password to identify the endpoint participant by
name. Based on this lack of feature capability, we proved that this test did not pass.


Test case 18 - Roll Call
In this test case, we determined if the MCU illustrated increased conference security by being able to replay
all the names recorded prior to entering a conference, during the conference. To prove this capability, we
created a conference with identification required. From two endpoints, we dialed into the conference. From
one endpoint, we then requested a roll call of all connected endpoints.

Polycom MGC-100 - Passed
We created a conference definition with Roll Call enabled in the IVR settings. We created the conference and
dialed into it as a participant. The MCU prompted us to enter our name, followed by the “#” sign. We followed
these instructions and we were entered into the conference. We connected to the conference call using an
additional endpoint but with a different name. From one of the endpoints, we selected the DTMF code (*33) to
request a roll call of all participants. We received the roll call announcement. The confirmation of the roll call
proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we were unable to create a
conference that prompted us for names at the start of the conference, and use these names for a manual roll
call. Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we were unable to create a
conference that prompted us for names at the start of the conference, and use these names for a manual roll
call. Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we were unable to create a
conference that prompted us for names at the start of the conference, and use these names for a manual roll
call. Based on this lack of feature capability, we proved that this test did not pass.


Test case 19 - Automatic Dial Out
In this test case, we determined if the MCU illustrated increased conference security by enabling the
conference to automatically connect predefined participants when initiated. To prove this capability, we
created a conference with predefined participants. Using an endpoint, we called into the conference and
determined if the predefined participants received a call from the conference

Polycom MGC-100 - Passed
We created a conference definition with two predefined participants. We dialed into the conference and the
MCU immediately dialed out to the two predefined participant endpoints. The confirmation of the predefined
call proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
Although the conference can define specific invites for a conference call, the conference will not automatically
dial out to them when the call is initiated by the chair. From the endpoint, we can invite another endpoint by
typing Conference prefix and ID + ** + the endpoint that we want to invite.

TANDBERG MCU 16+16 - Did not pass

              Multipoint Conferencing Unit Comparative Study                                                    19
The TANDBERG 16+16 MCU allows the administrator to create a conference and add participants. It will start
this conference and dial out immediately once the conference is created. However, since the conference is
created well before a call is desired to start or it’s scheduled start time, it cannot respond to a call leader
starting the call and respond by calling out to conference participants.

TANDBERG MPS - Did not pass
The TANDBERG MPS allows the administrator to create a conference and add participants. It will start this
conference and dial out immediately once the conference is created. However, since the conference is
created well before a call is desired to start or it’s scheduled start time, it cannot respond to a call leader
starting the call and respond by calling out to conference participants.


Test case 20 - Operator Assisted Routing
In this test case, we determined if the MCU illustrated increased conference security by allowing participants
to be acknowledged and vetted first by a video operator before being manually placed into the destination
conference. To prove this capability, we created a conference that required operator assistance. Using one
endpoint, we created an operator conference. We then attempted to dial into the conference from a second
endpoint and verified that an operator attended the call and placed us in our targeted conference.

Polycom MGC-100 - Passed
We first created an operator conference. To create an attended wait, we selected Msg Service Type to be
Attended (Wait). We then dialed into the conference as a participant and requested assistance. The attendant
monitored our assistance request using the administration console and moved us into the requested
conference. The confirmation of the ability to get routed to the correct conference via operator assistance
proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we found that for operator
assistance, the participant must dial the operator number. The documentation states to "Enter the number of
the delegated operator which the MCU dials when the operator invitation selected in the Conference Control
interface during a conference. The operator is invited to join the conference for consultation and to provide
support.” For this action to work as desired, the calling participant must call from within a conference;
therefore, it cannot make a call to an operator for routing assistance. The confirmation of the inability to get
routed to the correct conference via operator assistance proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG
MCU does not support operator assistance of any sort. Based on this lack of feature capability, we proved
that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG
MPS does not support operator assistance of any sort. Based on this lack of feature capability, we proved that
this test did not pass.


Test case 21 - Request Private Operator Assistance
In this test case, we determined if the MCU illustrated increased conference security by allowing a participant
to request private operator assistance during a conference. Once acknowledged, the requesting participant
and operator can hear and see each other in complete privacy before being placed back into the original
conference. To prove this capability, we created and started a conference that provided operator assistance.
Using one endpoint, we created an operator conference. We then dialed into the conference from a second
endpoint, requested assistance, and then rejoin the conference.

Polycom MGC-100 - Passed
We first created an operator conference and dialed into the operator conference. We then created a new
conference and dialed into as a participant. We used the DTMF code to be taken out of the conference and

              Multipoint Conferencing Unit Comparative Study                                                      20
request assistance. The DTMF code we used was *0. We then waited for the operator for assistance. Once
the operator became available and saw our request on the administration console, we were taken into a
private conference with the operator and then moved back into the destination conference. The confirmation
of the ability to receive private operator assistance proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
We first created a conference and dialed into the conference. We used the DTMF code to be taken out of the
conference and request assistance. The DTMF code we used was *0. When we used this DTMF code, we
were not taken out of the conference call and operator assistance was not raised on the administration
console. The confirmation of the inability to receive private operator assistance proved that this test did not
pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG
MCU does not support private operator assistance request of any sort. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG
MPS does not support private operator assistance request of any sort. Based on this lack of feature
capability, we proved that this test did not pass.


Test case 22 - Secure Breakout or Sidebar Session
In this test case, we determined if the MCU illustrated increased conference security by allowing any number
of conference participants to be moved securely and seamlessly from one conference to another and rejoined
without disconnection. Each conference is completely independent and secure of the original with video and
audio streams isolated to each conference. To prove this capability, we created and started several isolated
conferences. We added four participants to a conference. We separated two participants from the conference
without disconnection and validated that the audio and video streams were separate.

Polycom MGC-100 - Passed
We first created two conferences, conference 55 and 56, both with quad views. We dialed four endpoints into
conference 55. We then highlighted two of the endpoints in the administration console, right-clicked on them,
and selected to move them to conference 56. The two endpoints that we selected were moved to conference
56, so now there were two private conferences each with two participants. Confirmation of the ability to create
two private conferences from one conference without participant disconnection proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
We created two conferences. We dialed into one of the conferences with four endpoints. We were unable to
move the participants from one conference to another conference via the administration console. Additionally,
the DTMF code required to move the audio into a subconference (*71) did not move the participant into a
subconference. We were required to move the participant into the subconference via the management
console. Confirmation of the inability to create two private conferences from one conference without
participant disconnection proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG
MCU does not support conference separation or breakout of any sort. Based on this lack of feature capability,
we proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG
MPS does not support private operator assistance request of any sort. Based on this lack of feature
capability, we proved that this test did not pass.




              Multipoint Conferencing Unit Comparative Study                                                 21
Test case 23 - Decreasing Password Attempts
In this test case, we determined if the MCU illustrated increased conference security by restricting the number
of password attempts to enter a conference before being disconnected. Protecting a conference for example
with a single attempt of entering a password adds an additional level of security. To prove this capability, we
defined and started a conference with a single logon attempt. We dialed into the conference and entered an
incorrect password multiple times. We validated that the number of login attempts equaled the preset value.

Polycom MGC-100 - Passed
We first set the number of user input tries in the IVR Msg Services to three. We then created a conference
with this IVR setting. We attempted to dial into the conference three times using an incorrect password. After
the third attempt, the MCU automatically disconnected us from the conference queue. Confirmation of the
ability to set decreasing password attempts proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
When we used the RADVISION MCU, we were given three chances to enter the correct password before
being disconnected from the password entry queue. After a thorough search of the RADVISION MCU product
and documentation, we were unable to determine how to change the number of invalid password login
attempts. This product does provide security by limiting the number of invalid password attempts; however,
the inability to set decreasing password attempts proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
When we used the TANDBERG MCU, we were given a set fixed time and to enter a fixed number of
password entry attempts. We were unable to determine how to change the number of invalid password login
attempts or how to change the total available time to enter the password. This product does provide security
by limiting the number of invalid password attempts; however, the inability to set decreasing password
attempts proved that this test did not pass.

TANDBERG MPS - Did not pass
When we used the TANDBERG MPS, we were given a set fixed time and to enter a fixed number of
password entry attempts. We were unable to determine how to change the number of invalid password login
attempts or how to change the total available time to enter the password. This product does provide security
by limiting the number of invalid password attempts; however, the inability to set decreasing password
attempts proved that this test did not pass.


Test case 24 - Failed Conference Access
In this test case, we determined if the MCU illustrated increased conference security as any participants who
fail to enter a valid conference password for any reason would be automatically placed on hold. To prove this
capability, we defined and started a conference with a single logon attempt. We dialed into the conference,
entered an incorrect password, and waited to be put on hold. We used the administration console to identify
participants placed on hold pending operator assistance. We validated this test case by finding participants on
hold in the administration console and attending to them.

Polycom MGC-100 - Passed
We first created an operator assistance conference. We then created a standard conference and dialed into
this conference as a participant. We entered an invalid password and were placed in the operator queue on
the MCU. From the administration console, we were able to see the endpoint that was requesting assistance
and send this endpoint into the operator conference for assistance. Confirmation of the ability to be moved
into an operator assistance queue due to a did not pass conference access proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
We created a conference and dialed into this conference as a participant. We entered an invalid password
and were allowed to retry entering a correct password three times. We were then disconnected from the
conference. It appears that there is no administration console setting that allows us to have participants move
to operator assist upon a failed conference access. Confirmation of the inability to be moved into an operator
assistance queue due to a failed conference access proved that this test did not pass.


             Multipoint Conferencing Unit Comparative Study                                                  22
TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG 16+16 MCU product and documentation, we found that the
TANDBERG 16+16 MCU does not support a feature to put a participant on hold and assist them with
password problems. Based on this lack of feature capability, we proved that this test did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG
MPS does not support a feature to put a participant on hold and assist them with password problems. Based
on this lack of feature capability, we proved that this test did not pass.


Test case 25 - Secure Non-Password Conference
In this test case, we determined if the MCU illustrated increased security by forcing dial out systems to
acknowledge connection to the MCU with a DTMF tone when prompted. If no response is detected the
connection will be terminated, eliminating connection to endpoints where it may be set to auto answer, where
no one is present or to passive recording devices. To prove this capability, we defined and started a
conference with a dial out participant defined. If the endpoint failed to respond when prompted for a DTMF
tone, such as an answer machine might respond, then the MCU should disconnect that endpoint from the
conference.

Polycom MGC-100 - Passed
We defined a conference with a dial out participant defined. We created the conference and then dialed into
the conference using one of the endpoints. We then initiated the conference to dial out to the defined dial out
participant. The conference dialed out and waited for a response from the new endpoint. When it received no
response, then the conference disconnected the endpoint. Confirmation of the ability to disconnect an
insecure non-password endpoint proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint.
The conference dialed out and immediately connected the new endpoint. The conference connected to the
dialed endpoint regardless of whether the connecting party was the correct connection. Confirmation to
connect to unknown endpoints proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint.
The conference dialed out and immediately connected the new endpoint. The conference connected to the
dialed endpoint without DTMF code confirmation. Confirmation to connect to unknown endpoints proved that
this test did not pass.

TANDBERG MPS - Did not pass
We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint.
The conference dialed out and immediately connected the new endpoint. The conference connected to the
dialed endpoint without DTMF code confirmation. Confirmation to connect to unknown endpoints proved that
this test did not pass.


Test case 26 - Administration Hierarchy
In this test case, we determined if the MCU illustrated an administration hierarchy. This hierarchy is a set of
profiles that administrators can assign, or be assigned to, to enable or restrict access capabilities according to
their needs. Assigning administrators with different profiles and rights provides greater security to the overall
system. Using the administration console, we determined the number of levels of permissions that the
administration console allowed us to create.

Polycom MGC-100
After reviewing the Polycom MCU documentation, we found that the MGC Manager administration console
supported three levels of operators. They were:
    1. Attendant

              Multipoint Conferencing Unit Comparative Study                                                   23
2. Ordinary
     3. Superuser
The attendant operator can only define and manage new conferences, gateway sessions, meeting rooms,
and participants. The attendant operator does not have access to the MCU Configuration icon and MCU
Utilities. Ordinary operators can perform all the tasks an attendant operator does. In addition, ordinary
operators can also view the configurations of the modules in the MGC-100. Superuser operators can perform
all tasks attendant and ordinary operators do. In addition, superuser operators can define and delete other
operators, and define network services. While ordinary operators can view the configurations of the modules
in the MGC-100, only the superuser operator can modify the configuration of a module.

RADVISION viaIP 400 MCU
After reviewing the RADVISION MCU documentation, we found that the RADVISION system allowed two
levels of access privileges. They were:
    1. Chair controller
    2. User

Additionally, the system offers two levels of console management. They were:
   1. Operator
   2. Administrator

TANDBERG MCU 16+16
After reviewing the RADVISION MCU documentation, we found that the TANDBERG 16+16 MCU could not
assign different levels of privileges to call participants. We found only one level of administration level.




Figure 12. TANDBERG 16+16 MCU System Configuration, Miscellaneous Configuration dialog box

TANDBERG MPS
After reviewing the RADVISION MPS documentation, we found that the TANDBERG MPS could not assign
different levels of privileges to call participants. We found only one level of administration level.




             Multipoint Conferencing Unit Comparative Study                                                24
Figure 13. TANDBERG MPS MCU System Configuration, Miscellaneous Configuration Settings dialog
box


Test case 27 - Administration Login Identification
In this test case, we determined if the MCU illustrated increased conference security by identifying all login
connections to the MCU. The MCU should provide the name, profile date of login and device. To prove this
capability, we identified the current administration connections to the MCU by name and profile. We also
measured the ability to see who is logged in and how they are logged in.

Polycom MGC-100 - Passed
Within the Polycom Administration console, by selecting the Connections drilldown icon on the left, we could
determine that we were the only connection logged into the MGC manager. We could also determine that we
were a superuser, our administration name, when we connected, from what location, and using which
protocol. Confirmation of the ability to determine the administration login identification proved that this test
passed.

RADVISION viaIP 400 MCU - Did not pass
Within the RADVISION MCU administration console, we were unable to determine which users are logged in
the console. The system allows the first administrator to enter into the console and is granted full permissions.
All others who then connect to the console are granted read-only privileges. Confirmation of the inability to
determine the administration login identification proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
Within the TANDBERG MCU administration console, we found that it does not display the number of current
connections, the connection identification, and the connection profile. Confirmation of the inability to
determine the administration login identification proved that this test did not pass.

TANDBERG MPS - Did not pass
Within the TANDBERG MPS administration console, we found that it does not display the number of current
connections, the connection identification, and the connection profile. Confirmation of the inability to
determine the administration login identification proved that this test did not pass.


Test case 28 - Conference Countdown to Termination
In this test case, we determined if the MCU illustrated increased conference security by terminating a
conference definition after a set number of activations. To prove this capability, we set a conference to
terminate after two activations.

Polycom MGC-100 - Passed
We created an instance of a meeting room object and set the number of occurrences to be two in the Meet
Me per Conference dialog box. We dialed in to the conference twice and after each disconnection, the MCU
reduced the number of conference activations by one in the Meet Me per Conference dialog box. After we


              Multipoint Conferencing Unit Comparative Study                                                     25
accessed the meeting twice, the conference definition was deleted and we were unable to activate the
conference further. Based on this feature capability, we proved that this test passed.

RADVISION viaIP 400 MCU - Did not pass
After a thorough search of the RADVISION MCU product and documentation, we found that this MCU does
not support conference termination after a specific number of activations. Based on this lack of feature
capability, we proved that this test did not pass.

TANDBERG MCU 16+16 - Did not pass
After a thorough search of the TANDBERG MCU product and documentation, we found that conferences
could only be terminated manually. We were able to terminate the conference only by manually terminating
the conference in the administration console. Based on this lack of feature capability, we proved that this test
did not pass.

TANDBERG MPS - Did not pass
After a thorough search of the TANDBERG MPS product and documentation, we found that conferences
could only be terminated manually. We were able to terminate the conference only by manually terminating
the conference in the administration console. Based on this lack of feature capability, we proved that this test
did not pass.

In summary, the Polycom MGC-100 system passed all 27 test cases, as compared to five passed by the
RADVISION viaIP 400 MCU and one by the TANDBERG 16+16 and MPS MCU products. Additionally, as
shown in test case 26, the Polycom MCU demonstrated three levels of administration hierarchy, compared to
two levels for the RADVISION MCU and one level for the TANDBERG MCU. Overall, the Polycom MCU
demonstrated the most complete set of security and authentication feature capabilities of the MCU products in
our review.




              Multipoint Conferencing Unit Comparative Study                                                  26
Versatility Testing
The Versatility test cases focus on determining the product’s ability to provide a maximum level of versatility
through the set of features provided by each MCU under test. Within versatility testing, we tested features
related to transcoding, continuous presence, conference routing, conference types, and resource
management.

Test cases 29 through 33 address the ability of each MCU to perform transcoding. Transcoding is the process
of converting a media stream from one format to another. When related to MCU functionality, transcoding is
the process of managing audio and video stream information from endpoints with different bandwidth
connections, different video protocols and formatting capabilities and different audio algorithms in such a
manner so that they can work together successfully within a single conference at their optimum capabilities.

To measure the transcoding capabilities for test cases 29 through 33, we generated multiple conference
streams into the MCU under test. This methodology allowed us to inject many conferences with fixed
parameters, such as protocols, formats, and algorithms into the MCU under test and verify the maximum
number of unique audio and video streams that the MCU was able to successfully transcode.

To generate a large number of unique streams, we used a Polycom MGC-100 MCU to create specific
conference parameters and the connected into the MCU under test with these fixed parameters. As can be
seen in Figure 16, we connected this MCU into our test bed network.


Test case 29 - Transcoding Bandwidths
In this test case, we determined if the MCU illustrated that all supported bandwidths up to two Mbps can
coexist in the same conference without prior configuration and that by facilitating any combination of
bandwidths in a single conference improves connectivity and reliability. We will test this capability by creating
a conference definition and dial into the conference using the following bandwidths:
     • 64 kbps
     • 128 kbps
     • 192 kbps
     • 256 kbps
     • 384 kbps
     • 320 kbps
     • 512 kbps
     • 768 kbps
     • 1152 kbps
     • 1472 kbps
     • 1536 kbps
     • 1920 kbps

Polycom MGC-100
We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The
following list is a set of the streams that we used during our testing. The bolded parameters illustrate that the
transcoding focused on the bandwidth settings.
     • 64 kbps, H.261, CIF
     • 128 kbps, H.261, CIF
     • 192 kbps, H.261, CIF
     • 256 kbps, H.261, CIF
     • 320 kbps, H.261, CIF
     • 384 kbps, H.261, CIF
     • 512 kbps, H.261, CIF
     • 768 kbps, H.261, CIF
     • 1152 kbps, H.261, CIF
     • 1472 kbps, H.261, CIF


              Multipoint Conferencing Unit Comparative Study                                                   27
•   1536 kbps, H.261, CIF
    •   1920 kbps, H.261, CIF

We were able to connect these 12 streams, each with a unique bandwidth into a single conference on the
Polycom MCU. We inspected the properties of each incoming connection to ensure that all bandwidth
requirements were met and validated that conference transcoding was being performed by the MCU as
expected. Confirmation of the ability to transcode multiple bandwidths proved that this MCU was able to
transcode all available bandwidth capabilities.

RADVISION viaIP 400 MCU
Using the administration console, we used the RADVISION MCU interface to create video scheme settings
with different bandwidths. We found a limitation in the user interface that prevented us from creating more
than three video scheme settings. Figure 14 shows the user interface with this limitation. Notice that the
button that allows the user to create additional streams, the Add button, became disabled after three video
scheme settings has been created.




Figure 14. RADVISION viaIP 400 MCU View Settings dialog box

If we edit the first setting in the list, and change the mode from Basic to Non_Transcoding, then we are able to
return to the View Settings Screen and add a fourth video scheme setting. However, we were able to perform
this only when the Max Layout Continuous Presence is set to Full Screen. If we change the Max Layout to

             Multipoint Conferencing Unit Comparative Study                                                   28
anything other than Full Screen, then we are unable to add more than three video scheme settings.
Confirmation of the ability to transcode multiple bandwidths proved that this MCU was able to transcode all
available bandwidth capabilities.

TANDBERG MCU 16+16
Using the administration console, we used the TANDBERG MCU interface to create a new conference. We
dialed into the conference using several endpoints. We noticed that as we added new endpoints into the
conference that the MCU maintained two bandwidth points for transcoding.

The first two bandwidths that connect to the conference define the upper and lower limits of the MCU
transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the
bandwidth of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the
bandwidth of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit
will be established for the conference is equal to this newest bandwidth.

Additionally, we found confirming documentation in Section 4.4.4.3 of the document entitled “Technical
Description of TANDBERG MCU with software version D2 (TANDBERG D12925 Rev. 02)”.

In summary, we found that the TANDBERG MCU was able to rate match multiple input streams to a
maximum of two transcoded bandwidth outputs.

TANDBERG MPS
Using the administration console, we used the TANDBERG MCU interface to create a new conference. We
dialed into the conference using several endpoints. We noticed that as we added new endpoints into the
conference that the MCU maintained two bandwidth points for transcoding.

The first two bandwidths that connect to the conference define the upper and lower limits of the MCU
transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the
bandwidth of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the
bandwidth of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit
will be established for the conference equal to this latest bandwidth.

Additionally, we found confirming documentation in the document entitled “MPS User Manual.” in Section
6.2.3 on the Enhanced Video Transcoding of this document.

In summary, we found that the TANDBERG MCU was able to rate match multiple input streams to a
maximum of two transcoded bandwidth outputs.


Test case 30 - Transcoding Video Protocols
In this test case, we determined if the MCU illustrated that all supported video protocols can coexist in the
same conference without prior configuration and that by facilitating any combination of video protocols in a
single conference improves connectivity and reliability. We will test this capability by creating a conference
definition and dial into the conference using the following bandwidths:
     • H.261
     • H.263
     • H.264

Polycom MGC-100
We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The
bolded parameters illustrate that the transcoding focused on the video protocol settings.
    • 64 kbps, H.261, CIF
    • 64 kbps, H.263, CIF
    • 64 kbps, H.264, CIF

We were able to connect these three streams, each with a unique video protocol into a single conference on
the Polycom MCU. We inspected the properties of each incoming connection to ensure that all protocol

              Multipoint Conferencing Unit Comparative Study                                                     29
requirements were met and validated that conference transcoding was being performed by the MCU as
expected. Confirmation of the ability to transcode multiple video protocol proved that this MCU was able to
transcode all available video protocol capabilities.

RADVISION viaIP 400 MCU
Using the administration console, we used the RADVISION MCU interface to create video scheme settings
with different video protocols. We found a limitation in the user interface that prevented us from creating more
than three video scheme settings. Figure 14 shows the user interface with this limitation.

When we tested the RADVISION MCU using the on-board video card, i.e. MVP mode, we were able to
transcode using only H.261 and H.263 video protocols. H.264 was unavailable. When we tested the MCU
card, i.e. MP mode, we than we able to select H.261, H.263, and H.264, but only in non-transcoded
conference.

TANDBERG MCU 16+16
Using the administration console, we used the TANDBERG MCU interface to create a new conference. We
dialed into the conference using several endpoints. We noticed that as we added new endpoints into the
conference that the MCU maintained two video protocols for transcoding. The first two video protocols that
connected to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints
connect to the conference between the upper and lower limits, then the protocol of the latest endpoint entered
into the conference will be reduced to meet the lower limit. If the protocol of the latest endpoint entering in the
conference is less than the lower limit, then a new lower limit will be established for the conference equal to
this latest video protocol.

Additionally, when we created a conference and successfully connected a H.261 endpoint, and connected a
H.263 endpoint. When we connected a H.264 endpoint in to the conference, the conference terminated in the
administration console.

In summary, we found that the TANDBERG MCU was able to accept multiple input streams to a maximum of
two distinct video protocol outputs.

TANDBERG MPS
Using the administration console, we used the TANDBERG MPS interface to create a new conference. We
dialed into the conference using several endpoints. We noticed that as we added new endpoints into the
conference that the MCU maintained two video protocols for transcoding. The first two video protocols that
connected to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints
connect to the conference between the upper and lower limits, then the protocol of the latest endpoint entered
into the conference will be reduced to meet the lower limit. If the protocol of the latest endpoint entering in the
conference is less than the lower limit, then a new lower limit will be established for the conference equal to
this latest video protocol.

In summary, we found that the TANDBERG MPS was able to accept multiple input streams to a maximum of
two distinct video protocol outputs.


Test case 31 - Transcoding Video Formats
In this test case, we determined if the MCU illustrated that all supported video formats can coexist in the same
conference without prior configuration and that by facilitating any combination of video formats in a single
conference improves connectivity and reliability. We will test this capability by creating a conference definition
and dial into the conference using the following bandwidths:
     • QCIF
     • CIF
     • 4CIF

Polycom MGC-100
We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The
bolded parameters illustrate that the transcoding focused on the video format settings.

              Multipoint Conferencing Unit Comparative Study                                                    30
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study
Multipoint Conferencing Unit Comparative Study

Más contenido relacionado

La actualidad más candente

Securing the present block cipher against combined side channel analysis and ...
Securing the present block cipher against combined side channel analysis and ...Securing the present block cipher against combined side channel analysis and ...
Securing the present block cipher against combined side channel analysis and ...Nxfee Innovation
 
Caps Professional Services Diagnostic
Caps Professional Services DiagnosticCaps Professional Services Diagnostic
Caps Professional Services Diagnosticlebenworld
 
Software Requirements for Safety-related Systems
Software Requirements for Safety-related SystemsSoftware Requirements for Safety-related Systems
Software Requirements for Safety-related SystemsVittorio Giovara
 
Quantstamp Report - LINKSWAP
Quantstamp Report - LINKSWAPQuantstamp Report - LINKSWAP
Quantstamp Report - LINKSWAPRoy Blackstone
 
Short definitions of all testing types
Short definitions of all testing typesShort definitions of all testing types
Short definitions of all testing typesGaruda Trainings
 
Michael_Joshua_Validation
Michael_Joshua_ValidationMichael_Joshua_Validation
Michael_Joshua_ValidationMichaelJoshua
 
Misracompliant20162020
Misracompliant20162020Misracompliant20162020
Misracompliant20162020Kiyoshi Ogawa
 
NASA Software Safety Guidebook
NASA Software Safety GuidebookNASA Software Safety Guidebook
NASA Software Safety GuidebookVapula
 
DO-254 for dummies 7
DO-254 for dummies 7DO-254 for dummies 7
DO-254 for dummies 7DMAP
 

La actualidad más candente (13)

nullcon 2011 - Fuzzing with Complexities
nullcon 2011 - Fuzzing with Complexitiesnullcon 2011 - Fuzzing with Complexities
nullcon 2011 - Fuzzing with Complexities
 
Securing the present block cipher against combined side channel analysis and ...
Securing the present block cipher against combined side channel analysis and ...Securing the present block cipher against combined side channel analysis and ...
Securing the present block cipher against combined side channel analysis and ...
 
Caps Professional Services Diagnostic
Caps Professional Services DiagnosticCaps Professional Services Diagnostic
Caps Professional Services Diagnostic
 
Software Requirements for Safety-related Systems
Software Requirements for Safety-related SystemsSoftware Requirements for Safety-related Systems
Software Requirements for Safety-related Systems
 
Quantstamp Report - LINKSWAP
Quantstamp Report - LINKSWAPQuantstamp Report - LINKSWAP
Quantstamp Report - LINKSWAP
 
Short definitions of all testing types
Short definitions of all testing typesShort definitions of all testing types
Short definitions of all testing types
 
Michael_Joshua_Validation
Michael_Joshua_ValidationMichael_Joshua_Validation
Michael_Joshua_Validation
 
Misracompliant20162020
Misracompliant20162020Misracompliant20162020
Misracompliant20162020
 
NASA Software Safety Guidebook
NASA Software Safety GuidebookNASA Software Safety Guidebook
NASA Software Safety Guidebook
 
50120140502011
5012014050201150120140502011
50120140502011
 
Ash Maurya, USERcycle
Ash Maurya, USERcycleAsh Maurya, USERcycle
Ash Maurya, USERcycle
 
Part 6
Part 6Part 6
Part 6
 
DO-254 for dummies 7
DO-254 for dummies 7DO-254 for dummies 7
DO-254 for dummies 7
 

Similar a Multipoint Conferencing Unit Comparative Study

Case Study - AMR Test Automation
Case Study - AMR Test AutomationCase Study - AMR Test Automation
Case Study - AMR Test AutomationiFocusSystec
 
SCALABLE CI CD DEVOPS
SCALABLE CI CD DEVOPSSCALABLE CI CD DEVOPS
SCALABLE CI CD DEVOPSG R VISHAL
 
Accelerating tests with Cypress for a leaderboard platform
Accelerating tests with Cypress for a leaderboard platformAccelerating tests with Cypress for a leaderboard platform
Accelerating tests with Cypress for a leaderboard platformKnoldus Inc.
 
Introduce Test Harness for Direct To Consumer Solutions.pdf
Introduce Test Harness for Direct To Consumer Solutions.pdfIntroduce Test Harness for Direct To Consumer Solutions.pdf
Introduce Test Harness for Direct To Consumer Solutions.pdfKnoldus Inc.
 
SourceWarp AST 2023.pdf
SourceWarp AST 2023.pdfSourceWarp AST 2023.pdf
SourceWarp AST 2023.pdfJulian Thome
 
UVM_Full_Print_n.pptx
UVM_Full_Print_n.pptxUVM_Full_Print_n.pptx
UVM_Full_Print_n.pptxnikitha992646
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREVLSICS Design
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREVLSICS Design
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREVLSICS Design
 
[ENGLISH] TDC 2015 - PHP Trail - Tests and PHP Continuous Integration Enviro...
[ENGLISH] TDC 2015 - PHP  Trail - Tests and PHP Continuous Integration Enviro...[ENGLISH] TDC 2015 - PHP  Trail - Tests and PHP Continuous Integration Enviro...
[ENGLISH] TDC 2015 - PHP Trail - Tests and PHP Continuous Integration Enviro...Bruno Tanoue
 
Fuzzing101 - webinar on Fuzzing Performance
Fuzzing101 - webinar on Fuzzing PerformanceFuzzing101 - webinar on Fuzzing Performance
Fuzzing101 - webinar on Fuzzing PerformanceCodenomicon
 
The quality assurance checklist for progressive testing
The quality assurance checklist for progressive testingThe quality assurance checklist for progressive testing
The quality assurance checklist for progressive testingMaitrikpaida
 
The Quality Assurance Checklist for Progressive Testing
The Quality Assurance Checklist for Progressive TestingThe Quality Assurance Checklist for Progressive Testing
The Quality Assurance Checklist for Progressive TestingCygnet Infotech
 
Intro to Automation Using Perfecto's CQ Lab
Intro to Automation Using Perfecto's CQ LabIntro to Automation Using Perfecto's CQ Lab
Intro to Automation Using Perfecto's CQ LabLizzy Guido (she/her)
 
Zero-bug Software, Mathematically Guaranteed
Zero-bug Software, Mathematically GuaranteedZero-bug Software, Mathematically Guaranteed
Zero-bug Software, Mathematically GuaranteedAshley Zupkus
 

Similar a Multipoint Conferencing Unit Comparative Study (20)

A New Generation Software Test Automation Framework – CIVIM
A New Generation Software Test Automation Framework – CIVIMA New Generation Software Test Automation Framework – CIVIM
A New Generation Software Test Automation Framework – CIVIM
 
Case Study - AMR Test Automation
Case Study - AMR Test AutomationCase Study - AMR Test Automation
Case Study - AMR Test Automation
 
SCALABLE CI CD DEVOPS
SCALABLE CI CD DEVOPSSCALABLE CI CD DEVOPS
SCALABLE CI CD DEVOPS
 
Accelerating tests with Cypress for a leaderboard platform
Accelerating tests with Cypress for a leaderboard platformAccelerating tests with Cypress for a leaderboard platform
Accelerating tests with Cypress for a leaderboard platform
 
Vandana B
Vandana BVandana B
Vandana B
 
Mobile Monitoring Best Practices
Mobile Monitoring Best PracticesMobile Monitoring Best Practices
Mobile Monitoring Best Practices
 
Introduce Test Harness for Direct To Consumer Solutions.pdf
Introduce Test Harness for Direct To Consumer Solutions.pdfIntroduce Test Harness for Direct To Consumer Solutions.pdf
Introduce Test Harness for Direct To Consumer Solutions.pdf
 
SourceWarp AST 2023.pdf
SourceWarp AST 2023.pdfSourceWarp AST 2023.pdf
SourceWarp AST 2023.pdf
 
UVM_Full_Print_n.pptx
UVM_Full_Print_n.pptxUVM_Full_Print_n.pptx
UVM_Full_Print_n.pptx
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
 
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER COREUVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
UVM BASED REUSABLE VERIFICATION IP FOR WISHBONE COMPLIANT SPI MASTER CORE
 
Resume
ResumeResume
Resume
 
[ENGLISH] TDC 2015 - PHP Trail - Tests and PHP Continuous Integration Enviro...
[ENGLISH] TDC 2015 - PHP  Trail - Tests and PHP Continuous Integration Enviro...[ENGLISH] TDC 2015 - PHP  Trail - Tests and PHP Continuous Integration Enviro...
[ENGLISH] TDC 2015 - PHP Trail - Tests and PHP Continuous Integration Enviro...
 
Fuzzing101 - webinar on Fuzzing Performance
Fuzzing101 - webinar on Fuzzing PerformanceFuzzing101 - webinar on Fuzzing Performance
Fuzzing101 - webinar on Fuzzing Performance
 
The quality assurance checklist for progressive testing
The quality assurance checklist for progressive testingThe quality assurance checklist for progressive testing
The quality assurance checklist for progressive testing
 
The Quality Assurance Checklist for Progressive Testing
The Quality Assurance Checklist for Progressive TestingThe Quality Assurance Checklist for Progressive Testing
The Quality Assurance Checklist for Progressive Testing
 
Intro to Automation Using Perfecto's CQ Lab
Intro to Automation Using Perfecto's CQ LabIntro to Automation Using Perfecto's CQ Lab
Intro to Automation Using Perfecto's CQ Lab
 
Resume
ResumeResume
Resume
 
Zero-bug Software, Mathematically Guaranteed
Zero-bug Software, Mathematically GuaranteedZero-bug Software, Mathematically Guaranteed
Zero-bug Software, Mathematically Guaranteed
 

Más de Videoguy

Energy-Aware Wireless Video Streaming
Energy-Aware Wireless Video StreamingEnergy-Aware Wireless Video Streaming
Energy-Aware Wireless Video StreamingVideoguy
 
Microsoft PowerPoint - WirelessCluster_Pres
Microsoft PowerPoint - WirelessCluster_PresMicrosoft PowerPoint - WirelessCluster_Pres
Microsoft PowerPoint - WirelessCluster_PresVideoguy
 
Proxy Cache Management for Fine-Grained Scalable Video Streaming
Proxy Cache Management for Fine-Grained Scalable Video StreamingProxy Cache Management for Fine-Grained Scalable Video Streaming
Proxy Cache Management for Fine-Grained Scalable Video StreamingVideoguy
 
Free-riding Resilient Video Streaming in Peer-to-Peer Networks
Free-riding Resilient Video Streaming in Peer-to-Peer NetworksFree-riding Resilient Video Streaming in Peer-to-Peer Networks
Free-riding Resilient Video Streaming in Peer-to-Peer NetworksVideoguy
 
Instant video streaming
Instant video streamingInstant video streaming
Instant video streamingVideoguy
 
Video Streaming over Bluetooth: A Survey
Video Streaming over Bluetooth: A SurveyVideo Streaming over Bluetooth: A Survey
Video Streaming over Bluetooth: A SurveyVideoguy
 
Video Streaming
Video StreamingVideo Streaming
Video StreamingVideoguy
 
Reaching a Broader Audience
Reaching a Broader AudienceReaching a Broader Audience
Reaching a Broader AudienceVideoguy
 
Considerations for Creating Streamed Video Content over 3G ...
Considerations for Creating Streamed Video Content over 3G ...Considerations for Creating Streamed Video Content over 3G ...
Considerations for Creating Streamed Video Content over 3G ...Videoguy
 
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGVideoguy
 
Impact of FEC Overhead on Scalable Video Streaming
Impact of FEC Overhead on Scalable Video StreamingImpact of FEC Overhead on Scalable Video Streaming
Impact of FEC Overhead on Scalable Video StreamingVideoguy
 
Application Brief
Application BriefApplication Brief
Application BriefVideoguy
 
Video Streaming Services – Stage 1
Video Streaming Services – Stage 1Video Streaming Services – Stage 1
Video Streaming Services – Stage 1Videoguy
 
Streaming Video into Second Life
Streaming Video into Second LifeStreaming Video into Second Life
Streaming Video into Second LifeVideoguy
 
Flash Live Video Streaming Software
Flash Live Video Streaming SoftwareFlash Live Video Streaming Software
Flash Live Video Streaming SoftwareVideoguy
 
Videoconference Streaming Solutions Cookbook
Videoconference Streaming Solutions CookbookVideoconference Streaming Solutions Cookbook
Videoconference Streaming Solutions CookbookVideoguy
 
Streaming Video Formaten
Streaming Video FormatenStreaming Video Formaten
Streaming Video FormatenVideoguy
 
iPhone Live Video Streaming Software
iPhone Live Video Streaming SoftwareiPhone Live Video Streaming Software
iPhone Live Video Streaming SoftwareVideoguy
 
Glow: Video streaming training guide - Firefox
Glow: Video streaming training guide - FirefoxGlow: Video streaming training guide - Firefox
Glow: Video streaming training guide - FirefoxVideoguy
 

Más de Videoguy (20)

Energy-Aware Wireless Video Streaming
Energy-Aware Wireless Video StreamingEnergy-Aware Wireless Video Streaming
Energy-Aware Wireless Video Streaming
 
Microsoft PowerPoint - WirelessCluster_Pres
Microsoft PowerPoint - WirelessCluster_PresMicrosoft PowerPoint - WirelessCluster_Pres
Microsoft PowerPoint - WirelessCluster_Pres
 
Proxy Cache Management for Fine-Grained Scalable Video Streaming
Proxy Cache Management for Fine-Grained Scalable Video StreamingProxy Cache Management for Fine-Grained Scalable Video Streaming
Proxy Cache Management for Fine-Grained Scalable Video Streaming
 
Adobe
AdobeAdobe
Adobe
 
Free-riding Resilient Video Streaming in Peer-to-Peer Networks
Free-riding Resilient Video Streaming in Peer-to-Peer NetworksFree-riding Resilient Video Streaming in Peer-to-Peer Networks
Free-riding Resilient Video Streaming in Peer-to-Peer Networks
 
Instant video streaming
Instant video streamingInstant video streaming
Instant video streaming
 
Video Streaming over Bluetooth: A Survey
Video Streaming over Bluetooth: A SurveyVideo Streaming over Bluetooth: A Survey
Video Streaming over Bluetooth: A Survey
 
Video Streaming
Video StreamingVideo Streaming
Video Streaming
 
Reaching a Broader Audience
Reaching a Broader AudienceReaching a Broader Audience
Reaching a Broader Audience
 
Considerations for Creating Streamed Video Content over 3G ...
Considerations for Creating Streamed Video Content over 3G ...Considerations for Creating Streamed Video Content over 3G ...
Considerations for Creating Streamed Video Content over 3G ...
 
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
 
Impact of FEC Overhead on Scalable Video Streaming
Impact of FEC Overhead on Scalable Video StreamingImpact of FEC Overhead on Scalable Video Streaming
Impact of FEC Overhead on Scalable Video Streaming
 
Application Brief
Application BriefApplication Brief
Application Brief
 
Video Streaming Services – Stage 1
Video Streaming Services – Stage 1Video Streaming Services – Stage 1
Video Streaming Services – Stage 1
 
Streaming Video into Second Life
Streaming Video into Second LifeStreaming Video into Second Life
Streaming Video into Second Life
 
Flash Live Video Streaming Software
Flash Live Video Streaming SoftwareFlash Live Video Streaming Software
Flash Live Video Streaming Software
 
Videoconference Streaming Solutions Cookbook
Videoconference Streaming Solutions CookbookVideoconference Streaming Solutions Cookbook
Videoconference Streaming Solutions Cookbook
 
Streaming Video Formaten
Streaming Video FormatenStreaming Video Formaten
Streaming Video Formaten
 
iPhone Live Video Streaming Software
iPhone Live Video Streaming SoftwareiPhone Live Video Streaming Software
iPhone Live Video Streaming Software
 
Glow: Video streaming training guide - Firefox
Glow: Video streaming training guide - FirefoxGlow: Video streaming training guide - Firefox
Glow: Video streaming training guide - Firefox
 

Multipoint Conferencing Unit Comparative Study

  • 1. December 2004 www.veritest.com • info@veritest.com Multipoint Conferencing Unit Comparative Study Test report prepared under contract from Polycom, Inc. Executive Summary Polycom commissioned VeriTest to conduct an independent comparative Key Findings analysis of four Multipoint Conferencing Unit (MCU) products Overall, the Polycom MCU demonstrated the most complete used for video conferencing systems. set of security and authentication, as well as, administration We performed a series of tests on operation and control feature capabilities of all MCU products each product that was consistent with in our review. the typical product usage. We found that the Polycom MCU offered the most flexibility We evaluated the following four MCU within its feature set of all of the MCU products. systems: Based on the results from our three use case scenarios, we • Polycom MGC-100 found that the Polycom offered the largest and most flexible • RADVISION viaIP 400 MCU set of options to complete the use cases successfully. • TANDBERG MCU 16+16 • TANDBERG Media Processing System (MPS) Polycom and VeriTest worked together to create a test methodology to measure the capability of each product in this study. This methodology covered a wide spectrum of real-user MCU product capabilities and was designed to examine how effective each product was when subjected to real-world operational settings. The 71 test cases that we used measured the capability of each product across the following feature set: 1. Security and Authentication a. Conference Security b. System Security 2. Versatility a. Transcoding b. Data and Content c. Continuous Presence d. Conference Routing e. Conference Types f. Resource Management g. Customization 3. Operation and Control a. System Management b. User Control In summary, we found that the Polycom MGC-100 MCU successfully passed 63 of the 63 test cases, compared to 14 passed test cases for the RADVISION viaIP 400 MCU, 5 for the TANDBERG MCU 16+16, and 7 for the TANDBERG MCU MPS. Additionally, for tests that were quantitative in nature and did not generate a simple pass/fail response, the Polycom MCU consistently demonstrated a significantly wider range of capabilities and more flexibility than the other manufacturers. One example that showed this flexibility was the Polycom approach to transcoding. Their ability to mix 62 video connections in a single conference, each
  • 2. with separate connection parameters was significantly more than the other manufacturers could do and would be of significant benefit in a video network deployment. The Polycom MCU also demonstrated the most complete set of security and authentication capabilities as well as the most powerful administration operation and control features of all MCU products in our review. An example of this is the consistently high pass rate of the Polycom MCU on security issues such as multiple administration levels and password protection, when compared to the other manufacturers’ products. Overall, we found that the Polycom MCU offered by far the greatest flexibility within its feature set across all three key areas of security, versatility and operational management of all of the MCU products tested. In addition, we used three use case scenarios to determine how each product would behave when deployed as the target MCU within different real-world scenarios. For the first use case, we used the following scenario: Company XYZ hosts multiple conferences on the behalf of clients and billed according to usage. As such, they need to provide secure conferencing with strong password and conference protection. Every client is provided with a unique, randomly generated password for chair and participant access. It is critical that all passwords comply with their in-house password policy. Based on our test case results, the Polycom MCU was able to complete all required tasks. The RADVISION MCU was able to complete two of the required tasks, and both TANDBERG MCU products did not pass on all tasks. For the second use case, we used the following scenario: Company XYZ has implemented on-demand conferencing throughout their company. Each functional work group has their own entry queue, conference identifier, and set of passwords for security. To conserve resources, the director of IT only wants the conference to start once the chairperson is participating. In addition, to minimize the amount of time spent on conference management, the director wants the ability for the chairperson to control his or her own conference, identifying who is present, the duration, and the screen layouts. Based on our test case results, the Polycom MCU was able to complete all required tasks. The other MCU products did not pass on all tasks. For the third use case, we used the following scenario: Service Provider XYZ business model is to host multiple conferences for their enterprise-based clients. As such, they provide premium high touch services as a way to differentiate themselves from their competition. One area they wish to excel at is for their clients to have a high quality experience with the expectation to connect right away, request help when needed and the audio quality to be superb. This service provider has set up each of their clients with their own call in number with multiple conference ID’s for each number, customized IVR, operator services and a Service Level Agreement. Since they host thousands of hours of conferencing per month, scalability is required and multiple operators to monitor on going conferences. Based on our test case results, the Polycom MCU was able to complete all required tasks. The other MCU products did not pass on all tasks. Based on the results from our use case scenarios, we found that the Polycom offered the largest and most flexible set of options to complete the use cases successfully. Multipoint Conferencing Unit Comparative Study 2
  • 3. Test Results Polycom commissioned VeriTest to conduct a comparative analysis of four MCU products. We performed a series of tests on each of the four products that was consistent with the typical product usage. We evaluated the following four systems: • Polycom MGC-100 • RADVISION viaIP 400 MCU • TANDBERG MCU 16+16 • TANDBERG MPS Polycom and VeriTest worked together to create a test methodology to measure the capability of each product in this study. This methodology covered a wide spectrum of real-user product capabilities. The test methodology that we used measured the capability of each product across the following feature set: 1. Security and Authentication a. Conference Security b. System Security 2. Versatility a. Transcoding b. Data and Content c. Continuous Presence d. Conference Routing e. Conference Types f. Resource Management g. Customization 3. Operation and Control a. System Management b. User Control Although we tested discrete features of the MCUs in this study, some of the tests that we ran have common methodologies. See the section on Test Methodology for a complete description of the test methodology that we used in this study. Multipoint Conferencing Unit Comparative Study 3
  • 4. Results Summary The following set of tables includes a summary of the test cases that we performed in this study. Test # Test Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 1 Conference Passed Passed Did not pass Did not pass Password Call-in and Call- out 2 Password Passed Did not pass Did not pass Did not pass Hierarchy 3 Privilege Profiles Passed Did not pass Did not pass Did not pass 4 Automatic Passed Did not pass Did not pass Did not pass Password Generation 5 Password Integrity Passed Did not pass Did not pass Did not pass Validation 6 Conference Passed Passed Did not pass Did not pass Password String Validation 7 Change Passed Did not pass Did not pass Did not pass Conference Password During A Conference 8 Conference Lock Passed Passed Passed Passed 9 Conference Hide Passed Did not pass Did not pass Did not pass 10 Automatic Passed Passed Did not pass Did not pass Conference Termination – no show 11 Automatic Passed Passed Did not pass Did not pass Conference Termination – after last person 12 Automatic Passed Did not pass Did not pass Did not pass Conference Termination – after chairperson leader profile exits 13 Conference Passed Did not pass Did not pass Did not pass Termination – During A Conference 14 Conference Passed Did not pass Did not pass Did not pass Requires Chairperson or leader To Start 15 Participant Passed Did not pass Did not pass Did not pass Identification – Entering a conference 16 Participant Passed Did not pass Did not pass Did not pass Multipoint Conferencing Unit Comparative Study 4
  • 5. Identification – Leaving a conference 17 Automatic Passed Did not pass Did not pass Did not pass Participant Identification By Name 18 Roll Call Passed Did not pass Did not pass Did not pass 19 Automatic Dial Out Passed Did not pass Did not pass Did not pass 20 Operator Assisted Passed Did not pass Did not pass Did not pass Routing Figure 1. Security and Authentication Test Results Multipoint Conferencing Unit Comparative Study 5
  • 6. Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 21 Request Private Passed Did not pass Did not pass Did not pass Operator Assistance 22 Secure Breakout Passed Did not pass Did not pass Did not pass or Sidebar Session 23 Decreasing Passed Did not pass Did not pass Did not pass Password Attempts 24 Failed Conference Passed Did not pass Did not pass Did not pass Access 25 Secure Non Passed Did not pass Did not pass Did not pass Password Conference 26 Administration 3 levels of 2 levels of 1 level of 1 level of Hierarchy administration administration administration administration 27 Administration Passed Did not pass Did not pass Did not pass Login Identification 28 Conference Passed Did not pass Did not pass Did not pass Countdown To Termination Figure 2. Security and Authentication Test Results (continued) Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 29 Transcoding 12 of 12 3 of 12 2 of 12 2 of 12 Bandwidths 30 Transcoding Video 3 of 3 2 of 3 2 of 3 2 of 3 Protocols 31 Transcoding Video 3 of 3 1 of 3 2 of 3 2 of 3 Formats 32 Transcoding Audio 6 of 6 6 of 6 4 of 6 4 of 6 Algorithms 33 Transcoding All 62 of 62 3 of 62 2 of 62 2 of 62 34 Mixed Protocol Passed Did not pass Did not pass Did not pass Conference Application Layer 35 Mixed Conference Passed Did not pass Did not pass Passed Presentation Layer Figure 3. Versatility - Transcoding Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 36 T.120 Support Passed Passed Did not pass Did not pass Datasheet comparison 37 Standard H.239 Passed Passed Did not pass Passed Support Datasheet comparison Figure 4. Versatility – Data and Content Test Results Multipoint Conferencing Unit Comparative Study 6
  • 7. Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 38 Configurable Passed Did not pass Did not pass Did not pass Automatic Layout Selection 39 Private Layout Passed Did not pass Did not pass Did not pass 40 Chairperson Passed Did not pass Did not pass Did not pass Layout Change 41 Virtual Classroom Passed Did not pass Did not pass Did not pass 42 Broadcast Mode Passed Did not pass Did not pass Did not pass 43 CNN CP View Passed Passed Did not pass Did not pass Figure 5. Versatility – Continuous Presence Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 44 Conference DID Passed Passed Passed Passed Number Routing 45 Different Number Passed Did not pass Did not pass Did not pass Conference ID Routing 46 Participant Passed Did not pass Did not pass Did not pass Number Routing Figure 6. Versatility – Conference Routing Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 47 Operator Passed Did not pass Did not pass Did not pass 48 Scheduled Passed Passed Passed Passed 49 Ad-hoc Dialing Passed Passed Did not pass Did not pass 50 Ad-hoc Predefined Passed Did not pass Did not pass Did not pass Dialing Figure 7. Versatility – Conference Type Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 51 Music On Hold Passed Did not pass Did not pass Did not pass Detection 52 Resource Passed Did not pass Did not pass Did not pass Management 53 Resource Reset Passed Did not pass Did not pass Did not pass 54 Multi System View 3 of 3 parameters 0 of 3 parameters 1 of 3 parameters 1 of 3 parameters 55 Integrated Passed Did not pass Did not pass Did not pass Gateway 56 Simultaneous Passed Passed Did not pass Did not pass Conferences Figure 8. Versatility – Resource Management Test Results Multipoint Conferencing Unit Comparative Study 7
  • 8. Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 57 IVR Variations Passed Did not pass Did not pass Did not pass 58 Multi-language Passed Did not pass Did not pass Did not pass Company Greeting Entry Queue Figure 9. Versatility – Customization Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 59 Administration Passed Did not pass Did not pass Did not pass Login Identification 60 Multiple Admin 3 levels of 2 levels of 1 level of 1 level of Profiles administration administration administration administration 61 Multi-language Passed Did not pass Did not pass Did not pass Company Greeting Entry Queue 62 Single Passed Did not pass Did not pass Did not pass Management Interface 63 Conference Passed Did not pass Did not pass Did not pass Filtering – Faulty Connection 64 Conference Passed Did not pass Did not pass Did not pass Filtering – Participants Requesting Assistance 65 Conference Passed Did not pass Did not pass Did not pass Filtering – Noisy Line 66 Automatic Mute Passed Did not pass Did not pass Did not pass On Music Detection 67 View Individual Passed Did not pass Passed Passed Capabilities Figure 10. Operation and Control – System Management Test Results Test # Name Polycom MGC- RADVISION viaIP TANDBERG MCU TANDBERG MPS 100 400 MCU 16+16 68 Ad-hoc Dialing Passed Passed Did not pass Did not pass 69 Single Number per Passed Passed Passed Passed Conference 70 Single Number For Passed Did not pass Did not pass Did not pass All Conferences 71 Personalized Passed Did not pass Did not pass Did not pass Conference Figure 11. Operation and Control – User Control Test Results Multipoint Conferencing Unit Comparative Study 8
  • 9. Security and Administration Testing The Security and Administration test cases focus on determining the product’s ability to provide a maximum level of conference security through the set of features provided by the MCU under test. Additionally, these tests address the set of features provided by the MCU to perform administrative control remotely. Test case 1 - Conference Password In this test case, we determined if the MCU illustrated increased conference security by protecting entry to a conference by the use of a password. To prove this capability, we created a conference definition with a conference password. We then dialed into and out of the conference checking to ensure that the MCU prompted us for a password for each type of connection. Polycom MGC-100 - Passed Using the administration console, we were able to create a conference that was password protected. We dialed into the conference and the Polycom MCU prompted us for a password. We then dialed out to a second endpoint and once again, the MCU prompted us for a password. This test proved that this security feature worked for both dial in and dial out conditions. RADVISION viaIP 400 MCU - Passed Using the administration console, we were able to create a conference that was password protected. We dialed into the conference and the RADVISION MCU prompted us for a password. We then dialed out to a second endpoint and once again, the MCU prompted that endpoint for a password. This test proved that this security feature worked for both dial in and dial out conditions. TANDBERG MCU 16+16 - Did not pass Using the administration console, we were able to create a conference that was password protected. We dialed into the conference and the TANDBERG 16+16 MCU prompted us for a password. We then dialed out to a second endpoint; however, when that participant answered the endpoint, the MCU did not request a password. The MCU placed the endpoint into the conference regardless. This test proved that this security feature worked for dial in connections but not for dial out connections. TANDBERG MPS - Did not pass Using the administration console, we were able to create a conference that was password protected. We dialed into the conference and the TANDBERG MPS prompted us for a password. We then dialed out to a second endpoint; however, when that participant answered the endpoint, the MCU did not request a password. The MCU placed the endpoint into the conference regardless. This test proved that this security feature worked for dial in connections but not for dial out connections. Test case 2 - Password Hierarchy In this test case, we determined if the MCU illustrated increased conference security by facilitating entry into a conference using a password hierarchy. Permitting access into a conference using multiple passwords allows the MCU to provide greater conference security by granting or denying access to additional services based on the password profile supplied to enter the conference. To prove this capability, we created a conference definition granting additional privileges to the chairperson or leader password profile to that of the participant password profile. We then dialed into the conference using each password profile to confirm that entry was possible using a password hierarchy and that each profile afforded differing levels of functionality. Polycom MGC-100 - Passed Using the administration console, we were able to create a conference with a chairperson and a participant password. Using the MCU configuration menu we selected an IVR Message Service that we used for this test. We then dialed into the conference using the participant password from one endpoint and then dialed into the same conference using the chairperson password from another endpoint. To ensure that we had dialed into the conference with differing levels of permissions, we were able to mute all endpoints using DTMF codes from the endpoint where the chairperson’s password was entered and were unable to do this on the endpoint where the participant’s password was entered. This test proved that this password hierarchy test passed successfully. Multipoint Conferencing Unit Comparative Study 9
  • 10. RADVISION viaIP 400 MCU - Did not pass Using the administration console, we were able to create a conference with a chairperson and a participant password. However, when we dialed into the conference, we were able to log in as the participant only. When we attempted to dial into the conference as the chairperson, the RADVISION MCU generated an operator recording stating that we had entered an invalid password. We later found that the chairperson password is to be used to enter the administration console with special permissions, not to enter a specific conference with chairperson privileges. This test proved that this password hierarchy test did not pass. TANDBERG MCU 16+16 - Did not pass Using the administration console, we found that the TANDBERG MCU 16+16 allowed us to create only one password per conference. This test proved that this password hierarchy test did not pass. TANDBERG MPS – Did not pass Using the administration console, we found that the TANDBERG MPS allowed us to create only one password per conference. This test proved that this password hierarchy test did not pass. Test case 3 - Privilege Profiles In this test case, we determined if the MCU illustrated increased conference security being capable of assigning multiple instances of contrasting levels of in-conference functionality or privilege profiles using a single conference definition. To prove this capability, we created a single conference definition and confirmed that the chairperson or leader received different in-conference capabilities to that of the participant. Using the same conference definition, a second conference was created that used a different privilege profile. We then connected another chairperson or leader and participant to confirm that a completely different set of in- conference privileges were available. Polycom MGC-100 - Passed Using the administration console, we were able to create a conference with a chairperson and a participant. We were able to make these changes by going to the MCU configuration menu and selecting IVR Msg Services, and then a specific IVR Message Service that we used for this test. We dialed into the conference as a participant using one endpoint and then dialed into the conference as a chairperson using another endpoint. To ensure that we had dialed into the conference with different permissions, we were able to mute all endpoints using DTMF codes on the chairperson endpoint, and unable to do this on the participant endpoint. We then created a second conference using the same conference definition and confirmed that a different profile was active. This test proved that this privilege profile test passed successfully. RADVISION viaIP 400 MCU - Did not pass Using the administration console, we were able to create a conference with a chairperson and a participant. However, when we dialed into the conference, we were able to log in as the participant only. When we attempted to dial into the conference as the chairperson, the RADVISION MCU generated an operator recording stating that we had entered an invalid password. We were unable to mute all other participants from an endpoint for two reasons: 1.) all of the conference endpoints did not have sufficient privileges to mute all other participants, and 2.) we were unable to find DTMF codes that would allow an endpoint to mute all other endpoint in a conference. However, we found that all endpoints could be muted by using the RADVISION MCU administration console. The inability to pass this test proved that the privilege profile test did not pass. TANDBERG MCU 16+16 - Did not pass Using the administration console, we created a conference with one level of password hierarchy (See Test 2). We then dialed into the conference and were unable to find functionality to enable or restrict differing levels of functionality. We found that we were required to have access to the TANDBERG MCU 16+16 administration console to perform chairperson privileges, such as muting other participants. The inability to pass this test proved that the privilege profile test did not pass. TANDBERG MPS - Did not pass Multipoint Conferencing Unit Comparative Study 10
  • 11. Using the administration console, we created a conference with one level of password hierarchy (See Test 2). We then dialed into the conference and were unable to find functionality to enable or restrict differing levels of functionality. We found that we were required to have access to the TANDBERG MPS administration console to perform chairperson privileges, such as muting other participants. The inability to pass this test proved that the privilege profile test did not pass. Test case 4 - Automatic Password Generation In this test case, we determined if the MCU illustrated increased conference security being capable of automatically generating passwords. Automatic password generation increases conference security ensuring that every conference is password protected, complies with password integrity checks, and ensures password uniqueness. To prove this capability, we created a conference with no password and validated whether a password was automatically generated based on the condition of no password supplied. Polycom MGC-100 - Passed Using the administration console, we were able to create a password-protected conference. When we attempted to create a conference with no password, the Polycom MCU overrode this option and automatically assigned randomized passwords for both the chairperson and participants RADVISION viaIP 400 MCU - Did not pass Using the administration console, we were able to create a password-protected conference. The RADVISION MCU did not generate a random password, so we were required to enter a password. The MCU allowed single character passwords, so there did not appear to be any password integrity checks on the entered password. The inability to pass this test proved that the automatic password generation test did not pass. TANDBERG MCU 16+16 - Did not pass Using the administration console, we were able to create a password-protected conference. The MCU did not generate a random password, so we were required to enter a password. The MCU allowed single character passwords, so there did not appear to be any password integrity checks on the entered password. The inability to pass this test proved that the automatic password generation test did not pass. TANDBERG MPS - Did not pass Using the administration console, we were able to create a password-protected conference. The MCU did not generate a random password, so we were required to enter a password. The MCU allowed single character passwords, so there did not appear to be any password integrity checks on the entered password. The inability to pass this test proved that the automatic password generation test did not pass. Test case 5 - Password Integrity Validation In this test case, we determined if the MCU illustrated increased conference security by applying a password integrity check, checking that all passwords meet a minimum or maximum password length specified by the MCU. To prove this capability, we validated whether or not the MCU under test checked, validated, or rejected passwords entered from the endpoint. We dialed into a password-protected conference and attempted to enter a password. Polycom MGC-100 - Passed Upon creation of conference, we got a dialog that stated “status = STATUS_ILLEGAL_PASSWORD_LENGTH”. The conference required four or more numeric characters for a valid password. RADVISION viaIP 400 MCU - Did not pass Created a conference with a service that had password required. When password required was enabled, we were able to enter with passwords of only one character in length. There appeared to be no custom minimum limit to the password size. TANDBERG MCU 16+16 - Did not pass We were able to create a conference with a password with only one character. Multipoint Conferencing Unit Comparative Study 11
  • 12. TANDBERG MPS - Did not pass We were able to create a conference with a password with only one character. Test case 6 - Conference Password String Validation In this test case, we determined if the MCU illustrated increased conference security by validating the password as a complete string. To prove this capability, we created a conference with a password of “12345.” We then entered the conference with the password of “1234567” and reported whether or not we could connect to the conference. Polycom MGC-100 - Passed Using the administration console, we created a password-protected conference using a password of “12345.” We then used an endpoint to dial into the conference. The Polycom MCU prompted us to enter the conference password, followed by a “#” sign. Requiring the endpoint to terminate the password with the “#” sign allows the Polycom MCU to match exact string matches. We entered a password of “1234567” and the MCU denied our entry into the conference due to providing the wrong password. The rejection of the incorrect password string proved that the conference password string validation test passed. RADVISION viaIP 400 MCU - Passed Using the administration console, we created a password-protected conference using a password of “12345.” We then used an endpoint to dial into the conference. The RADVISION MCU prompted us to enter the conference password, followed by a “#” sign. Requiring the endpoint to terminate the password with the “#” sign allows the RADVISION MCU to match exact string matches. We entered a password of “1234567” and the MCU denied our entry into the conference due to providing the wrong password. The rejection of the incorrect password string proved that the conference password string validation test passed. TANDBERG MCU 16+16 - Did not pass Using the administration console, we created a password-protected conference using a password of “12345.” We then used an endpoint to dial into the conference. The TANDBERG MCU prompted us to enter the conference password. The TANDBERG MCU did not prompt us to terminate the password with the "#" sign, or some other termination key. We entered a password of “1234567” and the MCU connected us to the conference. Additionally, when we dialed "9871234567" as the password, we were connected to the conference apparently because the password string "12345" exists somewhere in the string we entered. We found that the MCU remains open accepting password characters. If any substring is entered that matches the expected password string, then the endpoint is entered into the conference. The ability to enter a conference with an incorrect password proved that the conference password string validation test did not pass. TANDBERG MPS - Did not pass Using the administration console, we created a password-protected conference using a password of “12345.” We then used an endpoint to dial into the conference. The TANDBERG MCU prompted us to enter the conference password. The TANDBERG MCU did not prompt us to terminate the password with the "#" sign, or some other termination key. We entered a password of “1234567” and the MCU connected us to the conference. Additionally, when we dialed "9871234567" as the password, we were connected to the conference apparently because the password string "12345" exists somewhere in the string we entered. We found that the MCU remains open accepting password characters. If any substring is entered that matches the expected password string, then the endpoint is entered into the conference. The ability to enter a conference with an incorrect password proved that the conference password string validation test did not pass. Test case 7 - Change Conference Password during a Conference In this test case, we determined if the MCU illustrated increased conference security by allowing a password assigned to a conference to be changed by an endpoint during an ongoing conference. To prove this capability, we created a conference with a password of “2222.” We then entered the conference and changed the password to “3333.” We then attempted to have a new endpoint join. We validated failure by typing “2222” Multipoint Conferencing Unit Comparative Study 12
  • 13. to ensure that we could not connect to the updated conference and also validated success by typing “3333” to ensure that we could connect to the conference. Polycom MGC-100 - Passed Using the administration console, we created a password-protected conference with a password of “2222.” We used an endpoint to dial into the conference and entered “2222” when prompted for the password. We then entered *77, the DTMF code to change the conference password, and changed the password to “3333.” We then had a second endpoint dial into the conference. We tried entering the conference by entering the password “2222,” were rejected from the conference, and asked to re-enter the password. We entered “3333” this time and were connected to the conference. The rejection of the incorrect password string and acceptance of the updated password proved that this test passed. RADVISION viaIP 400 MCU - Did not pass Using the administration console, we created a password-protected conference with a password of “2222.” We used an endpoint to dial into the conference and entered “2222” when prompted for the password. We were unable to use DTMF codes at the endpoint to change the password. Although the RADVISION MCU manual says that the MCU can use DTMF codes, we were unable to get a response from the MCU using DTMF codes. We were unable to find a parameter setting in the administration console to change this features. The inability to change the password within a conference proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU documentation, we were unable to find any information regarding using DTMF codes to administer the TANDBERG 16+16 MCU from an endpoint. We confirmed that DTMF codes, with the exception of password provision, are not supported on the TANDBERG MCU. We were unable to connect to the conference since it was locked. We were also unable to change the conference password during the conference via the administration console; however, the password string field was disabled. The inability to support DTMF codes to support this feature proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MCU documentation, we were unable to find any information regarding using DTMF codes to administer the TANDBERG MPS from an endpoint. We confirmed that DTMF codes, with the exception of password provision, are not supported on the TANDBERG MCU. We were unable to connect to the conference since it was locked. We were also unable to change the conference password during the conference via the administration console; however, the password string field was disabled. The inability to support DTMF codes to support this feature proved that this test did not pass. Test case 8 - Conference Lock In this test case, we determined if the MCU illustrated increased conference security by allowing an on going conference to be locked to deny access to any further connections. To prove this capability, we created a conference, then entered and locked the conference to stop further participants joining. We then attempted to dial into the conference to confirm that further entry was not allowed. Polycom MGC-100 - Passed Using the administration console, we created a conference. We used an endpoint to dial into the conference. We then locked the conference using DTMF codes (*70) and then, using a second endpoint, we dialed into the conference. We were unable to connect to the conference since it was locked. The inability to connect to a locked conference proved that this test passed. RADVISION viaIP 400 MCU - Passed Using the administration console, we created a conference. We used an endpoint to dial into the conference. We then locked the conference using the administration console and then, using a second endpoint, we dialed into the conference. We were unable to connect to the conference since it was locked. The inability to connect to a locked conference proved that this test passed. TANDBERG MCU 16+16 - Passed Multipoint Conferencing Unit Comparative Study 13
  • 14. Using the administration console, we created a conference. We used an endpoint to dial into the conference. We disabled the Allow Incoming Calls checkbox using the administration console and then, using a second endpoint, we dialed into the conference. The inability to connect to a locked conference proved that this test passed. TANDBERG MPS - Passed Using the administration console, we created a conference. We used an endpoint to dial into the conference. We disabled the Allow Incoming Calls checkbox using the administration console and then, using a second endpoint, we dialed into the conference. The inability to connect to a locked conference proved that this test passed. Test case 9 - Conference Hide In this test case, we determined if the MCU illustrated increased conference security by allowing an on going conference to be secured so that it cannot be monitored by any application or interface. To prove this capability, we created a conference, then entered the conference and secured the conference so that it cannot be monitored any application or interface. We then attempted to view the conference in the administration console. Polycom MGC-100 - Passed Using the administration console, we created a conference. We used an endpoint to dial into the conference. We then locked the conference using DTMF codes (*71). We then attempted to view the conference in the Polycom MCU administration console and could not see any information related to this call. The inability to view this hidden conference proved that this test passed. RADVISION viaIP 400 MCU - Did not pass Using the administration console and the RADVISION MCU documentation, we were unable to find any information to suggest that allowed us to hide conferences on the RADVISION MCU. The lack of a hide conference feature proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass Using the administration console and the TANDBERG 16+16 MCU documentation, we were unable to find any information to suggest that allowed us to hide conferences on the TANDBERG 16+16 MCU. The lack of a hide conference feature proved that this test did not pass. TANDBERG MPS - Did not pass Using the administration console and the TANDBERG MPS documentation, we were unable to find any information to suggest that allowed us to hide conferences on the TANDBERG MPS. The lack of a hide conference feature proved that this test did not pass. Test case 10 - Automatic Conference Termination – no show In this test case, we determined if the MCU illustrated increased conference security by terminating a conference if no connections are made within a set number of minutes from the start of the conference. We created a conference to terminate after two minutes before the first connection. We then used the administration console to confirm that conference terminated after two minutes had elapsed. Polycom MGC-100 - Passed We created a conference definition with Auto-termination enabled. We set the termination time to be two minutes. We created the conference and let it sit idle for two minutes. We observed the conference terminate via the MGC Manager console. The confirmation of the terminated conference proved that this test passed. RADVISION viaIP 400 MCU - Passed We created a conference with termination after no show using the advanced options. We set the termination time to be two minutes. We created the conference and let it idle for two minutes. We observed the conference terminate via the RADVISION administration console. The confirmation of the terminated conference proved that this test passed. Multipoint Conferencing Unit Comparative Study 14
  • 15. TANDBERG MCU 16+16 - Did not pass We created a conference with the Max Call Duration set to one minute. The conference displayed this information in the conference summary window. Once a participant called into the conference, a timer was set to allow a conference of 1-minute maximum. After one minute, the participant was silently disconnected. The conference remained created. If another participant called into the conference, the clock would reset and allow that participant to join that conference for one minute. The TANDBERG MCU is designed to terminate the conference call, but to leave the conference running for future connections. Regardless, the only manner to terminate a conference is by manually terminating it with the administration console. The inability to have a conference terminate by conference timeout confirms that this test did not pass. TANDBERG MPS - Did not pass We created a conference with the Max Call Duration set to one minute. The conference displayed this information in the conference summary window. Once a participant called into the conference, a timer was set to allow a conference of 1-minute maximum. After one minute, the participant was silently disconnected. The conference remained created. If another participant called into the conference, the clock would reset and allow that participant to join that conference for one minute. The TANDBERG MPS MCU is design to terminate the conference call, but to leave the conference running for future connections. Regardless, the only manner to terminate a conference is by manually terminating it with the administration console. The inability to have a conference terminate by conference timeout confirms that this test did not pass. Test case 11 - Automatic Conference Termination – after last person In this test case, we determined if the MCU illustrated increased conference security by terminating a conference after the last person leaves the conference. We created a conference to terminate one minute after the last person leaves the conference. We then used the administration console to confirm that conference terminated one minute after the last person left. Polycom MGC-100 - Passed We created a conference definition with Auto-termination enabled. We set the termination time to be one minute after the last person leaves. We created the conference, dialed into it, disconnected from it, and then let it sit idle for one minute. We observed the conference terminate via the MGC Manager console. The confirmation of the terminated conference proved that this test passed. RADVISION viaIP 400 MCU - Passed We created a conference with the administration console setting to terminate after last participant leaves. We created the conference, dialed into it, disconnected from it, and then let it sit idle for one minute. After one minute, the conference terminated on its own. The confirmation of the terminated conference proved that this test passed. TANDBERG MCU 16+16 - Did not pass We created a conference with the administration console. We noticed that the TANDBERG MCU only allowed the overall length of a conference call to be pre-determined. After reviewing the product and the TANDBERG MCU documentation, we determined that we must terminate all conferences manually. The failure to terminate the conference automatically proved that this test did not pass. TANDBERG MPS - Did not pass We created a conference with the administration console. We noticed that the TANDBERG MCU only allowed the overall length of a conference call to be pre-determined. After reviewing the product and the TANDBERG MCU documentation, we determined that we must terminate all conferences manually. The failure to terminate the conference automatically proved that this test did not pass. Test case 12 - Automatic Conference Termination – after chairperson profile exits In this test case, we determined if the MCU illustrated increased conference security by terminating a conference after the chairperson profile exits the conference. We created a conference to terminate after the chairperson profile exits the conference. We then dialed into the conference as the chairperson, and dialed in Multipoint Conferencing Unit Comparative Study 15
  • 16. with a separate endpoint as a participant. We then had the chairperson exit the conference. We used the administration console to confirm that conference terminated after the chairperson exited the conference. Polycom MGC-100 - Passed We created a conference definition with Terminate after Chairperson Exits enabled. We created the conference, dialed into it as the chairperson, and dialed into it as a participant. We then disconnected the chairperson from the conference and waited to ensure that the conference terminated. The confirmation of the terminated conference proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we determined that the first participant into a conference creates the conference instance. Therefore, when this participant exits the conference, the conference terminates. We also found no distinction between participant and chairperson in the conference. Based on the previous reasons, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any information regarding establishing a hierarchy of conference privileges; therefore, it cannot detect the difference between a chairperson dialing into a conference versus a participant dialing into a conference. We also determined that all conferences must be terminated manually. Based on the previous reasons, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any information regarding establishing a hierarchy of conference privileges; therefore, it cannot detect the difference between a chairperson dialing into a conference versus a participant dialing into a conference. We also determined that all conferences must be terminated manually. Based on the previous reasons, we proved that this test did not pass. Test case 13 - Conference Termination – during a conference In this test case, we determined if the MCU illustrated increased conference security by allowing a conference to be instantaneously terminated during an ongoing conference. To prove this capability, we created a conference and had three endpoints dial into the conference as participants. From one of the endpoints, we entered the DTMF code to terminate the conference. We used the administration console to confirm that conference terminated. Polycom MGC-100 - Passed Using the administration console, we created a conference. We used three endpoints to dial into the conference as participants. Using one endpoint, we then terminated the conference using DTMF codes (*87). We monitored the conference in the Polycom MCU administration console. The Polycom MCU deleted the conference from the console. The termination of this conference from the console proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we determined that there were no DTMF commands that allow an endpoint to terminate the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we determined that this product did not support DTMF codes with the exception of password provision. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass Multipoint Conferencing Unit Comparative Study 16
  • 17. After a thorough search of the TANDBERG MCU product and documentation, we determined that this product did not support DTMF codes with the exception of password provision. Based on this lack of feature capability, we proved that this test did not pass. Test case 14 - Conference Requires Chairperson to Start In this test case, we determined if the MCU illustrated increased conference security by allowing a conference to start only when the chairperson present. To prove this capability, we created a conference that requires the chairperson to start. From one of the endpoints, we dialed into the conference as a participant. If the endpoint was put on hold, we then used another endpoint and dialed into the conference as a chairperson. If both endpoints entered the conference, then we would know that the conference required a chairperson to start Polycom MGC-100 - Passed We created a conference with Start Conf Requires Chairperson enabled. We dialed into the conference as a participant and were put on hold. We then used a separate endpoint and dialed into the conference as the chairperson. At this point, the conference started, and thus proved the start of this test. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we determined that this product was unable to create a conference where participants are put on hold until the chairperson enters the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass The TANDBERG MCU does not support a chairperson or leader privileges; therefore, the conference cannot detect when a chairperson or leader enters the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass The TANDBERG MPS does not support a chairperson or leader privileges; therefore, the conference cannot detect when a chairperson or leader enters the conference. Based on this lack of feature capability, we proved that this test did not pass. Test case 15 - Participant Identification – entering a conference In this test case, we determined if the MCU illustrated increased conference security by prompting each connection to a conference to record their name which will be replayed to announce their entry in to the conference. To prove this capability, we created a conference with identification required. From one endpoint, we dialed into the conference and verified that it prompted for our name upon entering a conference. Polycom MGC-100 - Passed We created a conference with IVR settings set to rollcall enabled. We dialed into the conference with one endpoint and were prompted for our name before entering the conference. At this point, the conference started, and thus proved the start of this test. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we were unable to create a conference that prompted us for our name upon entering the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass The TANDBERG MCU does not support prompting for participant names. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass The TANDBERG MPS does not support prompting for participant names. Based on this lack of feature capability, we proved that this test did not pass. Multipoint Conferencing Unit Comparative Study 17
  • 18. Test case 16 - Participant Identification – leaving a conference In this test case, we determined if the MCU illustrated that when a connection to a conference is terminated, the name recorded prior to entry will announce its departure. To prove this capability, we created a conference with identification required. From two endpoints, we dialed into the conference and when prompted, we announced our name. We then disconnected one endpoint from the conference and verified that the other conference connection received the announcement of leaving the conference. Polycom MGC-100 - Passed Using the administration console, we created a conference with Roll Call enabled in the IVR settings. We connected to the conference using two endpoints. Upon entering the conference, we were prompted for our names, which we entered as instructed. We then had one of the endpoints disconnect for the conference. The name of the disconnecting endpoint was then announced to the conference as was heard by the remaining endpoint. The ability to hear the disconnecting endpoint proved that this test passed. RADVISION viaIP 400 MCU - Did not pass Using the administration console, we created a conference. However, we were unable to create conference that would prompt for participant identification upon entering the conference call. Since participant identification is not taken during the conference, the RADVISION MCU is unable to provide automatic participant identification upon leaving the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass Using the administration console, we created a conference. However, we were unable to create conference that would prompt for participant identification upon entering the conference call. We were able to find a capability for a tone upon exiting the call. Since participant identification is not taken during the conference, the TANDBERG MCU is unable to provide automatic participant identification upon leaving the conference. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass Using the administration console, we created a conference. However, we were unable to create conference that would prompt for participant identification upon entering the conference call. We were able to find a capability for a tone upon exiting the call. Since participant identification is not taken during the conference, the TANDBERG MPS is unable to provide automatic participant identification upon leaving the conference. Based on this lack of feature capability, we proved that this test did not pass. Test case 17 - Automatic Participant Identification by Name In this test case, we determined if the MCU illustrated increased conference security by identifying each participant by name when entering a conference. To prove this capability, we created a conference and connected one endpoint to the conference. Using the administration console, we monitored the connection of a participant into a conference and confirmed that the identification of the participant by name and was consistent with the actual endpoint that entered the conference. Polycom MGC-100 - Passed Using the administration console, we created a conference. We then used an endpoint to dial into the conference. The Polycom MCU prompted us to enter the conference identification and password. Once accepted into the conference, the MCU detected and identified the connection by name. The Polycom MCU performs this function by storing information about the participant in a local Access database managed by the Polycom administration console. The ability to provide this information proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we were unable to find any information regarding the ability to use a conference ID and password to identify the endpoint participant. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass Multipoint Conferencing Unit Comparative Study 18
  • 19. After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any information regarding the ability to use a conference ID and password to identify the endpoint participant by name. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Final After a thorough search of the TANDBERG MCU product and documentation, we were unable to find any information regarding the ability to use a conference ID and password to identify the endpoint participant by name. Based on this lack of feature capability, we proved that this test did not pass. Test case 18 - Roll Call In this test case, we determined if the MCU illustrated increased conference security by being able to replay all the names recorded prior to entering a conference, during the conference. To prove this capability, we created a conference with identification required. From two endpoints, we dialed into the conference. From one endpoint, we then requested a roll call of all connected endpoints. Polycom MGC-100 - Passed We created a conference definition with Roll Call enabled in the IVR settings. We created the conference and dialed into it as a participant. The MCU prompted us to enter our name, followed by the “#” sign. We followed these instructions and we were entered into the conference. We connected to the conference call using an additional endpoint but with a different name. From one of the endpoints, we selected the DTMF code (*33) to request a roll call of all participants. We received the roll call announcement. The confirmation of the roll call proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we were unable to create a conference that prompted us for names at the start of the conference, and use these names for a manual roll call. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we were unable to create a conference that prompted us for names at the start of the conference, and use these names for a manual roll call. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we were unable to create a conference that prompted us for names at the start of the conference, and use these names for a manual roll call. Based on this lack of feature capability, we proved that this test did not pass. Test case 19 - Automatic Dial Out In this test case, we determined if the MCU illustrated increased conference security by enabling the conference to automatically connect predefined participants when initiated. To prove this capability, we created a conference with predefined participants. Using an endpoint, we called into the conference and determined if the predefined participants received a call from the conference Polycom MGC-100 - Passed We created a conference definition with two predefined participants. We dialed into the conference and the MCU immediately dialed out to the two predefined participant endpoints. The confirmation of the predefined call proved that this test passed. RADVISION viaIP 400 MCU - Did not pass Although the conference can define specific invites for a conference call, the conference will not automatically dial out to them when the call is initiated by the chair. From the endpoint, we can invite another endpoint by typing Conference prefix and ID + ** + the endpoint that we want to invite. TANDBERG MCU 16+16 - Did not pass Multipoint Conferencing Unit Comparative Study 19
  • 20. The TANDBERG 16+16 MCU allows the administrator to create a conference and add participants. It will start this conference and dial out immediately once the conference is created. However, since the conference is created well before a call is desired to start or it’s scheduled start time, it cannot respond to a call leader starting the call and respond by calling out to conference participants. TANDBERG MPS - Did not pass The TANDBERG MPS allows the administrator to create a conference and add participants. It will start this conference and dial out immediately once the conference is created. However, since the conference is created well before a call is desired to start or it’s scheduled start time, it cannot respond to a call leader starting the call and respond by calling out to conference participants. Test case 20 - Operator Assisted Routing In this test case, we determined if the MCU illustrated increased conference security by allowing participants to be acknowledged and vetted first by a video operator before being manually placed into the destination conference. To prove this capability, we created a conference that required operator assistance. Using one endpoint, we created an operator conference. We then attempted to dial into the conference from a second endpoint and verified that an operator attended the call and placed us in our targeted conference. Polycom MGC-100 - Passed We first created an operator conference. To create an attended wait, we selected Msg Service Type to be Attended (Wait). We then dialed into the conference as a participant and requested assistance. The attendant monitored our assistance request using the administration console and moved us into the requested conference. The confirmation of the ability to get routed to the correct conference via operator assistance proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we found that for operator assistance, the participant must dial the operator number. The documentation states to "Enter the number of the delegated operator which the MCU dials when the operator invitation selected in the Conference Control interface during a conference. The operator is invited to join the conference for consultation and to provide support.” For this action to work as desired, the calling participant must call from within a conference; therefore, it cannot make a call to an operator for routing assistance. The confirmation of the inability to get routed to the correct conference via operator assistance proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG MCU does not support operator assistance of any sort. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG MPS does not support operator assistance of any sort. Based on this lack of feature capability, we proved that this test did not pass. Test case 21 - Request Private Operator Assistance In this test case, we determined if the MCU illustrated increased conference security by allowing a participant to request private operator assistance during a conference. Once acknowledged, the requesting participant and operator can hear and see each other in complete privacy before being placed back into the original conference. To prove this capability, we created and started a conference that provided operator assistance. Using one endpoint, we created an operator conference. We then dialed into the conference from a second endpoint, requested assistance, and then rejoin the conference. Polycom MGC-100 - Passed We first created an operator conference and dialed into the operator conference. We then created a new conference and dialed into as a participant. We used the DTMF code to be taken out of the conference and Multipoint Conferencing Unit Comparative Study 20
  • 21. request assistance. The DTMF code we used was *0. We then waited for the operator for assistance. Once the operator became available and saw our request on the administration console, we were taken into a private conference with the operator and then moved back into the destination conference. The confirmation of the ability to receive private operator assistance proved that this test passed. RADVISION viaIP 400 MCU - Did not pass We first created a conference and dialed into the conference. We used the DTMF code to be taken out of the conference and request assistance. The DTMF code we used was *0. When we used this DTMF code, we were not taken out of the conference call and operator assistance was not raised on the administration console. The confirmation of the inability to receive private operator assistance proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG MCU does not support private operator assistance request of any sort. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG MPS does not support private operator assistance request of any sort. Based on this lack of feature capability, we proved that this test did not pass. Test case 22 - Secure Breakout or Sidebar Session In this test case, we determined if the MCU illustrated increased conference security by allowing any number of conference participants to be moved securely and seamlessly from one conference to another and rejoined without disconnection. Each conference is completely independent and secure of the original with video and audio streams isolated to each conference. To prove this capability, we created and started several isolated conferences. We added four participants to a conference. We separated two participants from the conference without disconnection and validated that the audio and video streams were separate. Polycom MGC-100 - Passed We first created two conferences, conference 55 and 56, both with quad views. We dialed four endpoints into conference 55. We then highlighted two of the endpoints in the administration console, right-clicked on them, and selected to move them to conference 56. The two endpoints that we selected were moved to conference 56, so now there were two private conferences each with two participants. Confirmation of the ability to create two private conferences from one conference without participant disconnection proved that this test passed. RADVISION viaIP 400 MCU - Did not pass We created two conferences. We dialed into one of the conferences with four endpoints. We were unable to move the participants from one conference to another conference via the administration console. Additionally, the DTMF code required to move the audio into a subconference (*71) did not move the participant into a subconference. We were required to move the participant into the subconference via the management console. Confirmation of the inability to create two private conferences from one conference without participant disconnection proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we found that the TANDBERG MCU does not support conference separation or breakout of any sort. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG MPS does not support private operator assistance request of any sort. Based on this lack of feature capability, we proved that this test did not pass. Multipoint Conferencing Unit Comparative Study 21
  • 22. Test case 23 - Decreasing Password Attempts In this test case, we determined if the MCU illustrated increased conference security by restricting the number of password attempts to enter a conference before being disconnected. Protecting a conference for example with a single attempt of entering a password adds an additional level of security. To prove this capability, we defined and started a conference with a single logon attempt. We dialed into the conference and entered an incorrect password multiple times. We validated that the number of login attempts equaled the preset value. Polycom MGC-100 - Passed We first set the number of user input tries in the IVR Msg Services to three. We then created a conference with this IVR setting. We attempted to dial into the conference three times using an incorrect password. After the third attempt, the MCU automatically disconnected us from the conference queue. Confirmation of the ability to set decreasing password attempts proved that this test passed. RADVISION viaIP 400 MCU - Did not pass When we used the RADVISION MCU, we were given three chances to enter the correct password before being disconnected from the password entry queue. After a thorough search of the RADVISION MCU product and documentation, we were unable to determine how to change the number of invalid password login attempts. This product does provide security by limiting the number of invalid password attempts; however, the inability to set decreasing password attempts proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass When we used the TANDBERG MCU, we were given a set fixed time and to enter a fixed number of password entry attempts. We were unable to determine how to change the number of invalid password login attempts or how to change the total available time to enter the password. This product does provide security by limiting the number of invalid password attempts; however, the inability to set decreasing password attempts proved that this test did not pass. TANDBERG MPS - Did not pass When we used the TANDBERG MPS, we were given a set fixed time and to enter a fixed number of password entry attempts. We were unable to determine how to change the number of invalid password login attempts or how to change the total available time to enter the password. This product does provide security by limiting the number of invalid password attempts; however, the inability to set decreasing password attempts proved that this test did not pass. Test case 24 - Failed Conference Access In this test case, we determined if the MCU illustrated increased conference security as any participants who fail to enter a valid conference password for any reason would be automatically placed on hold. To prove this capability, we defined and started a conference with a single logon attempt. We dialed into the conference, entered an incorrect password, and waited to be put on hold. We used the administration console to identify participants placed on hold pending operator assistance. We validated this test case by finding participants on hold in the administration console and attending to them. Polycom MGC-100 - Passed We first created an operator assistance conference. We then created a standard conference and dialed into this conference as a participant. We entered an invalid password and were placed in the operator queue on the MCU. From the administration console, we were able to see the endpoint that was requesting assistance and send this endpoint into the operator conference for assistance. Confirmation of the ability to be moved into an operator assistance queue due to a did not pass conference access proved that this test passed. RADVISION viaIP 400 MCU - Did not pass We created a conference and dialed into this conference as a participant. We entered an invalid password and were allowed to retry entering a correct password three times. We were then disconnected from the conference. It appears that there is no administration console setting that allows us to have participants move to operator assist upon a failed conference access. Confirmation of the inability to be moved into an operator assistance queue due to a failed conference access proved that this test did not pass. Multipoint Conferencing Unit Comparative Study 22
  • 23. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG 16+16 MCU product and documentation, we found that the TANDBERG 16+16 MCU does not support a feature to put a participant on hold and assist them with password problems. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MPS product and documentation, we found that the TANDBERG MPS does not support a feature to put a participant on hold and assist them with password problems. Based on this lack of feature capability, we proved that this test did not pass. Test case 25 - Secure Non-Password Conference In this test case, we determined if the MCU illustrated increased security by forcing dial out systems to acknowledge connection to the MCU with a DTMF tone when prompted. If no response is detected the connection will be terminated, eliminating connection to endpoints where it may be set to auto answer, where no one is present or to passive recording devices. To prove this capability, we defined and started a conference with a dial out participant defined. If the endpoint failed to respond when prompted for a DTMF tone, such as an answer machine might respond, then the MCU should disconnect that endpoint from the conference. Polycom MGC-100 - Passed We defined a conference with a dial out participant defined. We created the conference and then dialed into the conference using one of the endpoints. We then initiated the conference to dial out to the defined dial out participant. The conference dialed out and waited for a response from the new endpoint. When it received no response, then the conference disconnected the endpoint. Confirmation of the ability to disconnect an insecure non-password endpoint proved that this test passed. RADVISION viaIP 400 MCU - Did not pass We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint. The conference dialed out and immediately connected the new endpoint. The conference connected to the dialed endpoint regardless of whether the connecting party was the correct connection. Confirmation to connect to unknown endpoints proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint. The conference dialed out and immediately connected the new endpoint. The conference connected to the dialed endpoint without DTMF code confirmation. Confirmation to connect to unknown endpoints proved that this test did not pass. TANDBERG MPS - Did not pass We created a conference by dialing into a new conference definition. We then dialed out to a new endpoint. The conference dialed out and immediately connected the new endpoint. The conference connected to the dialed endpoint without DTMF code confirmation. Confirmation to connect to unknown endpoints proved that this test did not pass. Test case 26 - Administration Hierarchy In this test case, we determined if the MCU illustrated an administration hierarchy. This hierarchy is a set of profiles that administrators can assign, or be assigned to, to enable or restrict access capabilities according to their needs. Assigning administrators with different profiles and rights provides greater security to the overall system. Using the administration console, we determined the number of levels of permissions that the administration console allowed us to create. Polycom MGC-100 After reviewing the Polycom MCU documentation, we found that the MGC Manager administration console supported three levels of operators. They were: 1. Attendant Multipoint Conferencing Unit Comparative Study 23
  • 24. 2. Ordinary 3. Superuser The attendant operator can only define and manage new conferences, gateway sessions, meeting rooms, and participants. The attendant operator does not have access to the MCU Configuration icon and MCU Utilities. Ordinary operators can perform all the tasks an attendant operator does. In addition, ordinary operators can also view the configurations of the modules in the MGC-100. Superuser operators can perform all tasks attendant and ordinary operators do. In addition, superuser operators can define and delete other operators, and define network services. While ordinary operators can view the configurations of the modules in the MGC-100, only the superuser operator can modify the configuration of a module. RADVISION viaIP 400 MCU After reviewing the RADVISION MCU documentation, we found that the RADVISION system allowed two levels of access privileges. They were: 1. Chair controller 2. User Additionally, the system offers two levels of console management. They were: 1. Operator 2. Administrator TANDBERG MCU 16+16 After reviewing the RADVISION MCU documentation, we found that the TANDBERG 16+16 MCU could not assign different levels of privileges to call participants. We found only one level of administration level. Figure 12. TANDBERG 16+16 MCU System Configuration, Miscellaneous Configuration dialog box TANDBERG MPS After reviewing the RADVISION MPS documentation, we found that the TANDBERG MPS could not assign different levels of privileges to call participants. We found only one level of administration level. Multipoint Conferencing Unit Comparative Study 24
  • 25. Figure 13. TANDBERG MPS MCU System Configuration, Miscellaneous Configuration Settings dialog box Test case 27 - Administration Login Identification In this test case, we determined if the MCU illustrated increased conference security by identifying all login connections to the MCU. The MCU should provide the name, profile date of login and device. To prove this capability, we identified the current administration connections to the MCU by name and profile. We also measured the ability to see who is logged in and how they are logged in. Polycom MGC-100 - Passed Within the Polycom Administration console, by selecting the Connections drilldown icon on the left, we could determine that we were the only connection logged into the MGC manager. We could also determine that we were a superuser, our administration name, when we connected, from what location, and using which protocol. Confirmation of the ability to determine the administration login identification proved that this test passed. RADVISION viaIP 400 MCU - Did not pass Within the RADVISION MCU administration console, we were unable to determine which users are logged in the console. The system allows the first administrator to enter into the console and is granted full permissions. All others who then connect to the console are granted read-only privileges. Confirmation of the inability to determine the administration login identification proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass Within the TANDBERG MCU administration console, we found that it does not display the number of current connections, the connection identification, and the connection profile. Confirmation of the inability to determine the administration login identification proved that this test did not pass. TANDBERG MPS - Did not pass Within the TANDBERG MPS administration console, we found that it does not display the number of current connections, the connection identification, and the connection profile. Confirmation of the inability to determine the administration login identification proved that this test did not pass. Test case 28 - Conference Countdown to Termination In this test case, we determined if the MCU illustrated increased conference security by terminating a conference definition after a set number of activations. To prove this capability, we set a conference to terminate after two activations. Polycom MGC-100 - Passed We created an instance of a meeting room object and set the number of occurrences to be two in the Meet Me per Conference dialog box. We dialed in to the conference twice and after each disconnection, the MCU reduced the number of conference activations by one in the Meet Me per Conference dialog box. After we Multipoint Conferencing Unit Comparative Study 25
  • 26. accessed the meeting twice, the conference definition was deleted and we were unable to activate the conference further. Based on this feature capability, we proved that this test passed. RADVISION viaIP 400 MCU - Did not pass After a thorough search of the RADVISION MCU product and documentation, we found that this MCU does not support conference termination after a specific number of activations. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MCU 16+16 - Did not pass After a thorough search of the TANDBERG MCU product and documentation, we found that conferences could only be terminated manually. We were able to terminate the conference only by manually terminating the conference in the administration console. Based on this lack of feature capability, we proved that this test did not pass. TANDBERG MPS - Did not pass After a thorough search of the TANDBERG MPS product and documentation, we found that conferences could only be terminated manually. We were able to terminate the conference only by manually terminating the conference in the administration console. Based on this lack of feature capability, we proved that this test did not pass. In summary, the Polycom MGC-100 system passed all 27 test cases, as compared to five passed by the RADVISION viaIP 400 MCU and one by the TANDBERG 16+16 and MPS MCU products. Additionally, as shown in test case 26, the Polycom MCU demonstrated three levels of administration hierarchy, compared to two levels for the RADVISION MCU and one level for the TANDBERG MCU. Overall, the Polycom MCU demonstrated the most complete set of security and authentication feature capabilities of the MCU products in our review. Multipoint Conferencing Unit Comparative Study 26
  • 27. Versatility Testing The Versatility test cases focus on determining the product’s ability to provide a maximum level of versatility through the set of features provided by each MCU under test. Within versatility testing, we tested features related to transcoding, continuous presence, conference routing, conference types, and resource management. Test cases 29 through 33 address the ability of each MCU to perform transcoding. Transcoding is the process of converting a media stream from one format to another. When related to MCU functionality, transcoding is the process of managing audio and video stream information from endpoints with different bandwidth connections, different video protocols and formatting capabilities and different audio algorithms in such a manner so that they can work together successfully within a single conference at their optimum capabilities. To measure the transcoding capabilities for test cases 29 through 33, we generated multiple conference streams into the MCU under test. This methodology allowed us to inject many conferences with fixed parameters, such as protocols, formats, and algorithms into the MCU under test and verify the maximum number of unique audio and video streams that the MCU was able to successfully transcode. To generate a large number of unique streams, we used a Polycom MGC-100 MCU to create specific conference parameters and the connected into the MCU under test with these fixed parameters. As can be seen in Figure 16, we connected this MCU into our test bed network. Test case 29 - Transcoding Bandwidths In this test case, we determined if the MCU illustrated that all supported bandwidths up to two Mbps can coexist in the same conference without prior configuration and that by facilitating any combination of bandwidths in a single conference improves connectivity and reliability. We will test this capability by creating a conference definition and dial into the conference using the following bandwidths: • 64 kbps • 128 kbps • 192 kbps • 256 kbps • 384 kbps • 320 kbps • 512 kbps • 768 kbps • 1152 kbps • 1472 kbps • 1536 kbps • 1920 kbps Polycom MGC-100 We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The following list is a set of the streams that we used during our testing. The bolded parameters illustrate that the transcoding focused on the bandwidth settings. • 64 kbps, H.261, CIF • 128 kbps, H.261, CIF • 192 kbps, H.261, CIF • 256 kbps, H.261, CIF • 320 kbps, H.261, CIF • 384 kbps, H.261, CIF • 512 kbps, H.261, CIF • 768 kbps, H.261, CIF • 1152 kbps, H.261, CIF • 1472 kbps, H.261, CIF Multipoint Conferencing Unit Comparative Study 27
  • 28. 1536 kbps, H.261, CIF • 1920 kbps, H.261, CIF We were able to connect these 12 streams, each with a unique bandwidth into a single conference on the Polycom MCU. We inspected the properties of each incoming connection to ensure that all bandwidth requirements were met and validated that conference transcoding was being performed by the MCU as expected. Confirmation of the ability to transcode multiple bandwidths proved that this MCU was able to transcode all available bandwidth capabilities. RADVISION viaIP 400 MCU Using the administration console, we used the RADVISION MCU interface to create video scheme settings with different bandwidths. We found a limitation in the user interface that prevented us from creating more than three video scheme settings. Figure 14 shows the user interface with this limitation. Notice that the button that allows the user to create additional streams, the Add button, became disabled after three video scheme settings has been created. Figure 14. RADVISION viaIP 400 MCU View Settings dialog box If we edit the first setting in the list, and change the mode from Basic to Non_Transcoding, then we are able to return to the View Settings Screen and add a fourth video scheme setting. However, we were able to perform this only when the Max Layout Continuous Presence is set to Full Screen. If we change the Max Layout to Multipoint Conferencing Unit Comparative Study 28
  • 29. anything other than Full Screen, then we are unable to add more than three video scheme settings. Confirmation of the ability to transcode multiple bandwidths proved that this MCU was able to transcode all available bandwidth capabilities. TANDBERG MCU 16+16 Using the administration console, we used the TANDBERG MCU interface to create a new conference. We dialed into the conference using several endpoints. We noticed that as we added new endpoints into the conference that the MCU maintained two bandwidth points for transcoding. The first two bandwidths that connect to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the bandwidth of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the bandwidth of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit will be established for the conference is equal to this newest bandwidth. Additionally, we found confirming documentation in Section 4.4.4.3 of the document entitled “Technical Description of TANDBERG MCU with software version D2 (TANDBERG D12925 Rev. 02)”. In summary, we found that the TANDBERG MCU was able to rate match multiple input streams to a maximum of two transcoded bandwidth outputs. TANDBERG MPS Using the administration console, we used the TANDBERG MCU interface to create a new conference. We dialed into the conference using several endpoints. We noticed that as we added new endpoints into the conference that the MCU maintained two bandwidth points for transcoding. The first two bandwidths that connect to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the bandwidth of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the bandwidth of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit will be established for the conference equal to this latest bandwidth. Additionally, we found confirming documentation in the document entitled “MPS User Manual.” in Section 6.2.3 on the Enhanced Video Transcoding of this document. In summary, we found that the TANDBERG MCU was able to rate match multiple input streams to a maximum of two transcoded bandwidth outputs. Test case 30 - Transcoding Video Protocols In this test case, we determined if the MCU illustrated that all supported video protocols can coexist in the same conference without prior configuration and that by facilitating any combination of video protocols in a single conference improves connectivity and reliability. We will test this capability by creating a conference definition and dial into the conference using the following bandwidths: • H.261 • H.263 • H.264 Polycom MGC-100 We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The bolded parameters illustrate that the transcoding focused on the video protocol settings. • 64 kbps, H.261, CIF • 64 kbps, H.263, CIF • 64 kbps, H.264, CIF We were able to connect these three streams, each with a unique video protocol into a single conference on the Polycom MCU. We inspected the properties of each incoming connection to ensure that all protocol Multipoint Conferencing Unit Comparative Study 29
  • 30. requirements were met and validated that conference transcoding was being performed by the MCU as expected. Confirmation of the ability to transcode multiple video protocol proved that this MCU was able to transcode all available video protocol capabilities. RADVISION viaIP 400 MCU Using the administration console, we used the RADVISION MCU interface to create video scheme settings with different video protocols. We found a limitation in the user interface that prevented us from creating more than three video scheme settings. Figure 14 shows the user interface with this limitation. When we tested the RADVISION MCU using the on-board video card, i.e. MVP mode, we were able to transcode using only H.261 and H.263 video protocols. H.264 was unavailable. When we tested the MCU card, i.e. MP mode, we than we able to select H.261, H.263, and H.264, but only in non-transcoded conference. TANDBERG MCU 16+16 Using the administration console, we used the TANDBERG MCU interface to create a new conference. We dialed into the conference using several endpoints. We noticed that as we added new endpoints into the conference that the MCU maintained two video protocols for transcoding. The first two video protocols that connected to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the protocol of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the protocol of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit will be established for the conference equal to this latest video protocol. Additionally, when we created a conference and successfully connected a H.261 endpoint, and connected a H.263 endpoint. When we connected a H.264 endpoint in to the conference, the conference terminated in the administration console. In summary, we found that the TANDBERG MCU was able to accept multiple input streams to a maximum of two distinct video protocol outputs. TANDBERG MPS Using the administration console, we used the TANDBERG MPS interface to create a new conference. We dialed into the conference using several endpoints. We noticed that as we added new endpoints into the conference that the MCU maintained two video protocols for transcoding. The first two video protocols that connected to the conference define the upper and lower limits of the MCU transcoding. If additional endpoints connect to the conference between the upper and lower limits, then the protocol of the latest endpoint entered into the conference will be reduced to meet the lower limit. If the protocol of the latest endpoint entering in the conference is less than the lower limit, then a new lower limit will be established for the conference equal to this latest video protocol. In summary, we found that the TANDBERG MPS was able to accept multiple input streams to a maximum of two distinct video protocol outputs. Test case 31 - Transcoding Video Formats In this test case, we determined if the MCU illustrated that all supported video formats can coexist in the same conference without prior configuration and that by facilitating any combination of video formats in a single conference improves connectivity and reliability. We will test this capability by creating a conference definition and dial into the conference using the following bandwidths: • QCIF • CIF • 4CIF Polycom MGC-100 We used the second Polycom MGC-100 MCU to generate the following unique audio and video streams. The bolded parameters illustrate that the transcoding focused on the video format settings. Multipoint Conferencing Unit Comparative Study 30