1.    voice service voip

2.    no shutdown forced

3.    exit

1.    voice service voip

2.    h323

3.    no call service stop forced maintain-registration

4.    exit

1.    show gateway

Router# show gateway
H.323 ITU-T Version: 4.0   H323 Stack Version: 0.1
 H.323 service is shutdown
 Gateway  Router is not registered to any gatekeeper

Router# show gateway
H.323 ITU-T Version: 4.0   H323 Stack Version: 0.1
 H.323 service is shutting down
 Gateway  Router is registered to Gatekeeper GK1

Router# show gateway
H.323 ITU-T Version: 4.0   H323 Stack Version: 0.1
 H.323 service is shutdown
 Gateway  Router is registered to Gatekeeper GK1

1.    dial-peer voice tag pots

2.    destination-pattern string [T]

3.    port controller :D

4.    exit

5.    dial-peer voice tag voip

6.    destination-pattern string [T]

7.    tech-prefix number

8.    session target ras

9.    exit

1.    show dial-peer voice

Router# show dial-peer voice 1234
VoiceOverIpPeer1234
tag = 1234, destination-pattern = 1234',
answer-address = ',
group = 1234, Admin state is up, Operation state is up,
incoming called-number = ', connections/maximum = 0/unlimited,
application associated:
type = voip, session-target = ras',
technology prefix: 8#
ip precedence = 0, UDP checksum = disabled,
session-protocol = cisco, req-qos = controlled-load,
acc-qos = best-effort,
fax-rate = voice, codec = g729r8,
Expect factor = 10, Icpif = 30,
VAD = enabled, Poor QOV Trap = disabled,

• To display the types and addressing of RAS messages sent and received, use the debug rascommand. The debug output lists the message type using mnemonics defined in ITU-T specification H.225.
• To display additional information about the actual contents of the H.225 RAS messages, use the debug h225 asn1 command.

1.    voice service voip

2.    h323

3.    ras timeout {all | arq | brq | drq| grq | rai | rrq} value

4.    ras retry {all | arq | brq | drq| grq | rai | rrq} value

5.    exit

1.    voice service voip

2.    h323

3.    ras rrq ttl time-to-live [margin time]

4.    exit

1.    show running config

Router# show running-config
Current configuration : 925 bytes
!
version 12.3
.
.
.
voice service voip
 h323
  ras rrq ttl 90 margin 30
  ras timeout all 7
  ras timeout grq 10
  ras timeout drq 30
  ras retry all 10
  ras retry grq 5
.
.
.

To allow gatekeepers to make intelligent call-routing decisions, the gateway reports the status of its resource availability to its gatekeeper. Resources that are monitored are digital-signal-level 0 (DS0) channels and digital-signal-processor (DSP) channels.

The gateway reports its resource status to the gatekeeper using the RAS Resource Availability Indication (RAI). When a monitored resource falls below a configurable threshold, the gateway sends a RAI to the gatekeeper indicating that the gateway is almost out of resources. When the available resources then cross over another configurable threshold, the gateway sends an RAI indicating that the resource depletion condition no longer exists.

You can configure resource-reporting thresholds by using the resource threshold command. Upper and lower thresholds are separately configurable to prevent the gateway from operating sporadically because of the availability or lack of resources.

The Cisco H.235-based security and accounting features described in this section can be used by a gatekeeper, which is considered a known and trusted entity, to authenticate, authorize, and route H.323 calls.

The Cisco H.323 gateway supports the use of CryptoH323Tokens for authentication. The CryptoH323Token is defined in the ITU-T H.225 Version 2 standard and is used in a "password-with-hashing" security scheme as described in section 10.3.3 of the H.235 specification.

A cryptoToken can be included in any RAS message to authenticate the sender of the message. A separate database can be used for user ID and password verification.

Cisco H.323 gateways support three levels of authentication:

