Multiple PRI's configuration on Voice gateway

Scenario

Let’s say we have 2 PRI lines in voice gateway and both PRI’s use different DID numbers for inbound & outbound calls. Like First PRI DID number is 44441xx & Second PRI DID number is 55552xx. In this scenario, we needs to achieve that respective DID outbound calls should go through the respective PRI lines using H.323 gateway and eventually the destination phone display the correct calling number (DID) all the time.

Solution

1.      If  both the PRI’s are from the same Telco (PSTN Provider) then you may need to request them to all DID sharing over the 2 PRI’s

2.      If this is not possible or both are different provider then its better to route the calls via specific PRI. Configurations as below

Note: I assume that both PRI’s are configured properly and show isdn status shows layer 2

MULTIPLE_FRAME_ESTABLISHED.  Otherwise follow the PRI step by step configuration blog J

Configuration

Configure the Translation Rules & Profile

voice translation−rule 1

rule 1 /^9/ /19/       < --- assuming the PTSN access code is 9, if you're using discard digits on CCM - change it to none

!

voice translation−rule 2

rule 1 /^9/ /29/

!

voice translation−profile PRI1

translate called 1

!

voice translation−profile PRI2

translate called 2

!

Configure the H.323 Gateway Inbound dial-peers

dial peer voice 100 voip

answer−address 1..           ß---- should match the DN (DID) configured on IP Phone

translation−profile incoming PRI1

!

dial peer voice 200 voip

answer−address 6..   ß---- should match the DN (DID)  configured on IP Phone

translation−profile incoming PRI2

!

Configure the  H.323 Gateway Outbound dial-peers

dial-peer voice 19 pots

 destination-pattern 19T

 port 1/0/0:15

dial-peer voice 29 pots

 destination-pattern 29T

 port 1/0/1 :15

 

Verification

You can confirm your configuration works properly using below commands

·         debug voip ccapi inout —Verifies that the correct dial-peers are matched, both inbound and outbound.

·         test voice translation-rule 1 94444122—Verifies that the translation-rules prefix the number appropriately when called.

    

VOICE_GW#test voice translation-rule 1 94444122

Matched with rule 1

Original number: 94444122       Translated number: 194444122

Original number type: none      Translated number type:none

Original number plan: none      Translated number plan: none

VOICE_GW#test voice translation-rule 2 95555224

Matched with rule 1

Original number: 95555224       Translated number: 295555224

Original number type: none      Translated number type: none

Original number plan: none      Translated number plan: none

MGCP Gateway

MGCP is a master/slave protocol that allows a call control device such as Call Agent(CUCM) to take  control of a specific port on a Media Gateway. In MGCP context Media Gateway Controller is refereed to as Call Agent(CUCM). This has the advantage of centralized gateway administration and provides for largely scalable IP Telephony solutions. The distributed system is composed of a Call Agent, at least one Media Gateway (MG) that performs the conversion of media signals between circuits and packets Switched networks

MGCP is a signalling and call control protocol used within Voice over IP (VoIP) systems that typically inter-operate with the public switched telephone network (PSTN). As such it implements a PSTN-over-IP model with the power of the network residing in a call control center (softswitch, similar to the central office of the PSTN) and the endpoints being "low-intelligence" devices, mostly simply executing control commands.MGCP uses the Session Description Protocol (SDP) for specifying and negotiating the media streams to be transmitted in a call session and the Real-time Transport Protocol (RTP) for framing of the media streams

•           Centralized Dial Plan and Administration

•          Call processing is done by call agent such as Cisco Unified Communication Manager

•          MGCP gateway handle the translation between audio signals and the packet network

•           Call Agent(CUCM) in charge of the gateway

•           master/slave relationship

•          MGCP uses UDP for establish audio connections over the IP networks

•           Enhanced call Survivability

An MGCP packet is either a command or a response. Every issued MGCP command has a transaction ID and receives a response. Commands begin with a four-letter verb. Responses begin with a three number response code.

There are nine (9) command verbs:  AUEP, AUCX, CRCX, DLCX, EPCF, MDCX, NTFY, RQNT, RSIP

Two verbs are used by a Call Agent to query (the state of) a Media Gateway:

 AUEP - Audit Endpoint

 AUCX - Audit Connection

Three verbs are used by a Call Agent to manage an RTP connection on a Media Gateway (a Media Gateway can also send a DLCX when it needs to delete a connection for its self-management):

 CRCX - Create Connection

 DLCX - Delete Connection

 MDCX - Modify Connection

