Gateways are Cisco routers that have Voice Ports to connect to PSTN network and PVDM cards to transcode.
Pri E1 -> VWIC-1MFT-E1
Bri ports -> VIC2-2FXO
Analog devices (fax, mobile track) -> VIC-4FXS
Data ISDN -> WIC-2BRI
VWIC – Voice and WAN Interface Card (Voice + Data)
VIC – Voice Interface Card (Only Voice)
WIC – WAN Interface Card (Only Data)
VIC2 – The 2 means that it’s the second generation of that card.
VIC2-2FXO – The number after the first – defines the number of ports that the card have
PVDM2-64 – 64 defines the capacity of DSPs
Each voice channel in the gateway will require one available DSP. If there are no available DSPs, the voice channel won’t work.
Dial-Peers on the gateways don’t remove digits of the destination patterns as default.
When calling a number that fits in several dial peer destination patterns, it will use the most specific one.
1) Configure the gateway in Device > Gateway section. Define the protocol MGCP, domain name (including domain) and the card slots. Each card slot will need the Device Pool that will define the codecs that will use and several parameters that will be provided by the ISP.
2) Configure the gateway to get the configuration automatically from the CUCM server.
ccm-manager config server [CUCM-TFTP IP] ccm-manager config
Configuration automatically generated from the CUCM:
controller e1 0/1/0 pro-group timeslots 1-31 service mgcp voice-port 0/1/0:15 ccm-manager redundant-host [SUBSCRIBER IP] ccm-manager mgcp mgcp mgcp call-agent [PUBLISHER IP] 2427 service-type mgcp version 0.1 interface serial 0/1/0:15 isdn switch-type primary-net5 //depending on the configured parameters provided by the ISP isdn bind-l3 ccm-manager dial-peer voice 999020 pots service mgcpapp port 0/2/0
3) When reseting the CUCM gateway, the configuration will be downloaded again and all the changes done on it will be overriden. For this reason, it’s recommended to remove the two initial commands after the configuration is downloaded.
no ccm-manager config server [CUCM-TFTP IP] no ccm-manager config
4) We should also modify the PRI channels in use under the controller E1 to define the actual quantity of channels that the ISP is providing, but there are other commands that needs to be removed disabled before doing this change.
voice-port 0/1/0:15 shutdown interface serial 0/1/0:15 no isdn bind-l3 ccm-manager controller e1 0/1/0 pro-group timeslots 1-4 service mgcp voice-port 0/1/0:15 no shutdown interface serial 0/1/0:15 isdn bind-l3 ccm-manager
show ccm manager show mgcp show mgcp endpoints debug mgcp all
1) Voice ports should be configured using the ISP provided parameters, time-slots, clock,…
2) Dial-Peers should be configured in the GW to define where the calls should be redirected to voice ports
Forward land line calls through the PRI first or FX0 second
voice translation-rule 922551 rule 1 /^1/ /922552/ voice translation-profile toPri translate calling 922551
dial-peer voice 8900 pots destination-pattern 0........ port 0/1/0:15 translation-profile outgoing topri dial-peer voice 8901 pots destination-pattern 0…….. port 0/2/0 preference 5
Forward mobile calls through the FX0 first and second through the PRI
dial-peer voice 6700 pots destination-pattern 0…….. port 0/1/0:15 preference 5 dial-peer voice 6701 pots destination-pattern 0…….. port 0/2/0
Forward emergency calls through the PRI
dial-peer voice 112 pots destination-patter 112 port 0/1/0:15 forward-digits all dial-peer voice 113 pots destination-pattern 0112 port 0/1/0:15 forward-digits 3
3) Configuration of the dial-peer to forward calls to the CUCM for devices connected to it
dial-peer voice 2000 voip destination-pattern DN.. session target ipv4:[PUBLSIHER IP] dial-peer voice 2001 voip destination-pattern DN.. session target ipv4:[SUBSCRIBER IP] preference 5
4) Configuration to make the Gateway connect to CUCM using the loopback interface
interface loopback.0 h323-gateway voip interface h323-gateway voip bind srcaddr [LOOPBACK IP]
Gateway dial-peers will use H.323 and G.729 as default.
5) Configure the H323 gateway in Device > Gateway section. The name of the device should be the loopback IP of the gateway.
6) Configure a route pattern in Call routing > Route Hunt > Route Patterns so the CUCM knows which calls should be forwarded to the H323 gateway.
debug h225 q931
1) Create a Device > Trunk setting up SIP as device protocol, the name, device pool, the GW loopback IP, SIP Profile (Standard) and SIP trunk security profile (Non Secure)
2) Create a route pattern in Call routing > Route Hount > Route Patterns to define the calls that will be forwarded to the SIP gateway.
3) Create one dial peer for each CUCM box defining the destination pattern and the protocol. Subscriber will have a preference to be penalized.
dial-peer voice 2000 voip destination-pattern 20.. session target ipv4:10.2.1.1 session protocol sip dial-peer voice 2001 voip destination-pattern 20.. session target ipv4:10.2.1.2 preference 5 session protocol sipv2
4) Configure the loopback interface as a source interface for the SIP protocol.
voice service voip sip bind all source-interface loopback0
debug cssip messages
Router general commands
Voice ports and hardware information
show inventory show diag
show dial-peer voice summary show dialplan number XXXXX show voice port summary show controller e1 show isdn status debug vpm signal (for fxo) debug isdn q931 (for PRI) csim start EXTENSION // command to start a call from the gateway
SRST (Survivable Remote Site Telephony) configuration allows the phones to register to the local gateway in case of lose of connectivity to the CUCM. Gateway perform a simple Call Manager Express functions.
1) Configure SRST options
call-manager-fallback max-ephones 5 max-dn 10 ip source-address [SRST GW IP for the phones] system message primary [Message to shown in the phone screen]
“max-ephones ?” and “max-dn ?” will provide information about the maximum number of phones and DNs that can be configured with the current license.
When in Survivable mode, phones will kept the current extensions.
2) Definition of the SRST system in the CUCM in System > SRST. Setup a name, the GW IP and the port 2000.
3) Configuration of the SRST availability on the Device Pool that the remote sites are using. It’s possible to specify the SRST created in the previous point or it can be setup so the phones will always use their gateway as a SRST. In that case, point 2) is not needed.
Usually the number of allowed SRST phones is limited and it’s not possible to cover all the setup phones. It’s required to create two different Device Pools for the remote site to determine which phones will be capable to connect to the SRST and which phones won’t.