|
The VoIP Gateway |
Voice is a topic on many Cisco certification exams, including the CCIE R&S; written exam. This article discusses the gateway that is required if you are connecting your AVVID system to the traditional telephone system. It is excerpted from a tutorial by Jason Wydra titled, "Cisco Voice Systems." |
If you plan to connect your AVVID system to the traditional TDM based PSTN (public switched telephone network), you're going to have to connect through some sort of gateway. Currently the most popular gateways are the Cisco 1750, 2600/3600, VG-200 voice network modules, and Cisco AS5300 voice feature cards. You may also see gateway modules plugged into a Catalyst switch. Examples are the Catalyst 6500 8-port Voice T1/E1 and the Catalyst 6000 24-Port FXS module. If needed, the gateways contain the necessary DSPs (digital signal processors) needed to convert digital signals to analog or vice versa. This is the case if you're using FXO (foreign exchange office), FXS (foreign exchange station), or E&M ports. These ports, as well as the DSP function, will be discussed later in this article.
A Cisco VoIP gateway can run in a couple of different modes. You can configure it as either an H323 gateway or an MGCP gateway and it will register with the Call Manager. There are benefits of each method. MGCP is a Cisco proprietary protocol and one of its biggest advantages lies in its ability to keep an end-to-end call connected even if the primary Call Manager fails. The call will stay active until the end of the call. At this time, the phone will fall back to the back-up Call Manager (if there is one). If there's not a back-up Call Manager, you can configure the gateway for SRST (Survivable Remote Site Telephony). SRST comes into play when the gateway has lost all communications with the primary and secondary Call Managers. At this point, the gateway itself takes over limited call processing functionality.
H.323 was developed by the International Telecommunications Union (ITU). It's an extension of ITU-T standard H.320 that 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 the packet-based network and other terminals on a switched circuit network, or to another H.323 Gateway. Two additional items work along with H.323. They are H.225 and H.245. 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.
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 for call admission control. An example of a Call Manager H.323 call flow is listed below with details for each step. The StationD and StationInit messages are actual SCCP message sent between the Call Manager and the IP phone. Station D messages are from the Call Manager to the IP phone. StationInit messages are from the IP phone to the Call Manager. In this example, IP phone 3000 in Call Manager cluster 1 is calling IP phone 4000 in cluster 2. Intercluster trunks are used to link the clusters. This is one area where the H.323 communication takes place. In this example, you see a trace file from the originating Call Manager in cluster 1. Cluster 2 will also have a corresponding trace file for its portion of the call.
16:06:12.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
StationInit messages are sent from the IP phone to the Call Manager. This message indicates that the IP phone has gone off-hook. A TCP handle is assigned to the call that can be used as a reference throughout the life of the call.
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
Initiates the H225 connection request to cluster 2
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
The IE (information element) contains detailed information about the call. This is passed from cluster 2 to this cluster
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=3000, CalledPartyName=4000, CalledParty=4000, tcpHandle=0x1c64310
Passed to local IP phone from Call Manager to indicate calling and called party info.
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
Opens a logical channel for transport of audiovisual and data information
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
Call Manager tells the local IP phone to open a receive channel to its IP address.
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
Packet size and compression type is communicated to the local IP phone.
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2
Local IP phone acknowledges receipt of open receive channel request. It also tells the phone in cluster 2 its IP address and RTP port.
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
One way RTP path is established from cluster 2 to cluster 1.
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626
Cluster 1 sends open logical channel confirmation to cluster 2's IP address and RTP port number.
16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
Call Manager tells the local IP phone to begin RTP stream to the IP phone in cluster 2. This is a direct stream. It does not flow through the Call Manager.
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
Call Manager tells the local IP phone about the IP address, RTP port and packet size of cluster 2's phone.
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
Call Manager tells the local IP phone to close the receive channel.
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
Call Manager tells the local IP phone to stop media transmission to cluster 2's IP phone.
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol=H225Protocol
Call Manager 1 receives an H225 message from cluster 2 indicating that the resource release was complete.
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90 16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
H225 and Q931 Information Elements that identify why the call was disconnected. Call Manager has tools that can decode these messages.
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310
The local IP phone hangs up.
MGCP (Media Gateway Control Protocol) takes all of the brains out of the gateway and moves them to the Call Manager. The Call Manager is considered the call agent in MGCP. Instead of having the route plan configured on the H.323 gateway with dial-peers, you configure route patterns on the Call Manager. The Call Manager has all of 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. Basically, you configure dial peers on the MGCP gateway that will be used in the event your Call Managers fail. This way, the local site can still place and receive calls via the PSTN.
MGCP is defined under 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 to gateways, from call agents, using UDP port 2427. Port 2727 is used to send messages from the gateways to the call agent. MGCP refers to endpoints as any voice-port on a gateway, whether it is digital or analog. Call agents in MGCP are referring to the devices that actually control the gateway, i.e., the Call Manager. MGCP uses a set of commands and responses between the call-agent and the gateway. These are sent in plain text and are listed below along with a diagram of the process:
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 would be an example of this. |
NTFY | Notify | Gateway | Sent by the gateway to the Call Manager to request an event. |
RSIP | RestartInProgress | Gateway | Informs the Cisco CallManager that an endpoint has been removed from service or is being restored to service |
Figure 5.
Another concept relevant to the MGCP implementation is PRI backhaul. PRI Backhaul occurs when Cisco Call Manager takes control of the Q.931 signaling data used on an ISDN PRI. With PRI backhaul, raw ISDN Q931 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 Call Manager before the gateway will bring up the D channel. The Q921 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 is in use.
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 Call Manager, 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 points 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)# application MGCPAPP
Turns on MGCP for the dial-peer.
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 command allows the gateway to talk to the Call Manager using MGCP.
Router(Config)# ccm-manager redundant-host 10.110.110.11
Configures redundant Call Manager 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 are immediate. You can also set a specific time for the phones to switch back.
Voice ports come in either digital flavor or analog flavor. The analog ports are FXS, FXO, and E&M. The digital ports are PRI, BRI, T1-CAS, and MFT (multi-flex trunk).
The FXS module (Foreign Exchange Station) connects ordinary analog telephones to a voice gateway. You may also connect fax machines and overhead paging stations to these ports. Dial tone and ring voltage is provided to the analog sets when the end device goes off hook or is receiving a call. The interface on an FXS module is a standard RJ-11 cable. FXS port supplies the dial tone.
The FXO module (Foreign Exchange Office) connects to the PSTN or a PBX. The FXO connects to the C.O. switch. The C.O. switch actually thinks that the FXO port is a telephone. It also uses a standard RJ-11 cable. The FXO port does not provide dial tone and therefore you should not plug a telephone into the FXO port. So, where the FXS port supplies the dial tone, the FXO port expects the dial tone to be supplied. Two common configurations for FXO and FXS ports are ground-start and loop-start. Standard home telephone lines use loop start, but business telephones can order ground start lines. Loop-start signaling sends an off-hook signal that opens the loop and starts a call. An on-hook signal is sent to close the loop and end the call. Ground-start signaling provides current detection mechanisms at both ends of the trunk to detect off-hook signals. This mechanism permits endpoints to agree on which end is seizing the trunk, before it is seized, and minimizes the chance of glare. Glare happens when both ends of the call seize the trunk at the same time. You have experienced this when you picked up the phone and found there was already somebody on the line (even though you didn't hear it ring). Ground start provides recognition of connects and disconnects. It's the preferred signaling method for PBX connections. Some PBXs do not support ground-start signaling, so you must use loop-start signaling for the trunk interface. The default is loop start. In some modules, you will actually have to change the jumper settings to switch between signaling methods. The jumpers are labeled W3 and W4. Place the jumpers over positions 1 and 2 for ground start. Place the jumpers over positions 2 and 3 for loop start. Most installations use loop start. Listed below are some of the common FXO modules.
Module ID | Description |
VIC-2FXO | Two-port FXO Voice Interface Card |
VIC-2FXO-EU | Two-port FXO for Europe |
VIC-2FXO-M1 | Two-port FXO for U.S. with battery reversal |
VIC-2FXO-M2 | Two-port FXO for Europe with battery reversal |
VIC-2FXO-M3 | Two-port FXO for Australia |
At the end of a VoIP call, both ends hang up the phone or terminate the call. You would expect that all gateway ports involved with the end-to-end call would also disconnect. Sometimes this is not the case with FXO ports when using loop start signaling. There is a common problem known as the FXO disconnect problem.
The FXO port looks like a phone to the central office switch or PBX. The FXO interface closes the loop and the C.O. provides constant battery on the wire. Therefore, there is no disconnect supervision. Just as the switch expects a user to hang up the phone when the call is complete, it also expects the FXO port to hang up. There is no automated process in the router that tells the FXO to disconnect when a call is completed. This is why FXO ports can sometimes become hung up or continue to send ring tones after the call has already cleared. The FXO expects the C.O. switch or PBX to tell it when to hang up. If the local FXO initiated the call and sent it out of its FXO port, then it can supply local disconnect. If it's receiving a call on its FXO then it needs to have a disconnect signal from the PSTN or PBX. Now, there's always a work-around for everything. Here is a list of some of the methods Cisco uses to get around this problem.
Ground-start Signaling Disconnect
Power Denial-based Supervisory Disconnect
Battery Reversal
Tone-based Supervisory Disconnect
The most common form of analog trunking is the E&M interface. E&M Signaling is commonly referred to as "ear & mouth" or "recEive and transMit". It comes from the term earth and magnet. Earth represents electrical ground and magnet represents the electromagnet used to generate tone. E&M is commonly used for connecting to PBXs
E&M signaling uses direct current over two-wire or four-wire circuits to signal to the endpoint or CO switch when a call is in recEive or transMit (E&M) state. The E&M signaling type must be the same for both ends of the trunk interface. There are 5 interface types for E&M. Type 1 signaling is the most commonly used mode in the U.S. Type 1 uses two leads for supervisor signaling: E, and M. During inactivity, the E-lead is open and the M-lead is connected to ground. The PBX (acting as trunk circuit side) indicates the off-hook condition by connecting the M-lead to battery. The Cisco router/gateway (signaling unit) indicates the off-hook condition by connecting the E-lead to ground.
There are three signaling techniques for E&M. They are:
Wink-start signaling - The originating side sends an off-hook signal and waits to receive a wink pulse signal that indicates the receiving end is ready to receive the dialed digits for the call. Wink start is the preferred signaling method because it provides answer supervision. Not all COs and PBXs support wink-start signaling.
Delay-dial signaling - The originating side sends an off-hook signal, waits for a configurable time. Then it checks to see if the receiving end is on hook. The originating side sends dialed digits when the receiving side is on hook. The delay allows the receiving end to signal when it is ready to receive the call.
Immediate-start signaling - The originating side goes off hook, waits for a finite time, and then sends the dial digits without a ready signal from the receiving end.
The BRI (Basic Rate Interface) has 2 bearer channels and one signaling channel. The signaling channel is the D channel and the bearer channels are the B channels. Each B channel is 64 Kbps and the D channel is 16 Kbps. You can place a maximum of two voice calls on this interface using both B channels. The PRI (Primary Rate Interface) consists of 24 channels for T1 and 31 channels for E1. The T1 has 23 64 Kbps channels and 1 64 Kbps D channel on channel 23. The E1 interface has 30 channels plus 1 D channel on channel 15.
T-1 Channel Associated Signaling (CAS) uses part of each channel's bandwidth for signaling. This differs from ISDN because ISDN uses a separate D channel to signal all of the B channels. In T1 CAS, bits are robbed from each channel and used for signaling. CAS is commonly referred to as robbed bit signaling.
The Multi-Flex Trunk module dubs as a voice interface card if plugged into a High Density Voice Network Module. It can also act as a WAN Interface Card if it's installed in a WIC slot in the 2600 or 3600 router. It's considered a Voice WAN Interface Card (VWIC). Whether the MFT port acts as a voice port or a data port depends on what type of module it is plugged into. If you plug it into a High Density Voice Network Module, you can configure for T1 CAS or T1 PRI. If you plug it into a WIC slot of a 2600 or 3600 router, it acts as an ordinary WAN interface.
|