2009年7月13日 星期一

FXO Disconnect Failure (fxo port 咬線問題)

 

When loop-start signaling is used, a router's FXO interface looks like a phone to the switch (private branch exchange (PBX), public switched telephone network (PSTN), Key-System) it connects to. The FXO interface closes the loop to indicate off-hook. The switch always provides a battery so there is no disconnect supervision from the switch side. Since a switch expects a phone user (example of an FXO interface) to hang up the phone when the call is terminated (on either side), it also expects the FXO port on the router to hang-up. This "human intervention" is not built into the router. The FXO port expects the switch to tell it when to hang-up (or remove the battery to indicate on-hook). Because of this, there is no guarantee that a near-end or far-end FXO port disconnects the call once either end of the call hangs-up.

The most common symptoms of this problem are phones that continue to ring when the caller has cleared, or FXO ports that remain busy after the previous call should have been cleared.

Common Scenarios

As a simple rule-of-thumb, if the local router has an FXO port and it originates the call out of an FXO port, it has control over that call and can provide the local disconnect. If the local router has an FXO port and it receives the call, it requires that the connected switch provide this disconnect signal.

fxo_disconnect3.gif

Note: All scenarios assume that no Supervisory Disconnect features are configured on the PBXes.

Scenario 1

Phone-A calls phone-B. Phone-B does not answer. Phone-A then goes on-hook, but phone-B continues to ring because the router's FXO has no signaling information of the change (going on-hook) made by phone-A. If the call is answered, it stays active until phone-B hangs-up, regardless of the actions of phone-A.

Scenario 2

Phone-B calls phone-A. When the users hang-up, or if phone-B hangs-up before phone-A answers, the call is disconnected because the router's FXO port originated the call. However, if phone-A hangs-up before phone-B, the call remains up until phone-B hangs-up.

Scenario 3

This is the worst possible scenario because calls placed in either direction results in the router receiving a call on its' FXO port. In the case of a call that comes in from the PSTN, it might not be as bad. This is because the PSTN switch often provides a disconnect (ground-start or power-denial) and the far-end router ends the call from its' FXO port. However, calls to the PSTN will have the same problems that are discussed throughout this document, because the call comes into the router's FXO port.

Understand Supervisory Disconnect Signaling Methods

Ground-start Signaling Disconnect

Ground-start signaling can be used on the FXO port of the router if the switch is capable of providing a ground-start connection. When configured, the switch removes the ground from the connection and the FXO port goes on-hook. This option is available on the Cisco 1750, 2600, 3600, 3700 and MC3810 series multiservice routers.

Power Denial-based Supervisory Disconnect

Power denial detection is an interruption of line power from the switch or PBX to the FXO port, which lasts at least 350 ms. The FXO interface on the router detects that power is no longer present and interprets this as a supervisory disconnect indication. This is available on the Cisco 1750, 2600, 3600, 3700 and MC3810 series router analog FXO ports in all versions of Cisco IOS which have voice support. This figure provides an illustration:

fxo_disconnect1.gif

Battery Reversal

Battery reversal is implemented by reversing the battery polarity on the PBX. This is done initially when the call is connected (far-end answer), with the polarity reversed throughout the entire conversation. When the far-end disconnects, the battery polarity is changed back to normal to indicate call disconnect. PBX uses the battery reversal indication to start billing.

Note: Foreign Exchange Station (FXS) ports normally reverse the battery upon call connection. Therefore, if an FXS port is connected to an FXO port that does not support battery reversal detection, you should disable battery reversal on the FXS port to prevent unexpected behavior.

Tone-based Supervisory Disconnect

Supervisory Tone is the audible frequencies that a PBX can produce to indicate that a call has been released (caller back on-hook) and the connection should be disconnected. The tones are different in most countries. The router's FXO port can be configured to interpret the tones as Supervisory Disconnect and disconnect the call.

In this Supervisory Tone Disconnect example figure, the call is made to the far-end.

fxo_disconnect2.gif

Configure Supervisory Disconnect Signaling

Configure the FXO Port to Support Power Denial in Cisco IOS Software Release 11.3MA and Later