• Endpoint--The RAS channel used for gateway-to-gatekeeper signaling is not a secure channel. To ensure secure communication, H.235 allows gateways to include an authentication key in their RAS messages. This key is used by the gatekeeper to authenticate the source of the messages. At the endpoint level, validation is performed on all messages from the gateway. The cryptoTokens are validated using the password configured for the gateway.

Note	To secure the RAS messages and calls, it is essential that the gatekeeper provides authentication based on the secure key. The gatekeeper must support H.235 security using the same security scheme as the Cisco gateway.

• Per-Call--When the gateway receives a call over the telephony leg, it prompts the user for an account number and PIN. These two numbers are included in certain RAS messages sent from the endpoint to authenticate the originator of the call.
• All--This option is a combination of the other two. With this option, the validation of cryptoTokens in ARQ messages is based on an the account number and PIN of the user making a call. The validation of cryptoTokens sent in all the other RAS messages is based on the password configured for the gateway.

CryptoTokens for RRQs, unregistration requests (URQs), DRQs, and the terminating side of ARQs contain information about the gateway that generated the token. The cryptoTokens include the gateway identification (ID)--which is the H.323 ID configured on the gateway--and the gateway password. The cryptoTokens for the originating-side ARQ messages contain information about the user that is placing the call, including the user ID and PIN.

Although the scenarios in this document describe how to use the security and accounting features in a prepaid call environment, these features may also be used to authorize IP calls that originate in another domain (interservice provider or intercompany calls).

H.235-based security and accounting features can be used with AAA. The gateway can be configured to use the gatekeeper for call authentication or authorization, and AAA can be used for call accounting.

In addition, H.235-based security and accounting features include support for the following:

• Settlement with the gatekeeper, which allows the gateway to obtain, track, and return accounting information
• Call metering, which allows the gateway to terminate a call if it exceeds the allotted time (in the case of prepaid calls)

Note

The H.235 security and accounting features described in this document are separate from, and should not be confused with, the standard interactive-voice-response (IVR) and AAA features used to authenticate inbound calls or with the settlement functions provided by the Open Settlement Protocol (OSP).

• Settlement with the Gatekeeper
• Call Tracking

Tool Command Language (TCL) IVR scripts are the default scripts for all Cisco voice features that use IVR.

The H.323 security and accounting enhancements described in this document require the use of one of the following IVR scripts:

• voip_auth_acct_pin_dest.tcl
• voip_auth_acct_pin_dest_2.tcl

Note	For more information on TCL IVR applications, see the Cisco IOS TCL and VoiceXML Application Guide at http://www.cisco.com/en/US/docs/ios/voice/ivr/configuration/guide/tcl_c.html .

• voip_auth_acct_pin_dest.tcl Script
• voip_auth_acct_pin_dest_2.tcl Script

1.    gateway

2.    security password password level {endpoint | per-call | all}

3.    exit

4.    dial-peer voice tag pots

5.    call application voice application-name location word

6.    destination-pattern string [T]

7.    port controller-number :D

8.    exit

1.    show running-config

Router# show running-config
security password 151E0A0E level all

• You can use this feature only with a gatekeeper that supports the alternate gatekeeper functionality.
• The timer/retry number of RAS messages remains internal to the gateway as currently implemented. This feature does not include commands to allow tuning of these parameters.
• The alternate gatekeeper list is volatile--when the gateway loses power or is reset or reloaded, the alternate gatekeeper list that has been acquired from the gatekeeper is lost.

A gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the gatekeeper and to locate another gatekeeper. The gatekeeper provides logic variables for proxies or gateways in a call path to provide connectivity with the Public Switched Telephone Network (PSTN), to improve quality of service (QoS), and to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into the DNS or by using Cisco IOS configuration options.

An alternate gatekeeper provides redundancy for a gateway in a system in which gatekeepers are used. Redundant H.323 zone support in the gateway allows a user to configure two gatekeepers in the gateway (one as the primary and the other as the alternate). All gatekeepers are active. Each alternate gatekeeper, or gatekeeper node, shares its local zone information so that the cluster can effectively manage all local zones within the cluster. Each alternate gatekeeper has a unique local zone. Clusters provide a mechanism for distributing call processing seamlessly across a converged IP network infrastructure to support IP telephony, facilitate redundancy, and provide feature transparency and scalability.

