Cisco Voice Guru

The determining factor for whether a gateway registers with a TYPE of VOIP-GW or H323-GW relies entirely on the “allow-connections” commands entered under “voice service voip.” Essentially, if your gateway is functioning as an IP-to-IP gateway, it will display H323-GW.

The commands that make or break this:

voice service voip
allow-connections h t h
allow-connections h t s
allow-connections s t h
allow-connections s t s

After adding or removing these, make sure to bounce your gateway registration with the gatekeeper using “no gateway” and “gateway.”

I just verified this. Here is a snapshot without the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 58978 Spain VOIP-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

After adding the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 50555 Spain H323-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

I am reading in the Cisco IOS H.323 Configuration guide this morning.  Yes, it’s exhilarating to read at 5:00am (NOT!).  Since I’m nodding off to sleep, I am writing another post to pass on the next bit of knowledge – configuring RAS retries and timers.

Normally, you would never need to touch this piece of H.323 gateways, but we’re not dealing with “normal,” real-world experience.  We’re dealing with the psychotic CCIE voice lab.  You need to know everything.

Read the rest of this entry »

Usage Guidelines

Use the debug ras command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in International Telecommunications Union-Telecommunication (ITU-T) specification H.225.
Examples

Practical Example

In the following output, gateway GW13.cisco.com sends a RAS registration request (RRQ) message to gatekeeper GK15.cisco.com at IP address 10.9.53.15. GW13.cisco.com then receives a registration confirmation (RCF) message from the gatekeeper.

If there is no response, it could mean that the gatekeeper is offline or improperly addressed.

If you receive a reject (RRJ) message, it could mean that the gatekeeper is unable to handle another gateway or that the registration information is incorrect.