The supervisory disconnect signal command turns on support for power denial recognition. This is the default configuration. Configuring the no supervisory disconnect signal command turns off support for power denial in this release, and also enables support for basic supervisory tone disconnection. Refer to Configure the FXO Port to Support Supervisory Tone Disconnection.

FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#supervisory disconnect signal
FXO_Paper(config-voice)#end
FXO_Paper#



Configure the FXO Port to Support Battery Reversal Detection in Cisco IOS Software Release 12.0(7)XK and Earlier


To configure support for battery reversal, the battery-reversal command is applied to the voice port. This feature was supported on the Cisco MC3810 series router from launch. The Cisco 2600/3600 platforms were first supported in Cisco IOS Software Release 12.0(7)XK (integrated in Cisco IOS Software Release 12.1(3)T) and needs the addition of special FXO hardware VIC-2FXO-M1 and VIC-2FXO-M2.




FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#battery-reversal
FXO_Paper(config-voice)#end
FXO_Paper#



For more information on the VIC-2FXO-M1 and VIC-2FXO-M2, refer to Understanding FXO Voice Interface Cards.



For more information on configuring battery-reversal, refer to Voice Port Enhancements in Cisco 2600 and 3600 Series Routers and MC3810 Series Concentrators.



Configure the FXO Port to Support Supervisory Tone Disconnection in Cisco IOS Software Release 11.3MA


Supervisory tone disconnection was first supported in Cisco IOS Software Release 11.3MA. Activation was with the configuration of the no supervisory disconnect signal command. In this release the detection was minimal, with the FXO only being able to detect a 600 hertz tone as the disconnect signal.




FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#no supervisory disconnect signal
FXO_Paper(config-voice)#end
FXO_Paper#



Configure the FXO Port to Support Supervisory Tone Disconnection in Cisco IOS Software Release 12.1(3)T


The supervisory tone detection was changed in Cisco IOS Software Release 12.1(3)T to give more detailed support. The command line interface (CLI) was also changed. From this release, it is now possible to configure the disconnect tones to be detected either continuously during calls (by configuring the mid-call command), or only during call setup (by using the pre-connect command in the configuration). Detection of anytone (configured by the anytone command) operates only during call set-up. If you configure detection of anytone, you must also enable echo cancellation to prevent disconnection due to the detection of the router's own ringback tone.



Another new feature is the ability to create voice classes. This allows the various components that are used to construct a tone to be configured to match the tone created by PBXs from various countries. Because there are numerous commands that can make a voice class, it is beyond the scope of this document to explain their functionality. Consult the release documentation for detailed information.




FXO_Paper #configure terminal  
FXO_Paper(config)#voice-port 3/1/1
FXO_Paper(config-voiceport)#supervisory disconnect dualtone pre-connect voice-class 90
FXO_Paper(config-voiceport)#end

FXO_Paper(config)# voice class dualtone 90
FXO_Paper(config-voice-class)# freq-pair 1 350 440
FXO_Paper(config-voice-class)# freq-pair 2 480 850
FXO_Paper(config-voice-class)# freq-pair 3 1000 1250
FXO_Paper(config-voice-class)# freq-max-deviation 10
FXO_Paper(config-voice-class)# freq-max-power 6
FXO_Paper(config-voice-class)# freq-min-power 25
FXO_Paper(config-voice-class)# freq-power-twist 15
FXO_Paper(config-voice-class)# freq-max-delay 16
FXO_Paper(config-voice-class)# cadence-min-on-time 50
FXO_Paper(config-voice-class)# cadence-max-off-time 500
FXO_Paper(config-voice-class)# cadence-list 1 100 100 300 300 100 200 200 200
FXO_Paper(config-voice-class)# cadence-list 2 100 200 100 400 100 200 300 300
FXO_Paper(config-voice-class)# cadence-variation 8
FXO_Paper(config-voice-class)# exit



Note: All the commands other than the freq-pair command under the voice class dualtone command mode are hidden.



Note: The supervisory disconnect dualtone command is modified and improved from Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T.



