Polycom 4000 用户手册
RealPresence Collaboration Server (RMX) 1500/1800/2000/4000 Administrator’s Guide
Polycom®, Inc.
296
input for the required conference ID or password. If the input is incorrect, the application server will
request the MCU to replay the audio file and collect the DTMF input again. The MCU transfers the
DTMF input to the application server for revalidation.
5 When the application server has completed the pre-conference IVR, the application server routes
the call to a VMR with the collected password appended to the following dial string:
<conf-id>**<password>@mcu-sig-ip.
The call is disconnected from the application server. The MCU now has control of the call.
<conf-id>**<password>@mcu-sig-ip.
The call is disconnected from the application server. The MCU now has control of the call.
6 The call is transferred to a conference, which can reside on another MCU.
Call Flow for Standalone TIP Endpoints
The following describes how a standalone TIP endpoint call is placed into the IVR-controlled Entry Queue
and is then connected to a conference:
and is then connected to a conference:
1 A TIP call is routed through the application server to the IVR-controlled Entry Queue. TIP endpoints
can either have a single screen or multiple screens.
2 The MCU answers the call and waits for the IVR media file requests from the application server. The
MCU does not control the call while the call is in the Entry Queue.
3 The application server may request, through the MCCF channel - IVR package, to play an audio file
and display a video slide. When the TIP endpoint uses multiple screens, the video slide is displayed
on the main screen only. When the audio file has finished playing, the MCU notifies the application
server that the audio file has been played for the call.
4 The application server may request, through the MCCF channel - IVR package, to collect DTMF
input such as a conference ID or password, from the caller. When the TIP endpoint uses multiple
screens, the DTMF input is collected only once from the main screen. The DTMF input is transferred
from the MCU to the application server. When the application server receives the DTMF input, it
validates the input for the required conference ID or password. Because TIP uses DTLS, it can
optionally enable re-keying of DTMF input and the calls to the Entry Queue and the conference can
be encrypted.
5 When the application server has completed the pre-conference IVR, the application server routes
the call to a VMR with the collected password appended to the following dial string:
<conf-id>**<password>@mcu-sig-ip.
The call is disconnected from the application server. The MCU now has control of the call.
<conf-id>**<password>@mcu-sig-ip.
The call is disconnected from the application server. The MCU now has control of the call.
6 The call is transferred to a conference, which can reside on another MCU.
Call Flow for TIP Endpoints from a Polycom ITP System
The following describes how a TIP call from Cisco TPS endpoints or TIP calls from a Polycom ITP system
working as a TIP call is placed into the IVR-controlled Entry Queue and is then connected to a conference:
working as a TIP call is placed into the IVR-controlled Entry Queue and is then connected to a conference:
1 A TIP call is routed through the application server to the IVR-controlled Entry Queue.
2 The MCU answers the call and waits for the IVR media file requests from the application server. The
2 The MCU answers the call and waits for the IVR media file requests from the application server. The
MCU does not control the call while the call is in the Entry Queue.
3 While the call is in the Entry Queue, video is only displayed on the main screen.
4 DTMF input is collected only once from the main screen. Because TIP uses DTLS, it can optionally
4 DTMF input is collected only once from the main screen. Because TIP uses DTLS, it can optionally
enable re-keying of DTMF input and the calls to the Entry Queue and the conference can be
encrypted.