 |
MCU 4215 |
| хост: mcu |
|
MCU 4215 |
| хост: mcu |
Help contents >
Managing conferences >
Port reservation
|
Search/Print Указатель |
The MCU is able, if required, to allocate its available media ports in advance to specific conferences. This means that it is able to guarantee that a certain number of participants will be able to join that conference, irrespective of how many other people are using the MCU for other conferences at the same time.
There are three types of media ports available on the MCU, video ports, audio-only ports, and streaming and content channel ports.
For information about the number and type of ports provided by each MCU model, refer to MCU port matrix.
The term video port refers to a port that can be used by a video-conferencing endpoint for a call. Thus, a video port includes both video and audio streams (bidirectionally) and so the number of video ports available represents the number of "normal" video calls that the MCU is able to maintain simultaneously.
In general, each endpoint in a conference is able to use either a video port or an audio-only port, though normally the MCU will assign video ports to video-capable devices and audio-only ports to audio-only devices.
If a video-capable device joins a conference which has just audio-only ports available, the MCU will assign it an audio-only port – that participant will be able to listen to other people and contribute their own audio to the conference but the MCU will not transmit video to it (and will not use any video received from it). If an audio-only device such as a simple telephone joins a conference which has just video ports available, the MCU will assign it a video port, which includes audio capability. The video capability of that allocation will not be used, but the audio device will be able to participate as normal in the conference. The exception to this is VNC - because this is a video-only protocol, the MCU does not permit VNC connections to use audio-only ports.
Streaming a conference requires use of a video port or a streaming and content channel port. Where streaming and content channel ports are provided, streaming viewers and conferences' content channel (H.239 or BFCP) video allocations will use the streaming and content channel ports rather than the available video ports; where streaming and content channel ports are not provided, streaming viewers and content channel allocations will use available video ports.
If a streaming and content channel port or a video port is unavailable (or not allocated in advance when the MCU is in Reserved mode), it will not be possible to stream that conference. If a video port has been allocated for streaming a conference, any number of streaming viewers will be able to view that conference via streaming, at any combination of available bit rates.
The total number of media ports available depends on the MCU model; refer to the product datasheets available on the web site, or to MCU port matrix for more information.
How MCU media ports are allocated, and which options and settings are available, is controlled by the Media port reservation setting on the Settings > Conferences page.
This is the mode that the unit runs in when the Media port reservation setting is configured as Disabled, and is the mode that the MCU uses by default. With this scheme, you can specify a maximum value for the number of video and audio-only ports each conference is allowed to use on the Conference configuration page. These limits are optional, and by default there is no configured limit.
The configured limits are strictly maximum values; in particular, setting such a limit does not guarantee that that many participants will be able to join the conference. It is perfectly possible to set these values such that the sum of the configured limits across all active conferences exceeds the total number of ports available on the MCU.
This is the mode that the unit runs in when the Media port reservation setting is configured as Enabled. With this scheme, each conference must be configured with a number of video ports to reserve and a number of audio-only ports to reserve. These values differ from the maximum port values set in Unreserved mode in a number of ways:
In order to honor configured port reservations, the MCU must ensure that at any given time the number of reserved ports does not exceed the total media capacity. This entails some level of clash detection when you schedule conferences change their configuration.
The MCU considers two conferences to be clashing if they can ever be active simultaneously. When validating a conference schedule, the MCU looks at the maximum number of ports reserved by other conferences which can be active at the same time, and checks that the number of ports requested by the conference being added or changed is guaranteed to be available. If, for instance, the MCU has 20 video ports available in total, it will not be possible to set up two conferences which require 15 video ports each if they are scheduled such that they ever overlap.
In the simple case of conferences which start at specific times and end at specific times (or, indeed, are permanent), it is easy to see whether they clash. The more complex cases involve repetition, and it is important to bear in mind that port reservations are only permitted when the MCU can guarantee them for every repetition of a conference. As an example, a conference scheduled to run from 08:00 to 10:00 on the second Monday of each month will be deemed to clash with a conference configured to run from 09:00 to 09:30 every Monday, even though the former will only really clash with the latter every fourth or fifth week.
In general, to make best use of the available MCU media ports, you should not schedule conferences to be longer than needed, and you should limit repetitions, either by end date or number, wherever possible.
Because port reservations are mandatory in Reserved mode every active conference must have configured values for the number of video ports and the number of audio-only ports to reserve for it. In turn this means that every active conference must be configured, and therefore ad hoc conferences are not permitted when in Reserved mode.
This affects the operation of the MCU in the following ways:
If a participant calls in to the MCU and connects to an auto attendant, the MCU does not know which conference they will join until they make a selection from the auto attendant menu.
In Unreserved mode, the auto attendant connection allocates a media port from those not currently in use. If all of the media ports are in use, the endpoint's connection will be dropped by the MCU.
In Reserved mode, the auto attendant connection effectively "borrows" a media port from those not currently in use. However, this borrowed media port has a lower priority than a media port used by a conference participant, and if the auto attendant connection "borrows" the last remaining media port, then that connection will be dropped if another endpoint connects directly to a conference and requires a reserved media port.
In general, changing port reservation mode when there are active connections is not recommended. The effects of changing mode include, but are not necessarily limited to:
| © TANDBERG 2003-2010, Сведения о лицензии |