Router# debug ras
*Mar 13 19:53:34.231: RASlib::ras_sendto:msg length 105 from 10.9.53.13:8658 to 10.9.53.15:1719
*Mar 13 19:53:34.231: RASLib::RASSendRRQ:RRQ (seq# 36939) sent to 10.9.53.15
*Mar 13 19:53:34.247: RASLib::RASRecvData:successfully rcvd message of length 105 from 10.9.53.15:1719
*Mar 13 19:53:34.251: RASLib::RASRecvData:RCF (seq# 36939) rcvd from [10.9.53.15:1719] on sock [0x6168356C]

Yesterday, I worked on some gateway and gatekeeper exercises using IPexpert’s workbooks and ProctorLabs remote racks.  During my exercises, I had an issue with calls being routed from a CUCME H.323-configured gateway, through the HQ gatekeeper, and on to CUCM via H.225 gatekeeper-controlled trunk.  When I would place a call from the remote CUCME, I would get a message from the CUCM annunciator saying, “Your call cannot be completed as dialed.”  In the end, all I needed to do was reset the H.225 trunk in CUCM.  However, there were a few things I learned/saw along the way that were worth putting up on the site.

Read the rest of this entry »

Problem:

When you have a gatekeeper configured with zones that contain overlapping dial-plans, you need to be cognizant of your use of dots and asterisks in zone statements.  Otherwise, you will create (as Cisco puts it) “ambiguous situations” in which the gatekeeper will not know which zone or gateway it should send a call to.

For example:

gatekeeper
zone local localzone1 dns.au 10.1.1.228zone local localzone2 dns.au
no zone subnet localzone1 default enable
zone subnet localzone1 10.1.1.240/28 enable
no zone subnet localzone2 default enable
zone subnet localzone2 10.99.0.0/16 enable
zone prefix localzone1 0*
zone prefix localzone1 1*
zone prefix localzone1 6*
zone prefix localzone1 8*
zone prefix localzone2 9999931..
Zone prefix localzone2 9999932..
Zone prefix localzone2 9999933..
Zone prefix localzone2 9999934..
Zone prefix localzone2 9999935..
Zone prefix localzone2 9999936..
Zone prefix localzone2 9999937..
Zone prefix localzone2 9999938..
Zone prefix localzone2 9999939..
Zone prefix localzone2 999994…
zone prefix localzone2 999995…
zone prefix localzone1 9*
accounting vsa
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
lrq reject-unknown-prefix
no use-proxy localzone2 default inbound-to terminal
no use-proxy localzone2 default outbound-from terminal
no shutdown
endpoint ttl 60

Symptoms and Characteristics:

• The local gatekeeper is expected to route calls to more than one local zone or is expected to route calls to gatekeepers in remote zones or both.
• Calls within a local zone can be routed successfully.
• Some, but not all, interzone calls can be routed successfully.
• The interzone calls that are not routed successfully are to called numbers with a specific number of digits. For example, calls to a 10-digit or nine-digit number may succeed, while a call to a three-digit number starting with the same digit reliably fails.
• The gatekeeper configuration makes use of dot wildcards within zone prefixes.

Solution:

When you specify wildcard digits within a zone prefix, avoid using dots where possible. Instead, use the less-specific asterisk wildcard. You can also avoid the problem when you observe these rules:

1. If the dial-plan is consistent, you can use a configuration with only dots (or using only asterisks).
2. If there is an overlap in the dial-plan, it is best to stick to using configurations with asterisks.
3. If there is overlap in the dial-plan, and a configuration with only asterisks is not suitable, study the gatekeeper’s default behavior of prefix guessing (deduce and prepend the local area code) before you configure the gatekeeper.

The third rule requires an understanding of the details of the gatekeeper’s behavior as described in this document.

Debug Examples:

This is debug output from the gatekeeper that shows Registration, Admission, and Status Protocol (RAS) flows and zone prefix processing for:

debug h225 asn1 and debug gatekeeper main 10 – failed call

GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!— This output is from the debug h225 ans1 command issued on the gatekeeper. It shows
!— an incoming RAS ARQ for called number 112. It is important to
!— note that the calling number (source endpoint) comes from the zone localzone2 and,
!— assuming three-digit numbers, its prefix (source endpoint prefix) is 999995.

Mar 11 21:48:15: RAS INCOMING PDU ::=

value RasMessage ::= admissionRequest :
{
requestSeqNum 36784
callType pointToPoint : NULL
callModel gatekeeperRouted : NULL
endpointIdentifier {“618FED9800000008″}
destinationInfo
{
e164 : “112″,
e164 : “112″
}
srcInfo
{
h323-ID : {“999995985″},
e164 : “999995985″
}
srcCallSignalAddress ipAddress :
{
ip ’0A14000C’H
port 11309
}
bandWidth 1280
callReferenceValue 31633
conferenceID ’5634343434EF21002B211E5226E91D26′H
activeMC FALSE
answerCall FALSE
canMapAlias FALSE
callIdentifier
{
guid ’5634343434EF20002B211E5226E91D26′H
}
gatekeeperIdentifier {“localzone2″}
willSupplyUUIEs FALSE
}

!— This output is from the debug gatekeeper main 10 command
!— issued on the gatekeeper. It
!— shows the gatekeeper zone prefix processing logic (rassrv_get_addrinfo).
!— Comments are inserted throughout.

Mar 11 21:48:15: gk_rassrv_arq: arqp=0x61A09EE4, crv=0x7B91, answerCall=0
Mar 11 21:48:15: ARQ Didn’t use GK_AAA_PROC

!— Tech-prefix matching occurs first. In this case study, no
!— tech-prefixes are configured so no match is found.

Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.

!— The next line in the trace is the key to what, in this case study, is unexpected
!— behavior. The expected behavior is for 112 to match with the wildcard “1*” entry
!— in localzone1.

!— The local (source) zone of the calling number is localzone2.
!— It has been configured as
!— supporting the prefix “999995…” with three wildcard digits.
!— (Note the configuration line
!— “zone prefix localzone2 999995…”.)

!— The gatekeeper, when asked to resolve a three-digit number 112,
!— deduces this to mean “999995-112″ in the local zone because
!— “112″ matches with the specific-length three-dot
!— wildcard configuration for the local zone.

!— This behavior is exactly the same as a local area code being assumed when a local
!— call is made.

!— If the configuration line “zone prefix localzone2 999995…” was removed from the
!— configuration, or if the line “zone prefix localzone2 999995*” was inserted instead,
!— then the three-digit number “112″ would not match in the local
!— zone but would rather match localzone1 through the
!— configuration line “zone prefix localzone1 1*”.

Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint’s zone prefix 999995

Mar 11 21:48:15: No tech-prefix

Mar 11 21:48:15: Alias not found

!— The gatekeeper attempts to find a default technology prefix, But although “#1″ is
!— configured, the H.323 endpoints in localzone2 correctly do not register with that. The
!— conclusion drawn is that there is an “unknown address and no default
!— technology defined”:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0×805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint’s zone prefix 999995
Mar 11 21:48:15: No tech prefix

Mar 11 21:48:15: Alias not found

!— The gatekeeper indicates that it has failed to find a registered match for the
!— called number in localzone2:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0×805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0×103)

!— The gatekeeper sends the Admission Reject (ARJ) because the called party is not
!— registered:

Mar 11 21:48:15: RAS OUTGOING PDU ::=

value RasMessage ::= admissionReject :
{
requestSeqNum 36784
rejectReason calledPartyNotRegistered : NULL
}

debug gatekeeper main 10 – successful call

This debug is an extract from the output of the debug gatekeeper main 10 command and shows a successful call.

GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!— The four-digit called number 1003 does not match with the three-dot wildcard
!— for localzone2 noted earlier. Instead, it matches with the less-specific
!— asterisk wildcard for localzone1.

Feb 19 16:52:19: rassrv_get_addrinfo(1003): Tech-prefix match failed.
Feb 19 16:52:19: rassrv_get_addrinfo(1003): Matched zone prefix 1 and remainder 003
Feb 19 16:52:19: No tech prefix
Feb 19 16:52:19: Alias not found

!— The gatekeeper finds a default technology prefix (of #1) since the 5350
!— TGWs register with this prefix as per the show gatekeeper gw-type-prefix command.

Feb 19 16:52:19: Technology GW selected

gatekeeper
  zone local localzone1 dns.au 10.1.1.228
  zone local localzone2 dns.au
  no zone subnet localzone1 default enable
  zone subnet localzone1 10.1.1.240/28 enable
  no zone subnet localzone2 default enable
  zone subnet localzone2 10.99.0.0/16 enable
  zone prefix localzone1 0*
  zone prefix localzone1 1*
  zone prefix localzone1 6*
  zone prefix localzone1 8*
  zone prefix localzone2 9999931..
  Zone prefix localzone2 9999932..
  Zone prefix localzone2 9999933..
  Zone prefix localzone2 9999934..
  Zone prefix localzone2 9999935..
  Zone prefix localzone2 9999936..
  Zone prefix localzone2 9999937..
  Zone prefix localzone2 9999938..
  Zone prefix localzone2 9999939..
  Zone prefix localzone2 999994...
  zone prefix localzone2 999995...
  zone prefix localzone1 9*
  accounting vsa
  gw-type-prefix 1#* default-technology
  arq reject-unknown-prefix
  lrq reject-unknown-prefix
  no use-proxy localzone2 default inbound-to terminal
  no use-proxy localzone2 default outbound-from terminal
  no shutgatekeeper   zone local localzone1 dns.au 10.1.1.228   zone local localzone2 dns.au   no zone subnet localzone1 default enable   zone subnet localzone1 10.1.1.240/28 enable   no zone subnet localzone2 default enable   zone subnet localzone2 10.99.0.0/16 enable   zone prefix localzone1 0*   zone prefix localzone1 1*   zone prefix localzone1 6*   zone prefix localzone1 8*   zone prefix localzone2 9999931..   Zone prefix localzone2 9999932..   Zone prefix localzone2 9999933..   Zone prefix localzone2 9999934..   Zone prefix localzone2 9999935..   Zone prefix localzone2 9999936..   Zone prefix localzone2 9999937..   Zone prefix localzone2 9999938..   Zone prefix localzone2 9999939..   Zone prefix localzone2 999994...   zone prefix localzone2 999995...   zone prefix localzone1 9*   accounting vsa   gw-type-prefix 1#* default-technology   arq reject-unknown-prefix   lrq reject-unknown-prefix   no use-proxy localzone2 default inbound-to terminal   no use-proxy localzone2 default outbound-from terminal   no shutdown   endpoint ttl 60down
  endpoint ttl 60

Read the rest of this entry »

RAI Concept:

Resource Allocation Indication allows gatekeepers to make informed call routing decisions based on a predefined threshold levels for DS0 channels and DSP channels.  The gateway will report its utilization statistics via H.225 RAI to the H.323 gatekeeeper.  When a monitored resource falls below the configured threshold, the gateway will inform the gatekeeper that it is almost out of resources.

H.323 version 2 and 3 support yes/no resource availability information.  H.323 version 4 introduced call capacity.

How RAI Works:

Resource reporting thresholds are configured by using the resource threshold command under the gateway CLI. The upper and lower thresholds are separately configurable to prevent the gateway from operating sporadically due to the availability or lack of resources.  The default for “high” and “low” values is 90.

resource threshold [all] [high percentage-value] [low percentage-value]

Utilization is calculated taking with the following formula:
Accessible channels = Inuse + Free
Utilization = Inuse / Acceptable

For example, assume you have four T1 PRIs: two PRIs for incoming calls, two for outgoing. You have busied out 44 timeslots of the outgoing timeslots and you have one call on one of the outgoing timeslots. You will have:

• Total = 92 (23 B channels x 4 T1 PRIs)
• Addressable = 46 (23 B channels x 2 T1 PRIs)
• Disabled = 44
• Inuse = 1
• Free = 1

The utilization = 1/(1+1)= 50 %.   Therefore, if the configured high threshold is 90%, the Gateway still accepts calls.

Additional Insights:

• The above calculations only took the DS0 resources into consideration. However, the DSP resources are monitored and calculated in the same way. Also, depending on which resource (DSP or DS0) reaches the low or high threshold first, the gateway sends the RAI messages.
• No configuration is needed on the gatekeeper to activate the RAI.
• An RAI message, like any other RAS message, is UDP. Once the gateway sends an RAI message to the gatekeeper, it starts a three second timer. If the timer expires before it receives the RAC, the gateway tries to send the RAI again nine more times. Then, it gives up until the resource availability status changes again.
• RAI is useful if you want to give priority to a certain gateway. Also, once the threshold is reached, then you route the traffic to other gateways.
• With the command lrq reject-resource-low, the gatekeeper rejects the inter-zone call if all gateways in that zone are marked as almost-out-of-resources. This command is integrated in Cisco IOS Software Release 12.1(3a)XI6. If you do not use this command, the gatekeeper does not reject any calls from other zones when all gateways in that zone are marked as out of resources.

H.323 Gateway Configuration

interface Ethernet0
ip address 172.16.13.45 255.255.255.224load-interval 30
h323-gateway voip interface
h323-gateway voip id cisco_2 ipaddr 172.16.13.42 1718
h323-gateway voip h323-id 5300-3
h323-gateway voip tech-prefix 2#
!
gateway
resource threshold high 70 low 60

Verification

show gateway
show pool
show call resource voice stat
show call resource voice threshold
show gatekeeper gw-type-prefix
show gatekeeper endpoint

Debugs

Turn on debug ras and debug h225 asn1 if you think that the gateway is not sending the proper RAI message or the gatekeeper is not sending the RAC message.