Configure the FXO Port to Support Supervisory Tone Disconnection from Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T


Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T introduced many improvements and changes. These include a change to the command line, the addition of "Tone Detection Tolerance" Classes, changes to the custom voice class configuration, enabling the creation of Customized Cptones, and the ability to use the predefined country specific call progress tones. The predefined country specific call progress tones provide a means of not having to configure a custom voice class. This significantly reduces the overall configuration needed to deploy the feature. This is configured by applying the cptone locale command to the voice port. It is recommended that this method be initially tried first before attempting to use any custom configurations.



This is a sample configuration. Note the inclusion of the commands timeouts wait-release 5 and timeouts call-disconnect 5. The defaults of these timers are thirty seconds and sixty seconds, which can prove to be excessive in normal use. Therefore, the timers should be reduced to suit the local condition. As a guide, five seconds can be considered as a more satisfactory value for both.




FXO_Paper#configure terminal  
FXO_Paper(config)#voice-port 3/1/1
FXO_Paper(config-voiceport)#supervisory disconnect dualtone mid-call
FXO_Paper(config-voiceport)#cptone us
FXO_Paper(config-voiceport)#timeouts wait-release 5
FXO_Paper(config-voiceport)#timeouts call-disconnect 5
FXO_Paper(config-voiceport)#exit



Note: The timeouts call-disconnect command is hidden in Cisco IOS Software Release 12.1(5)XM.



FXO disconnect supervision is not supported on local hair pinned calls between analog voice ports (FXS and FXO) on Cisco MC3810 series concentrators because the digital signal processor (DSP) is bypassed. If hair pinning is turned off with the no voice local-bypass global configuration command, FXO disconnect supervision is supported.



The Cisco MC3810 series concentrators must be equipped with high-performance compression modules (HCMs) to support tone detection. Standard voice compression modules (VCMs) do not support the FXO Disconnect Supervision feature.



Note: To configure non-default tone detection tolerances, use the voice class dualtone-detect-params command. For more information, refer to FXO Disconnect Supervision.



Note: For more information on any of the commands in this document, refer to the Command Lookup Tool ( registered customers only) .



 



Reference:



http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800ae2d1.shtml



http://www.cisco.com/en/US/docs/ios/12_1/12_1xm/feature/guide/dt_dscon.html#wp61588



http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_FXO_Interfaces

2009年7月10日 星期五

Understanding How Digital T1 CAS (Robbed Bit Signaling) Works in IOS Gateways

Introduction

Channel Associated Signaling (CAS) is also referred to as Robbed Bit Signaling. In this type of signaling, the least significant bit of information in a T1 signal is "robbed" from the channels that carry voice and is used to transmit framing and clocking information. This is sometimes called "in-band" signaling. CAS is a method of signaling each traffic channel rather than having a dedicated signaling channel (like ISDN). In other words, the signaling for a particular traffic circuit is permanently associated with that circuit. The most common forms of CAS signaling are loopstart, groundstart, Equal Access North American (EANA), and E&M. In addition to receiving and placing calls, CAS signaling also processes the receipt of Dialed Number Identification Service (DNIS) and automatic number identification (ANI) information, which is used to support authentication and other functions.

Each T1 channel carries a sequence of frames. These frames consist of 192 bits and an additional bit designated as the framing bit, for a total of 193 bits per frame. Super Frame (SF) groups twelve of these 193 bit frames together and designates the framing bits of the even numbered frames as signaling bits. CAS looks specifically at every sixth frame for the timeslot's or channel's associated signaling information. These bits are commonly referred to as A- and B-bits. Extended super frame (ESF), due to grouping the frames in sets of twenty-four, has four signaling bits per channel or timeslot. These occur in frames 6, 12, 18, and 24 and are called the A-, B-, C-, and D-bits respectively.

The biggest disadvantage of CAS signaling is its use of user bandwidth in order to perform signaling functions.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • For AS5xxx, Cisco 2600/3600 platforms, all Cisco IOS® Software releases apply.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

CAS Signaling Types

Loopstart Signaling

Loopstart signaling is one of the simplest forms of CAS signaling. When a handset is picked up (the telephone goes off-hook), this action closes the circuit that draws current from the telephone company CO and indicates a change in status, which signals the CO to provide dial tone. An incoming call is signaled from the CO to the handset by sending a signal in a standard on/off pattern, which causes the telephone to ring.

