MGC-50/MGC-100 Getting Started Guide
Table
Field | Description |
|
|
Service mode | Note: In current Cisco implementations when |
(cont.) | there is more than one IP card in use, the |
| gatekeeper selects one of the boards that are |
| registered with the dialed string. Thus the system |
| does not automatically forward the calls to an |
| available card. To overcome this problem, |
| combine Register as a Gateway with |
| Forwarding. However, this method only works for |
| defined |
| • PseudoGatekeeper – Each IP card acts and is |
| defined as a gatekeeper allowing Board Hunting |
| to be performed. In PseudoGatekeeper mode, |
| the IP cards are manually registered with the |
| gatekeeper as neighboring gatekeepers. When |
| the gatekeeper receives an Admission Request |
| (ARQ) message from a participant looking for the |
| conference alias, the gatekeeper will forward the |
| request to all “neighboring gatekeepers” (IP |
| cards) simultaneously. The first card that has |
| enough resources to handle the call accepts the |
| request. |
| Note: Gatekeepers often send a multicast LRQ |
| message hoping that there is a gatekeeper that |
| can help with the translation. Multicast LRQ |
| messages are not handled by the MCU IP cards |
| within the Pseudo Gatekeeper mode. |
| • |
| Avaya environment only. |
|
|
Prefix | Enter the same prefix that was defined for the |
| MCU’s IP Network Service in the gatekeeper (if it |
| was defined in advance) or that will be used to |
| register the MCU in the gatekeeper later. This |
| number is used as part of the |
| participants. |
| Usually, one Network Service is defined for all IP |
| cards to let the system automatically manage the |
| resources allocated to conferences. In this case, the |
| system finds the free cards from the pool of cards |
| registered with the IP Network Service. |
|
|