An endpoint that detects the failure of its gatekeeper can safely recover from that failure by utilizing an alternate gatekeeper for future requests, including requests for existing calls. A gateway can only be registered to a single gatekeeper at a time. Only one gatekeeper is allowed to manage a single zone. The cluster manages up to five similarly configured zones and shares resources between the alternate gatekeepers in the cluster for each zone. You can define up to 100 zones in a single gatekeeper.

With gatekeeper clustering there is the potential that bandwidth may be overcommitted in a cluster. For example, suppose that there are five gatekeepers in a cluster and that they share 10 Mbps of bandwidth. Suppose that the endpoints registered to those alternates start placing calls quickly. It is possible that within a few seconds, each gatekeeper could be allocating 3 Mbps of bandwidth if the endpoints on each of the gatekeepers request that much bandwidth. The net result is that the bandwidth consumed in the cluster is 15 Mbps.

The alternate gatekeeper was purposely designed to restrict bandwidth because there is no clear way to sync bandwidth information quickly and efficiently. To work around this problem, "announcement" messages were restricted to intervals as small as 10 seconds. If the gatekeepers get into a situation in which endpoints request bandwidth rapidly, the problem is discovered and corrective action takes place within 10 seconds. Assuming that the gatekeepers are not synchronized on their timers, the announcement messages from the various gatekeepers are likely to be heard more quickly. Therefore, the problem is less severe. The potential exists, however, for overcommitment of the bandwidth between announcement messages if the call volume increases substantially in a short amount of time (as small as 10 seconds).

Note	If you monitor your bandwidth, it is recommended that you consider lowering the maximum bandwidth so that if "spikes" such as those described above do occur, some bandwidth is still available.

1.    interface Ethernet 0/1

2.    h323-gateway voip interface

3.    h323-gateway voip id gatekeeper-id {ipaddr ip-address [port]| multicast} [priority priority]

4.    h323-gateway voip id gatekeeper-id { ipaddr ip-address [ port ] | multicast } [ priority priority ]

5.    h323-gateway voip h323-id interface-id

6.    exit

1.    show gateway

Router# show gateway
Permanent Alternate Gatekeeper List 
priority 127 id bmx1 ipaddr 10.77.241.103 1719 register needed
priority 127 id bmx2 ipaddr 10.77.241.117 1719 register needed
Primary gatekeeper ID bmx1 ipaddr 10.77.241.103 1719

• Asynchronous dtmf-relay signaling configuration is not supported.
• DTMF-relay signaling must have the same configuration on both the outbound gateway and the trunking gateway.

Dual-tone multifrequency (DTMF) is the tone generated on a touchtone phone when the keypad digits are pressed. During a call, DTMF may be entered to access interactive voice response (IVR) systems, such as voice mail and automated banking services.

Although DTMF is usually transported accurately when using high-bit-rate voice codecs such as G.711, low-bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns and tend to distort DTMF tones. As a result, IVR systems may not correctly recognize the tones.

DTMF relay solves the problem of DTMF distortion by transporting DTMF tones "out of band," or separate from the encoded voice stream.

• Relay Types
• Capabilities and Priorities
• Payload Types
• H.245 Tunneling of DTMF Relay in Conjunction with Fast Connect

1.    dial-peer voice tag voip

2.    dtmf-relay [ cisco-rtp ] [ h245-alphanumeric ] [ h245-signal ] [ rtp-nte ]

3.    rtp payload-type nte number

4.    codec {clear-channel | g711alaw | g711ulaw | g723ar53 | g723ar63 | g723r53 | g723r63 | g726r16 | g726r24 | g726r32 | g726r53 | g726r63 | g728 | g729abr8 | g729ar8 | g729br8 | g729r8 | gsmefr| gsmfr} [bytes payload_size]

