|
by Jason Wydra
Gateway ProtocolsCisco routers are capable of using several open standard gateway protocols while communicating between two VoIP endpoints or a Cisco CallManager. The fact that these protocols are open standards lends to their interoperability with other vendors' products.
H.323 was developed by the International Telecommunications Union (ITU). An extension of ITU-T standard H.320, it enables videoconferencing over LANs and other packet-switched networks, as well as video over the Internet. An H.323 Gateway is an endpoint that provides for real-time, two-way communications between H.323 terminals on a packet-based network and other terminals on a switched circuit network, or to another H.323 Gateway. Two other protocols, H.225 and H.245, work alongside H.323. The H.245 channel provides a method for carrying control messages between two H.323 endpoints. H.225 formats the transmitted video, audio, data, and control streams into messages for output to the network. In addition, it performs logical framing, sequence numbering, error detection, and error correction for each media type. The following diagram is an example H.323 terminal. On the left side is the interface, which can be data, video, or voice. There's also the system control interface that is required for all terminals.
Figure 1. Components of an H.323 Terminal
The System Control Unit (H.245, H.225.0) provides signaling for proper operation of the H.323 terminal. It provides for call control, capability exchange, signaling of commands and indications, and messages to open and fully describe the content of logical channels. H.323 also provides a RAS (Registration, Admission, and Status) channel. It uses this channel for auto-discovery of a Gatekeeper. The Gatekeeper is a device that provides call admission control. We will discuss its function in more detail later in this tutorial. The endpoint sends a Gatekeeper request message (GRQ) to a multicast address. The endpoint can then register with a Gatekeeper once it responds with a Gatekeeper confirmation message (GCF).
H.323 is a popular protocol used on Cisco gateways because of its flexibility. The only problem is that if the CallManager fails, all active calls fail. With MGCP, we have call preservation. Any calls that are in a connect state will stay active until the call is cleared by the user.
MGCP (Media Gateway Control Protocol) takes all of the brains out of the Gateway and moves them to the CallManager. Instead of having the route plan configured on the H.323 Gateway with dial peers, the route patterns are configured on the CallManager. The CallManager has all the information needed to route a call to a particular gateway. The Gateway voice ports still need to be configured for the proper signaling but you won't find dial peers for MGCP. The exception is when a router is using SRST (survivable remote site telephony) or H.323 for fallback. We will discuss SRST later. You configure dial peers on the MGCP gateway to be used in the event your CallManager fails. This way, the local site can still place and receive calls via the PSTN.
MGCP is defined in RFC 2705. It's a plain-text protocol that uses a master/slave relationship to fully control a gateway and its associated ports. The plain-text commands are sent using UDP port 2427. MGCP refers to endpoints as any voice port on a gateway either digital or analog. Call agents in MGCP refer to the devices that actually control the Gateway, i.e., the CallManager. MGCP uses a set of commands and responses between the call agent and the Gateway. These commands are sent in plain text and are listed below:
Table 1. MGCP Control Messages
Command | Message Name | Sent By | Description |
AUEP | AuditEndpoint | CallManager | Determines the status of a given endpoint. |
AUCX | AuditConnection | CallManager | Retrieves all the parameters associated with a connection. |
CRCX | CreateConnection | CallManager | Creates a connection between two endpoints. |
DLCX | DeleteConnection | Both | From CallManager: Terminates a current connection. From Gateway: Indicates that a connection has been terminated. |
MDCX | ModifyConnection | CallManager | This is a request from the CCM to change certain parameters of the connection. |
RQNT | NotificationRequest | CallManager | The Call Manager uses this command to tell the Gateway to listen for events such as onhook/offhook or DTMF tones. This can also be used to tell a Gateway to provide signals to the endpoint. Dial tones and busy signals are an example of this. |
NTFY | Notify | Gateway | Sent by the Gateway to the CallManager to request an event. |
RSIP | RestartInProgress | Gateway | Informs the CallManager that an endpoint has been removed from service or is being restored to service |
Another concept relevant to MGCP implementation is PRI backhaul. PRI backhaul occurs when Cisco CallManager takes control of the Q.931 signaling data used on an ISDN PRI. With PRI backhaul, raw ISDN Q.931 data is passed untouched through the Gateway to the Call Manager. It does this using TCP port 2428. This signaling data is passed over the D channel and must be able to reach the CallManager before the Gateway will bring up the D channel. The Q.921 layer 2 data is terminated at the Gateway. Below is a sample MGCP configuration for a 2600-series router. These are some of the more common commands to start MGCP on a Gateway. This assumes a digital-access PRI. Otherwise, the only difference will be in reference to the voice port and the t1 controller definitions.
Router(Config)# mgcp ! (This turns on MGCP) Router(Config)# mgcp call-agent 10.110.110.10 2427 service-type mgcp version 0.1 ! (The IP address is the CallManager, 2427 is the TCP port number, service type defines either MGCP or SGCP and the version number.) Router(Config)# mgcp dtmf-relay codec all mode out-of-band ! (Selects the codec type and the dtmf option) Router(config)# controller t1 1/0 Router(config-controller)# pri-group timeslots 1-24 service mgcp ! (Tells the Gateway to use ports 1-24 of the PRI for service MGCP. The D channel will be port 23 and the actual channels will be 0-22. Router(config)# dial-peer voice 1 pots ! (This creates a POTS dial-peer that can be pointed to the D channel of the PRI as seen in the command following the next. One is a random number that I selected for this example. Router(config-dial-peer)# voice-port 1/0:23 ! (tells the dial-peer to use this port for calls controlled by MGCP. ! Binds the port to MGCP) Router(config)# ccm-manager MGCP ! (This commands allows the Gateway to talk to the CallManager using MGCP.) Router(Config)# ccm-manager redundant-host 10.110.110.11 ! (Configures a redundant CallManager for MGCP) Router(Config)# ccm-manager switchback graceful ! (Once the primary CCM comes back on line, this command will wait ! until any active calls are completed before the phones are registered ! back to the primary CCM. Other options will switch over immediately. ! You can also set a specific time for the phones to switch back.)
Session Initiation Protocol (SIP) is the Internet Engineering Task Force (IETF) standard for multimedia conferencing over IP. SIP is an ASCII-based, application-layer control protocol (defined in RFC 2543) that can be used to establish, maintain, and terminate calls between two or more endpoints. Components of SIP include the following:
UAC (User Agent Client) - Initiates SIP requests.
Phones - Act as either UAS or UAC. IP softphones (Software on a PC creating a virtual phone) and Cisco SIP IP phones can initiate SIP requests and respond to requests.
Gateways - Provide call control, including services such as translating SIP conferencing endpoints into other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the Gateway translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side.
UAS (User Agent Server) - Contacts the UAC when a SIP request is received and that returns a response on behalf of the user.
Proxy server - An intermediate device that receives SIP requests from a client and then forwards the requests on the client's behalf. Proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security.
Redirect server - Provides the client with information about the next hop or hops that a message should take and then the client contacts the next hop server or UAS directly.
Registrar server - Processes requests from UACs for registration of their current location. Registrar servers are often co-located with a redirect or proxy server.
Note: SIP endpoints are capable of functioning as both a UAC and a UAS, however, they usually provide only one of the functions per transaction.
[VP-GWGK1-WP1-F02]
[2006-03-07-00]
|