Cisco Cisco TelePresence MCU 4510 Release Notes
New features in 4.4
Cisco TelePresence MCU 4.4(3.57) Maintenance Release Notes
Page 4 of 28
Effect of certificate-based authentication on the API
If certificate-based authentication is allowed (option 3 above), the standard authentication parameters
(authenticationUser and authenticationPassword) are required in API messages only if the client
certificate is insufficient for login purposes.
(authenticationUser and authenticationPassword) are required in API messages only if the client
certificate is insufficient for login purposes.
If certificate-based authentication is required (option 4 above), the standard authentication parameters are
ignored altogether and a client certificate must be used for login purposes, meaning that only HTTPS access
is possible.
ignored altogether and a client certificate must be used for login purposes, meaning that only HTTPS access
is possible.
Persistent calls
The MCU's redial behavior has been extended to have greater scope and flexibility. You can now apply call
persistence on a per participant basis. This feature is configurable to distinguish between a connection
ending normally or failing, and for how persistent the MCU is in trying to restore the connection.
persistence on a per participant basis. This feature is configurable to distinguish between a connection
ending normally or failing, and for how persistent the MCU is in trying to restore the connection.
The persistence feature applies to participants and not to conferences or templates. Persistence can be
applied to preconfigured endpoints, API-configured participants, or participants manually added to an active
conference.
applied to preconfigured endpoints, API-configured participants, or participants manually added to an active
conference.
A call can only be made persistent before the MCU makes the call. Persistence cannot be applied to the call
while the participant is connected or connecting, and cannot be applied to incoming calls. However, a
preconfigured endpoint's persistence can be changed while a call is active, and the changes will be effective
from the next call onwards.
while the participant is connected or connecting, and cannot be applied to incoming calls. However, a
preconfigured endpoint's persistence can be changed while a call is active, and the changes will be effective
from the next call onwards.
The four levels of persistence are:
n
Never redial - The MCU tries only once to connect to this participant.
n
Redial until connected - The MCU only retries to connect to this participant when failing on first
establishing a connection, and only then if the connection is not deliberately rejected; the MCU never
retries if the connection fails after it is established.
establishing a connection, and only then if the connection is not deliberately rejected; the MCU never
retries if the connection fails after it is established.
n
Redial on unexpected disconnection - The MCU retries on connection as in the previous option, but also
retries if the connection fails after it is established. It does not retry if the connection is deliberately ended
by either party.
retries if the connection fails after it is established. It does not retry if the connection is deliberately ended
by either party.
n
Redial on any disconnection - The MCU retries on first connection and also on subsequent connection
failure, as in the previous two options, but also retries if the connection is deliberately ended by the
endpoint.
failure, as in the previous two options, but also retries if the connection is deliberately ended by the
endpoint.
When you configure the MCU to persist a call, you can choose whether it will do so according to a limited or
unlimited retry schedule. The limited schedule allows up to 10 reconnect attempts after which the MCU will
stop trying. If you select the unlimited schedule, the MCU persists until the connection is made or until the
participant's active state is destroyed (conference ends or participant is deleted).
unlimited retry schedule. The limited schedule allows up to 10 reconnect attempts after which the MCU will
stop trying. If you select the unlimited schedule, the MCU persists until the connection is made or until the
participant's active state is destroyed (conference ends or participant is deleted).
If a persistent call using the limited retry schedule drops repeatedly, the MCU stops reconnecting after three
successful reconnections. That is, the MCU will abandon a persistently failing call if it is configured to use
the limited retry schedule.
successful reconnections. That is, the MCU will abandon a persistently failing call if it is configured to use
the limited retry schedule.
Note: If an endpoint fails to use the correct signaling, and that participant is configured to be redialed on
unexpected disconnection, then the MCU may interpret a deliberate rejection or disconnection as
unexpected and redial the participant. Similarly, incorrect signaling may cause the MCU to not redial when
the user may have expected call persistence. If you are experiencing this kind of issue, you can work around
the incorrect behavior by changing that particular endpoint's redial setting.
unexpected disconnection, then the MCU may interpret a deliberate rejection or disconnection as
unexpected and redial the participant. Similarly, incorrect signaling may cause the MCU to not redial when
the user may have expected call persistence. If you are experiencing this kind of issue, you can work around
the incorrect behavior by changing that particular endpoint's redial setting.