A disadvantage of loopstart signaling is the inability to be notified upon a far-end disconnect or answer. For instance, a call is placed from a Cisco router configured for Foreign Exchange Station (FXS)-loopstart. When the remote end answers the call, there is no supervisory information sent to the Cisco router to relay this information. This is also true when the remote end disconnects the call.

Note: It is possible for answer supervision to be provided with loopstart connections if the network equipment can handle line-side answer supervision. Also, loopstart provides no incoming call channel seizure. Therefore a condition known as glare can arise, where both parties (Foreign Exchange Office [FXO] and FXS ) try to simultaneously place calls. Glare can be avoided when you configure the T1-CAS gateway's port selection order in such a way that the inbound and outbound calls are in reverse order. For example, if the inbound calls are sent by the provider on the FXO ports in the order of port 1, port 2, port 3 and port 4, then configure the Cisco CallManager Route Group to route outbound calls on those same ports in the order port 4, port 3, port 2 and port 1.

With loopstart signaling, the FXS side only uses the A-bit and the FXO side only uses the B-bit to communicate call information. The AB-bits are bi-directional. This state table defines this signaling information from the CPE's perspective (FXS).

Note: In this table, 0/1 indicates a signaling bit alternating between 1 and 0 in successive superframes.

image

This is the FXS-loopstart timing diagram.

t1-cas-ios-1.gif

On an incoming call (network -> CPE) this happens:

  1. The network toggles the B-bit to indicate ringing. This is a standard ringing pattern. For instance, 2 seconds on, 4 seconds off.

  2. CPE detects the ringing and off-hook states. A-bit goes from 0 to 1.