One verb is used by a Call Agent to request notification of events on the Media Gateway, and to request a Media Gateway to apply signals:

 RQNT - Request for Notification

One verb is used by a Call Agent to modify coding characteristics expected by the "line-side" on the Media Gateway:

 EPCF - Endpoint Configuration

One verb is used by a Media Gateway to indicate to the Call Agent that it has detected an event for which the Call Agent had previously requested notification of (via the RQNT command verb):

 NTFY - Notify

One verb is used by a Media Gateway to indicate to the Call Agent that it is in the process of restarting:

 RSIP - Restart In Progress

MGCP Backhauling

• Transports complete IP telephony signaling information using TCP
• Terminates Q.921 signaling functions on the MGCP gateway
• Ensures the integrity of the Q.931 signaling information
• Framing and Layer 2 signaling terminates at the gateway
• Layer3 signaling is backhauled to CUCM using TCP port 2428

MGCP PRI backhaul is a method for transporting complete IP telephony signaling information from an ISDN PRI interface on a MGCP gateway to Cisco Communication Manager through a Transmission Control Protocol (TCP) connection. MGCP PRI backhaul terminates all of the ISDN PRI Layer 2 (Q.921) signaling functions on the MGCP gateway and packages all of the ISDN PRI Layer 3 (Q.931) signaling information into packets for transmission to Cisco Communication Manager through an IP tunnel. In this way, MGCP PRI backhaul ensures the integrity of the Q.931 signaling information that passes through the network for managing IP telephony devices.

The MGCP gateway also establishes a TCP link to the backup (secondary) Cisco Communication Manager server. In the event of a Cisco Communication Manager switchover, the secondary Cisco Communication Manager server performs the MGCP PRI backhaul functions. During the switchover, all active ISDN PRI calls are preserved, and the affected MGCP gateway is registered with the new Cisco Communication Manager server through a ReStart In Progress (RSIP) message. In this way, continued gateway operation is ensured

MGCP-controlled backhaul of BRI signaling provides service to remote-office gateways that are connected by ISDN BRI trunks to a centralized Cisco Communication Manager. D-channel signaling information is backhauled to Cisco Communication Manager through a TCP session. All Q.931 messages are passed through the TCP connection between the Cisco MGCP gateway and Cisco Communication Manager.

MGCP configuration

MGCP configuration on Cisco gateway

! keep in mind hostname & domain name are important in MGCP configuration

Card type e1 0 0

!

network-clock-participate wic 0

network-clock-select 1 E1 0/0/0

!

isdn switch-type primary-net5 

!

controller E1 0/0/0

 framing no-crc4

 linecode hdb3

 pri-group timeslots 1-31 service mgcp

!

voice-port 0/0:15

!

mgcp call-agent 10.10.10.3

ccm-manager mgcp

ccm-manager redundant-host 10.10.10.2

ccm-manager music-on-hold

ccm-manager config

mgcp dtmf-relay voip codec all mode out-of-band

!

Mgcp

!

interface Serial0/0/0:15

 no ip address

 encapsulation hdlc

 isdn switch-type primary-net5

 isdn incoming-voice voice

 isdn bind-l3 ccm-manager

 no cdp enable

!

MGCP Gateway configuration in CUCM

To add the gateway to CUCM follow below instructions:

- From CUCM  Administration, choose  Device > Gateway.

- Click the Add New  button. The Add a New Gateway window will open.

- From the Gateway Type drop-down list, choose the appropriate MGCP gateway (2801, 2811, etc) and click next.

- Choose MGCP from the Protocol drop-down menu and click Next.

- Enter the hostname or fully qualified domain name of the gateway in the Domain Name field. The name has to match the hostname or the hostname and domain name (fully qualified domain name) of the Cisco IOS router.

- Enter a description for the gateway.

- Select a CUCM group.

- Configure the IDSN switch type.

- Click Save. Reset the gateway for the configuration changes to apply.

- Locate the Configured Slots, VICs, and Endpoints section, and select the voice hardware module placed in the slot.

- Click Save. The subunits (voice interface cards slots) of the selected voice module will display.

- For each subunit (voice interface cards slot), select the subunit. (show diag at th gateway will list modules  and interface cards that the gateway is equipped with)

- Click Save. The endpoints of the selected voice interface card will display.

To configure an MGCP endpoint, follow these steps:

- Click the endpoint identifier.

- Select the device protocol or signaling for the endpoint. T1 and E1 interfaces support channel associated signaling (CAS) or command channel signaling (CCS) via ISDN PRI. Analog interfaces support ground-start and loop-start signaling. Select the protocol that should be used on the endpoint and click Next.