5.    destination-pattern string [T]

6.    Cisco 2600 Series and Cisco 3600 Series

7.    exit

rtp payload-type nse 105

rtp payload-type nte 100

1.    debug voip rtp session named-event

2.    show voip rtp connections

1.    show running-config

Router(config-dial-peer)# show running config

1.    interface type slot/port

2.    h323-gateway voip bind srcaddr ip-address

3.    exit

1.    show running-config

router# show running-config
interface Loopback0
 ip address 10.0.0.0 255.255.255.0
 no ip directed-broadcast
 h323-gateway voip bind srcaddr 10.0.0.0
!
interface Ethernet0/0
 ip address 172.18.194.50 255.255.255.0
 no ip directed-broadcast
 h323-gateway voip interface
 h323-gateway voip id j70f_2600_gk2 ipaddr 172.18.194.53 1719
 h323-gateway voip h323-id j70f_3640_gw1
 h323-gateway voip tech-prefix 3#
.
.
.

interface Ethernet0/0
 ip address 172.18.194.50 255.255.255.0
 no ip directed-broadcast
 h323-gateway voip interface
 h323-gateway voip id j70f_2600_gk2 ipaddr 172.18.194.53 1719
 h323-gateway voip h323-id j70f_3640_gw1
 h323-gateway voip tech-prefix 3#
 h323-gateway voip bind srcaddr 172.18.194.50

Annex G of the H.323 standard provides address resolution using border elements (BE). The BE (as described in Annex G) is colocated with the Cisco H.323 gatekeeper and provides additional address resolution capabilities. The BE can cache address information from neighboring BEs. When the gatekeeper receives a call that it cannot resolve, it can contact its local BE. If the address is in the BE's cache, the BE on the gatekeeper sends an AccessRequest to the BE in the terminating domain. If the address is not in the BE's cache, then the BE attempts to resolve the address by sending an AccessRequest to each of its neighboring BEs.

Note

The Annex G BEs support Hot Standby Routing Protocol (HSRP) for high reliability and availability. You can identically configure multiple gatekeepers and BEs and use HSRP to designate a primary BE and other standby BEs. If the primary BE is down, a standby BE operates in its place. You configure the local address with an HSRP address in BE configuration.

The figure below illustrates a call flow for a scenario in which a call has originated in the zone administered by Border Element D, but the address cannot be resolved locally.

Figure 3

Address Resolution Using Border Elements

The table below describes how address resolution works in the illustration.

To configure and provision an Annex G border element, use the following commands beginning in global configuration mode.

Note	Cisco supports one BE per gatekeeper.

1.    call-router h323-annexg border-element-id

2.    local ip ip-address [port local-port]

3.    neighbor ip-address

4.    port neighbor-port

5.    id neighbor-id

6.    cache

7.    query-interval query-interval

8.    exit

9.    Repeat Steps 3 to 8 for each neighbor BE that you configure.

10.    advertise [static | dynamic | all]

11.    ttl value

12.    hopcount value

13.    no shutdown

14.    timer accessrequest sequential delay value

15.    exit

16.    gatekeeper

17.    h323-annexg border-element-id cost cost priority priority

18.    prefix prefix* * [seq | blast]

19.    exit

20.    exit

1.    call-router h323-annexg border-element-id

2.    neighbor ip-address

3.    no id neighbor-id

4.    exit

5.    Repeat Steps 3 to 8 for each neighbor BE that you configure.

6.    shutdown

7.    exit

Cisco H.225 Annex G implementation supports the minimal set of Annex G features that are needed to allow Cisco border elements (BE) to interoperate with other BEs per the iNow profile for IP telephony interoperability. The implementation also allows Cisco BEs to interoperate with ClearingHouse and other third-party elements. The figure below depicts a basic network configuration of BEs, gatekeepers, and Clearing Houses. This feature addresses the link between the gatekeeper/border element (GK/BE) in a Cisco domain and the ClearingHouse border element that complies with the Annex G specification and the iNow profile.