In an outgoing call (CPE -> network) this happens:

  1. CPE goes off-hook and A-bit goes from 0 to 1.

  2. The network provides dial tone. There is no signaling change.

  3. CPE sends digits (dual tone multifrequency (DTMF) in Cisco's case).

During a disconnect from the network, this occurs:

  1. CPE detects in-band that the call has dropped (someone says good-bye or a modem drops the carrier).

  2. CPE goes on-hook and A-bit goes from 1 to 0.

During a disconnect from the CPE, only step 2 occurs.

The Answer Supervision and Disconnect Supervision States are only seen when provided by the network.

Groundstart Signaling

Groundstart signaling is very similar to loopstart signaling in many regards. It works by using ground and current detectors that allow the network to indicate off-hook or seizure of an incoming call independent of the ringing signal and allow for positive recognition of connects and disconnects. For this reason, ground start signaling is typically used on trunk lines between PBXs and in businesses where call volume on loop start lines can result in glare.

The advantage of groundstart signaling over loopstart signaling is that it provides far-end disconnect supervision. Another advantage of groundstart signaling is the ability for incoming calls (network -> CPE) to seize the outgoing channel, thereby preventing a glare situation from occurring. This is done by using the A- and B- bit on the network side instead of just the B-bit. The A-bit is also used on the CPE side. However, the B-bit can also be involved, based on the switch's implementation. Typically the B-bit is ignored by the Telco. This is a state table that defines this signaling information from the CPE's perspective (FXS).

Note: In this table, 0/1 indicates a signaling bit alternating between 1 and 0 in successive superframes.

image

This is the FXS-groundstart timing diagram.

t1-cas-ios-3.gif

On an incoming call (network-> CPE) this happens:

  1. The network goes off-hook and the A-bit goes from 1 to 0 and rings the line by toggling the B-bit between 0 and 1.

  2. CPE detects the ringing and seizure and goes off-hook and the A-bit is set to 1.

  3. The network goes off-hook and the B-bit stops toggling. B-bit is now 1.

In an outgoing call (CPE -> network) this happens:

  1. CPE goes ground on ring and A-bit and B-bit are 0.

  2. The network goes off-hook and the A-bit goes from 1 to 0. The B-bit is set to 1.

  3. The CPE goes off-hook. The A-bit and the B-bit are 1.

  4. CPE detects a dialtone and sends digits.

During a disconnect from the network, this occurs:

  1. The network goes on-hook and the A-bit goes from 0 to 1.

  2. CPE goes on-hook and the A-bit goes from 1 to 0.

During a disconnect from the CPE, the above steps are reversed.

EandM Signaling

E&M Signaling is typically used for trunk lines. The signaling paths are known as the E-lead and the M-lead. Descriptions such as Ear and Mouth were adopted to help field personnel determine the direction of a signal in a wire. E&M connections from routers to telephone switches or to PBXs are preferable to FXS/FXO connections because E&M provides better answer and disconnect supervision.

E&M signaling has many advantages over the previous CAS signaling methods discussed in this document. It provides both disconnect and answer supervision as well as glare avoidance. E&M signaling is simple to understand and is the preferred choice when you use CAS.

This table represents Standard (E&M) Trunk type A- and B-bits.

image

This is the E&M Signaling diagram.

t1-cas-ios-2.gif

The three types of E&M Signaling that are supported on Cisco routers are:

  • Wink-start (FGB) - Used to notify the remote side that it can send the DNIS information.

  • Wink-start with wink-acknowledge or double-wink (FGD) - A second wink that is sent to acknowledge the receipt of the DNIS information.

  • Immediate start - Does not send any winks at all.

Note: FGD is the only variant of T1 CAS that supports ANI and Cisco supports it along with the FGD-EANA variant. In addition to FGD functionality, FGD-EANA provides certain call services, such as emergency (USA-911) calls. With FGD, the gateway supports the collection of ANI inbound only. With the use of FGD-EANA, a Cisco 5300 is able to send ANI information outbound as well as collecting it inbound. This latter capability requires the user of the fgd-eana signaling type in the ds0-group command, with ani-dnis option and calling-number outbound command in the POTS dial-peer. The calling-number outbound command is supported only on the Cisco 5300 as of Cisco IOS Software Release 12.1(3)T.

Therefore, on an incoming call (network-> CPE) this process happens:

  1. The network goes off-hook. The A-bit and B-bit equal 1.

  2. CPE sends wink. The A-bit and B-bit equal 1 for 200 ms. This only occurs when you use wink-start or wink-start with wink acknowledgement. Ignore this step for immediate start.

  3. The network sends DNIS information. This is done by sending inband tones which are decoded by the modem.

  4. CPE sends a wink acknowledgement. A-bit and B-bit equal 1 for 200 ms. This only occurs for wink-start with wink acknowledgement. Ignore this step for immediate start or wink-start.

  5. CPE goes off-hook when a call is answered. A-bit and B-bit equal 1.

In an outgoing call (CPE -> network) the same procedure occurs. However, the network just described is the CPE and vice-versa. This is because the signaling is symmetric.

During a disconnect from the network, this process occurs:

  1. The network goes on-hook. A-bit and B-bit equal 0.

  2. CPE goes on-hook. A-bit and B-bit equal 0.

During a disconnect from the CPE, these two steps are reversed.


Note e&m-fgd can receive calling-party number (ANI) and send called-party number (dialed-number identification service or DNIS) but cannot send ANI.


Note fgd-eana can send both ANI and DNIS but cannot receive ANI.

Reference:

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800e2560.shtml

NFAS only support T1 PRI

Restrictions for Configuring NFAS with D-Channel Backup

Restrictions are described in the Restrictions for Configuring ISDN Voice Interfaces, page 4. In addition, the following apply:

NFAS is supported with only a channelized T1 controller and, as a result, is ISDN PRI capable.

The router must connect to either a 4ess, dms250, dms100, or National ISDN switch type. Table 47 shows applicable ISDN switch types and supported NFAS types.

image

Reference:

http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_isdn_voice_configuration_guide/isdn06.html

2009年7月9日 星期四

Analog CAMA E911 Trunk

 

Feature Overview

The North American emergency E911 phone system consists of a voice network that is built largely outside of the normal public switched telephone network (PSTN) on which common voice traffic rides. They are treated specially because they are routed differently within the PSTN than normal traffic. Calls to emergency services are routed based on the calling number, not the called number. The calling number is checked against a database of emergency service providers that cross-references the service providers for the caller's particular location. When this information is known, the call is then routed to the proper public service answering point (PSAP), which, in turn, dispatches those services for the caller's location.

During setup of a call to E911, before the audio channel is connected, the calling number is transmitted to each switching point (known as a Selective Router-SR) via an old telephony protocol known as Centralized Automatic Message Accounting (CAMA). CAMA was originally designed as a protocol for long-distance billing, because it provides for carrying both calling and called number using in-band signaling.This allows the telephone system to send a station identification number to the PSAP via multifrequency (MF) signaling through the telephone company's E911 equipment. CAMA trunks are used in 80 percent of the E911 network today.

The calling number is needed at the PSAP for two reasons:

To use the calling number to reference the Automatic Location Identification (ALI) database to find the caller's exact location and any extra information about the caller that may have been stored in the database.

To have the callback number in case the call is disconnected.

A number of North American states have initiated legislation that requires enterprises to connect directly to the E911 network. It is expected that the Federal Communications Commission (FCC) will announce model legislation that extends this requirement to all North American states. Enterprises in areas where the PSTN accepts 911 calls on ISDN trunks can use existing Cisco ISDN voice-gateway products, because the calling number is an inherent part of the ISDN protocol. Most E911 networks are standalone networks within a political region, where at best the region is no bigger than a state. Because of the lack of a nationwide E911 network, customers with dispersed geographic locations larger than typical political boundaries will be required to provide E911 trunks at each political location.

Figure 1 illustrates the topography in existing E911 networks. Figure 2 illustrates an E911 network using the VIC-2CAMA card with Cisco 2600 series or Cisco 3600 series routers.

Figure 1 Existing E911 Networks

Figure 2 Analog CAMA E911 Networks

Benefits

Direct connection to the E911 network

Meets recently enacted legislation requiring enterprises to connect directly to the E911 network. This requirement is expected to expand to all US states.

Trunk capabilities to emergency services that are not currently supported on any Cisco product

Configuration on H.323 VoIP

Restrictions

VIC-2CAMA card installation is required

Configuration in Media Gateway Control Protocol (MCGP) is not supported

Direct trunking is not supported

Automatic location information (ALI) / Data Management Systems (DMS) Reverse ALI lookup features of E911 are not supported

Alternate routing for busy traffic, and night service for power failure is not supported

 

Reference:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/acam_911.html#wp1042981

2009年7月8日 星期三

Caller ID is not supported on FXO if GW configured as MGCP

 

Introduction

This document is a working example of the use of Media Gateway Control Protocol (MGCP) between a Cisco IOS® Gateway (for example, VG200, 2600, 3600, IAD2400) and a Cisco CallManager Media Convergence Server (MCS). It covers the configuration of one foreign exchange office (FXO) connection to the public switched telephone network (PSTN), as well as foreign exchange station (FXS) connections to analog hand sets. This document also shows VoIP connectivity to Cisco 7960 IP phones. When this configuration is complete, it will be possible to make calls between all of the phones used in this configuration. It will also be possible to route calls over the PSTN from any of the phones used in this configuration.

This document assumes that the reader is already familiar with how to configure Cisco IP phones in CallManager. This document also assumes that there is at least one IP phone already active on the Cisco CallManager server.

Symptoms

You can potentially encounter these symptoms when you configure Cisco CallManager with IOS MGCP gateways with analog FXO and FXS ports:

  • The MGCP gateway does not register with Cisco CallManager. Refer to MGCP Gateway Registration Failure with Cisco CallManager.

  • Caller ID does not work on FXO ports. This is because caller ID is not supported with FXO ports when configured for MGCP. Instead, configure the gateway in H.323 mode.

  • Overhead paging locks up the FXO port when doing hookflash unless users go completely off-hook. Perform a shut, no shut to reset the port. This is related to Cisco bug ID CSCef62275 ( registered customers only) and is fixed in Cisco IOS Software Release 12.3(14)T and later.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This configuration was tested with Cisco CallManager versions 3.x and 4.x and various versions of Cisco IOS Software 12.2 images. The screen shots found in the links within this document and the Cisco IOS configurations listed were captured using the software, hardware and other equipment listed here.

  • Cisco VG200 / 2 X FXS / 2 X FXO / 1 FastEthernet 10/100 port

  • Various versions of Cisco IOS Software Release 12.2

  • Cisco CallManager (specific versions are listed in the individual documents below)

  • Analog handsets

  • Cisco 7960 IP Phones

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

For recommended compatibility software versions between Cisco CallManager and the IOS Gateway, refer to the Cisco CallManager Compatibility Matrix. If your network has special needs, consult with your Cisco Account Manager before you change any Cisco IOS Software.

Note: Cisco recommends Cisco IOS Software Release 12.2(11)T or later based on the ccm-manager command enhancements. The ccm-manager command requires Cisco IOS Software Release 12.1(5)XM or later on all routers (2600, 3600) and the VG200.

Cisco 2600 and 3600 routers support MGCP if they run Cisco IOS Software Release 12.1(3)T or later. The release and version that you require will be based on the features that you need to enable. The router configuration is the same for all types of routers. See the Document Contents section for documentation on specific features and requirements related to Cisco CallManager.

Note: NM-HD-2V on an MGCP gateway is supported only from Cisco CallManager 3.3(3)SR4a and later. The NM-HD-2V is not listed as an MGCP Gateway option in Cisco CallManager versions earlier than 3.3(3)SR4a.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Document Contents

  1. Introduction

  2. Configuring the Cisco IOS MGCP Gateway

  3. Configuring the Cisco CallManager Server

  4. Verifying and Troubleshooting the Cisco IOS MGCP Gateway

  5. Sample of Debug MGCP Packets

  6. Monitor, Reset, and Delete MGCP Gateways for Cisco CallManager

You can use this document as a guide to configure the devices for use in a real network or as a workbook example to use in a lab environment for learning or testing purposes. Sections 4 and 5 are provided for additional information. If the tasks in sections 2 and 3 result in a working configuration, it is not necessary to refer to sections 4, 5 or 6.

Reference:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a008009428e.shtml

What is Greenfield deployment?

 

-Greenfield deployment

Enterprise Voice provides new businesses or even new office sites for existing businesses with the opportunity to implement a full-featured VoIP solution without having to worry about PBX integration or incurring the substantial deployment and maintenance costs of an IP PBX infrastructure. This solution supports both onsite and remote workers.

In this scenario, all calls are routed over the IP network. Calls to the PSTN are routed to the appropriate media gateway. Communicator serves as a softphone. RCC is unavailable in this scenario because Communicator Phone Edition, like Communicator, provides click-to-call capability. Voice mail and auto-attendant services are available through the optional deployment of Exchange Unified Messaging.

Bb803630.note(en-us,office.12).gifNote:

In addition to the network infrastructure that is required to support Communications Server 2007, a greenfield deployment might require a small PBX to support fax machines and analog or ISDN devices. In certain scenarios, this might require a new PRI (Primary Rate Interface) link with a new set of numbers.

The following figure shows a typical topology for a greenfield deployment.

Figure 14. Greenfield deployment option
Bb803630.256547b1-ee49-4aca-b27b-2d42bcd3622d(en-us,office.12).gif

 

Deployment Scenarios

The Cisco Unified Communications system can help you take full advantage of your existing IP network to deliver new communications services. Whether implemented individually or in combination, the products help you reap the highest possible productivity and cost-savings benefits and achieve a fast, measurable ROI in a variety of deployment scenarios, including:

  • Greenfield : A new telephone system is installed to serve a new or relocating facility
  • Centrex Replacement: The recurring costs of an outsourced service are replaced by an internally owned telephone system
  • Multisite Centralized Call Processing: Replacin g separate systems within a company or region with centralized call processing presents significant potential for reducing costs, consolidating redundant infrastructure, and standardizing network services
  • Single-site PBX and ACD Replacement: The need to replace aging or obsolete voice infrastructure often begins the migration to IPC
  • IP Telephony: Cisco products can integrate with existing PBX and key systems to help you migrate gradually to IP telephony while protecting current technology investment

 

Reference:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns165/net_business_benefit0900aecd80472efb.html

http://technet.microsoft.com/en-us/library/bb803630.aspx