- Enter a description for the endpoint

- Select the device pool that should be used by this endpoint.

- Click Save. Reset the gateway for configuration changes to be committed to the gateway

MGCP Gateway Registration Verification:

use show ccm-manager at the gateway to verify MGCP Gateway registration to  CUCM was successful

use show mgcp endpoints at the gateway to verify MGCP Endpoints have registered

 

Troubleshooting the IOS MGCP Gateway

One way call failure, on either outbound call or inbound calls individually, can occur in an IOS MGCP gateway. In order to resolve this issue, reconfigure the MGCP gateway. Generally, this involves a reconfiguration of the PRI interfaces and/or FXO interfaces. Then, a restart of the mgcp protocol on the gateway by issuing the no mgcp IOS command and the mgcp command in global configuration mode.

Cannot make calls from an analog phone connected to the MGCP IOS gateway. A busy tone is received.

Perform this procedure in order to resolve this problem:

1.   Make sure the application mgcpapp command is configured on the applicable port.

  



 

H.323 Gateway

 

H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio & video communication sessions on any packet network. The H.323 Standard addresses call signaling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences

H.323 is a system specification that describes the use of several ITU-T and IETF protocols. The protocols that comprise the core of almost any H.323 system

• H.225 Call Signaling, which is used between any two H.323 entities in order to establish communication.
• H.245 control protocol for multimedia communication, which describes the messages and procedures used for capability exchange, opening and closing logical channels for audio, video and data, control and indications.
• Real-time Transport Protocol (RTP), which is used for sending or receiving multimedia information (voice, video, or text) between any two entities.

Codecs that are widely implemented by H.323 equipment include:

• Audio codecs: G.711, G.729 (including G.729a), G.723.1, G.726, G.722, G.728
• Text codecs: T.140
• Video codecs: H.261, H.263, H.264

·         Peer to Peer protocol

·         No central control

·         Each gateway act on its own

·         All PSTN signaling terminates on gateway

·         H.323 and H.245 signaling communication over TCP between gateway & CUCM (Cisco unified Communication Manager )

·         Media over UDP directory between gateway and IP phones, CUCM responsible for call setup/tear-down and negotiation capability only

·         Gateway status on CUCM always remain “Unknown”

·         Dial plan and translation can be configured per gateway basis.

·         Call preservation for Cisco SRST

Card type e1 0 0
!
network-clock-participate wic 0
network-clock-select 1 E1 0/0/0
!
isdn switch-type primary-net5 
!
controller E1 0/0/0
 framing no-crc4
 linecode hdb3
 pri-group timeslots 1-31
!
voice-port 0/0:15
 
!
dial-peer voice 1 pots
Incoming called-number.
 direct-inward-dial
port 0/0/0:15

Now we have to check the status of PRI using show isdn status command. If you see the layer 2 state as MULTIPLE_FRAME_ESTABLISHED this means that PRI is successfully configured and ready to make/receive Calls. If it doesn’t show the MULTIPLE_FRAME_ESTABLISHED then follow the PRI/E1 blog

VOICE_GW#show isdn status

Global ISDN Switchtype = primary-net5

ISDN Serial0/0/0:15 interface

        dsl 0, interface ISDN Switchtype = primary-net5

    Layer 1 Status:

        ACTIVE

    Layer 2 Status:

        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

    Layer 3 Status:

        5 Active Layer 3 Call(s)

    Activated dsl 0 CCBs = 1

        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA

    The Free Channel Mask:  0xFFFF78FC

ISDN Serial0/0/0:15 interface

        dsl 1, interface ISDN Switchtype = primary-net5

    Layer 1 Status:

        ACTIVE

    Layer 2 Status:



H.225 timer is set to three seconds; the router attempts a connection to the primary CUCM Server. If it does not receive a response in three seconds; it falls back to the secondary CUCM Server.

!

voice class h323 1

  h225 timeout tcp establish 3

! Use this interface specific command, H323-gateway voip bind scraddr x.x.x.x, in the H.323 gateway to force it to use a specific IP address for H.225 setup messages with CUCM.

interface GigabitEthernet0/0
ip address 10.10.10.100 255.255.255.0
h323-gateway voip interface
h323-gateway voip bind srcaddr 10.10.10.100
!
Note: we assume that PSTN Provider sending 4digit of DID called number if Service Provider is sending more than 4 digit then translation rule required to translate the called number into 4 digits.