Figure 4

Basic Network Configuration

• Restrictions for Basic Service Relationships

1.    call-router h323-annexg border-element-id

2.    neighbor ip-address

3.    usage-indication

4.    retry interval seconds

5.    retry window minutes

6.    exit

7.    exit

8.    Router(config-annexg)# exit

1.    show call-router status

Router# show call-router status neighbors
ANNEX-G CALL ROUTER STATUS:
  ===========================
    Border Element ID Tag   : Celine
    Domain Name             : Celine-Domain
    Border Element State    : UP
    Border Element Local IP : 172.18.193.31:2099
    Advertise Policy        : STATIC descriptors
    Hopcount Value          : 7
    Descriptor TTL          : 3180
    Access Policy           : Neighbors only
    Current Active Calls    : 0
    Current Calls in Cache  : 0
    Cumulative Active Calls : 0
    Usage Ind Messages Sent : 0
    Usage Ind Cfm Rcvd      : 0
    IRRs Received           : 0
    DRQs Received           : 0
    Usage Ind Send Retrys   : 0
  NEIGHBOR INFORMATION:
  =====================
    Local Neighbor ID : (none)
    Remote Element ID : (unknown)
    Remote Domain ID  : (unknown)
    IP Addr           : 1.2.3.4:2099
    Status            : DOWN
    Caching           : OFF
    Query Interval    : 30 MIN (querying disabled)
    Usage Indications :
      Current Active Calls : 0
      Retry Period         : 600 SEC
      Retry Window         : 3600 MIN
    Service Relationship Status: ACTIVE
      Inbound Service Relationship  : DOWN
        Service ID     : (none)
        TTL            : 1200 SEC
      Outbound Service Relationship : DOWN
        Service ID     : (none)
        TTL            : (none)
        Retry interval : 120 SEC (0 until next attempt)

1.    dial-peer voice tag voip

2.    voice-class h323 number

3.    exit

1.    voice class h323 number

2.    h225 timeout setup value

3.    exit

1.    voice service voip

2.    h323

3.    session transport tcp [calls-per-connection value]

4.    exit

1.    voice service voip

2.    h323

3.    h225 timeout tcp call-idle {value value | never}

4.    exit

1.    voice service voip

2.    h323

3.    h225 signal overlap

4.    h225 timeout t302 seconds

5.    exit

1.    enable

2.    configure terminal

3.    voice service voip

4.    h323

5.    no h225 alt-ep hunt user-busy

!

1.    voice service voip

2.    h323

3.    session transport {udp | tcp}

4.    exit

The GTD for GKTMP Using SS7 Interconnect for Voice Gateways feature provides additional functionality to Cisco gateways and gatekeepers in a Cisco SS7 Interconnect for Voice Gateways Solution. The generic transparency descriptor or generic telephony descriptor (GTD) format is defined in the a Cisco-proprietary draft. GTD format defines parameters and messages of existing SS7 ISUP protocols in text format and allows SS7 messages to be carried as a payload in the H.225 RAS messages between gateway and gatekeeper. With the GTD feature, the gatekeeper extracts the GTD message and the external route server derives routing and accounting information based upon the GTD information provided from the Cisco Gatekeeper Transaction Message Protocol (GKTMP).

Currently routing on Cisco gateways is based on generic parameters such as originating number, destination number, and port source. Adding support for SS7 ISUP messages allows the VoIP network to use additional routing enhancements found in traditional TDM switches.

The figure below shows an example of a Cisco SS7 Interconnect for Voice Gateways solution using the GTD feature.

Figure 5

Cisco SS7 Interconnect for Voice Gateways Solution With the GTD Feature

In the originating network, the following events occur:

• The Cisco SC2200 receives SS7 messages from the SS7 network and encapsulates them into GTD format. The messages are then passed to the Cisco originating gateway (OGW).
• Using the GTD feature, the OGW transmits the GTD payload in the Admission Request (ARQ) message to GK1.
• GK1 transmits the GTD payload in a Location Request (LRQ) message to GK2.
• GK 2 uses GKTMP with the GTD feature to decode the GTD payload and transmits it to the route server with the REQUEST LRQ message.
• The route server returns a RESPONSE LCF (Location Confirmation) message that includes the GTD payload to GK2. The route server also returns a service descriptor code (SC) field to GK2. (The SC field is transmitted to the AAA server for billing purposes. The SC field conveys the Carrier ID and trunk number information that is determined by and passed from the Route Server.)
• GK2 passes the LCF that includes the GTD payload and the SC field to GK1.
• GK1 sends an Admission Confirmation (ACF) message that includes the GTD payload to the OGW, along with the SC field.
• The OGW sends the SC field and call detail records (CDRs) to the AAA server.
• When the call ends, the Cisco SC2200 receives the SS7 messages, encodes them into GTD format, and passes them to the OGW.
• The OGW sends a Disengage Request (DRQ) with the GTD payload to GK1.
• GK1 sends the DRQ with the GTD payload to the route server.

In the terminating network, the following events occur:

• The OGW sends the GTD in H.225 the SETUP message to the terminating gateway (TGW).
• The TGW sends regular RAS messages to the gatekeeper.

• Configure your VoIP network and the Cisco SS7 Interconnect for Voice Gateways Solution, including the following components:
  • Cisco SC2200--Cisco MGC Software Release 9.1(5) or higher
  • Cisco IOS gateways--Cisco IOS Release 12.2(2)XU or higher
  • Cisco IOS gatekeepers--Cisco IOS Release 12.2(2)XU or higher
  • Route servers
  • AAA servers

Note	For more information on software and components of the Cisco SS7 Interconnect for Voice Gateways Solution, see the release notes and other documentation at http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/das/index.htm

1.    voice service voip

2.    signaling forward {unconditional | none

3.    exit

1.    dial-peer voice tag voip

2.    signaling forward conditional | unconditional | none

3.    exit

1.    show running-config

Router# show running-config
Building configuration...
Current configuration : 4192 bytes
!
version 12.2
service config
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service internal
service udp-small-servers
!
hostname as5300-2
!
voice service voip
 signaling forward unconditional 
 h323
.
.
.

Router# show running-config
Building configuration...
Current configuration : 4192 bytes
!
version 12.2
service config
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service internal
service udp-small-servers
!
hostname as5300-2
!
.
.
.
!
dial-peer voice 1 pots
 application session
 incoming called-number 25164
 port 0:D
!
dial-peer voice 1513 voip
 destination-pattern 1513.......
 session target ipv4:1.8.156.3
!
dial-peer voice 1408525 voip
 destination-pattern 1408525....
!
dial-peer voice 1800877 voip
 destination-pattern 1800877....
 session target ipv4:1.8.156.3
!
dial-peer voice 2 pots
 destination-pattern 51550
 no digit-strip
 direct-inward-dial
 port 3:D
!
dial-peer voice 51557 voip
 destination-pattern 51557
 signaling forward unconditional
 session target ras
!
dial-peer voice 52557 voip
 destination-pattern 52557
 signaling forward unconditional
 session target ipv4:1.8.156.3
!
.
.
.

To configure the H.323v4 Gateway Zone Prefix Registration Enhancements feature, you must understand the following concepts:

• Additive Registration
• Dynamic Zone Prefix Registration

This section contains the following tasks:

1.    enable

2.    configure terminal

3.    voice service voip

4.    h323

5.    ras rrq dynamic prefixes

6.    exit

7.    gatekeeper

8.    rrq dynamic-prefixes-accept

9.    exit

1.    enable

2.    configure terminal

3.    voice service voip

4.    h323

5.    terminal-alias-pattern 22... priority 8

6.    terminal-alias-pattern 23* priority 7

7.    Repeat Step 5 for each priority you configure.

8.    ras rrq dynamic prefixes

9.    exit

1.    enable