!  Dial peer 11 route the incoming calls from PSTN for 4000-4999 towards the Publisher CUCM.( When you set the preference order, the lower the preference number, the higher the priority. The highest priority is given to the dial peer with preference order 0 and it is the default value. You can have a preference value between 0 to 10)

dial-peer voice 11 VoIP 
 Description ******CUCM Pub**** 
 destination-pattern 4… 
 session target ipv4: 10.10.10.2 
 dtmf-relay h245-alphanumeric
 voice-class h323 1 
 codec g711ulaw
 Preference 2  
 no vad
!
! Dial peer 12 route the incoming calls from PSTN for 4000-4999 towards the Subscriber CUCM

dial-peer voice 12 VoIP 
 Description ******CUCM Sub**** 
 destination-pattern 4... 
 session target ipv4: 10.10.10.3 
 dtmf-relay h245-alphanumeric
 voice-class h323 1 
  codec g711ulaw
  preference 1
 no vad
!

! Below translation rule will add the prefix (9) in all incoming calling number from PSTN. This will be help the  users  to make call using missed/received calls from their phone.
!
voice translation-rule 1  rule 1 /^\(.*\)/ /9\1/
!
voice translation-profile addinPrefix 
 translate calling 1
 !
voice-port 0/0/0:15
translation-profile incoming addinPrefix
!
! Dial Plan for outgoing calls to PSTN

dial-peer voice 991 pots 
 Description *** 3 digit outgoing call***** 
 destination-pattern 9[1-9].. 
  port 0/0/0:15 
 forward-digits 3
!
dial-peer voice 992 pots 
 Description *** 7 digit outgoing call***** 
 destination-pattern 9[2-9]...... 
 port 0/0/0:15 
 forward-digits 7
!
dial-peer voice 993 pots
Description *** 10 digit outgoing call*****
 destination-pattern 905[056].......
 port 0/0/0:15
 prefix 05
!
dial-peer voice 994 pots
 Description *** 9 digit outgoing call*****
 destination-pattern 90[234679].......
 port 0/0/0:15
 prefix 0

!

dial-peer voice 995 pots

 Description ** international outgoing calls***

 destination-pattern 900T

 port 0/0/0:15

 prefix 00

!

H.323 Gateway configuration in Cisco Unified Communication Manager

Click on Device and then Gateway

 

 

Then click on Add New

Select H.323 Gateway from the Gateway Type list

Device Name: 10.10.10.100 Gateway address and click on save

Device >> Gateway



Troubleshooting

Problem

Calls from a Cisco IP phone to a PSTN/PBX phone ring, but as soon as the called party picks up the phone, both ends hear a fast-busy

Symptom

There is a CODEC mismatch between the Cisco IP phone and the H.323 gateway.

Solution
 Check these items in CUCM and the IOS® configuration:

1.       Double check the Region and Device Pool configuration in CUCM, where CODEC is defined. Newer Cisco IP phones (79xx) support G.711 and G.729.

2.       If G.729 is needed between the gateway and Cisco IP phone, make sure the Media Termination Point Required box is not checked on the Gateway Configuration page. Otherwise, the gateway connection always uses G.711.

3.       Make sure the proper CODEC is defined under voip dial-peer on the H.323 gateway. The default is G.729r8.

Problem

Inbound calls from PSTN do not complete to CUCM and the Cisco IP phone, while the CUCM and H.323 gateway are properly configured.

Symptom
From debug cch323 h225 on the H.323 gateway, it sends out an H.225 setup message to CUCM, but never hears back. This is because CUCM does not know how to reach the IP address that the H.323 gateway used for the H.225 setup message.

Solution
Use the interface specific command, H323-gateway voip bind scraddr x.x.x.x, in the H.323 gateway to force it to use a specific IP address (which is reachable by CUCM) to send the H.225 setup message.

Problem
Inbound calls from the PSTN to CUCM do not work, while outbound calls from CUCM to the PSTN work fine.

Symptom
From debug voip ccapi inout on the H.323 gateway, CUCM disconnects the call because of an unassigned number (0x1) or invalid number (0x1C).

Solution
Check the CUCM configuration to make sure that the H.323 gateway is in a Calling Search Space that enables it to reach the Partitions that the IP phones belong to.

Problem
Inbound calls from the PSTN to CUCM do not work, while outbound calls from CUCM to the PSTN work fine.

Symptom
From debug voip ccapi inout on the H.323 gateway, the gateway disconnects the call because of an unassigned number (0x1) or invalid number (0x1C).

Solution
Check the IOS configuration for any number-expansions or translation patterns. Any called number that comes from the PSTN needs to go through these patterns before it is matched to the VoIP dial-peer.