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.
Lesson 1: Gatekeepers don’t change digit strings
Remember this mantra: “Whatever going in the gatekeeper, leaves the gatekeeper.” Whatever digits your gateway sends out will be received on the other end. A call passing through a 3rd party device (i.e. gatekeeper) does not necessitate a transformation. If I send #15002 (i.e. tech prefix + number) from my CUCME remote gateway, that is what CUCM will receive on the other end. Therefore, I need to configure the H.225 gatekeeper-controlled trunk in CUCM to discard the tech prefix (e.g. #1) by setting significant digits to 4. This tells CUCM to only process the rightmost four digits. #15002 becomes 5002 and the #1 is discarded.
Lesson 2: Use RAS debugging
H.225.0 call control signaling is used to setup connections between H.323 endpoints. This is achieved by exchanging H.225 protocol messages on the call-signaling channel.
H.225.0/RAS (Registration, Admission and Status) is the protocol between endpoints (terminals and gateways) and gatekeepers. The RAS is used to perform registration, admission control, bandwidth changes, status, and disengage procedures between endpoints and gatekeepers. An RAS channel is used to exchange RAS messages. This signaling channel is opened between an endpoint and a gatekeeper prior to the establishment of any other channels.
HQ-RTR#debug ras
H.323 RAS Messages debugging is on
@@@ I place a call from CUCME remote gateway to CUCM, using H.225 RAS Dial Peer
HQ-RTR#
*Feb 7 20:32:28.702: RecvUDP_IPSockData successfully rcvd message of length 205 from 10.10.110.3:54771
*Feb 7 20:32:28.702: ARQ (seq# 155) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen = 1134656188
*Feb 7 20:32:28.706: IPSOCK_RAS_sendto: msg length 83 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:28.706: RASLib::RASSendACF: ACF (seq# 155) sent to 10.10.110.3
HQ-RTR#
*Feb 7 20:32:35.946: RecvUDP_IPSockData successfully rcvd message of length 80 from 10.10.110.3:54771
*Feb 7 20:32:35.946: BRQ (seq# 156) rcvd
*Feb 7 20:32:35.946: IPSOCK_RAS_sendto: msg length 5 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:35.946: RASLib::RASSendBCF: BCF (seq# 156) sent to 10.10.110.3
*Feb 7 20:32:35.946: RecvUDP_IPSockData successfully rcvd message of length 176 from 10.10.110.3:54771
*Feb 7 20:32:35.950: IRR (seq# 157) rcvdparse_prCll_nonstd: prCll Nonstd decode succeeded, remlen = 1134656188
@@@ I answer the call, leave connected for 10 seconds, and then terminate the call
*Feb 7 20:32:49.522: RecvUDP_IPSockData successfully rcvd message of length 108 from 10.10.110.3:54771
*Feb 7 20:32:49.522: DRQ (seq# 158) rcvdparse_rasusginfo_nonstd: Ras Usage Info Nonstd decode succeeded, remlen = 1220674372
*Feb 7 20:32:49.526: IPSOCK_RAS_sendto: msg length 3 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:49.526: RASLib::RASSendDCF: DCF (seq# 158) sent to 10.10.110.3
HQ-RTR#
Key RAS messages:
- RegistrationRequest (RRQ)
Request from a terminal or gateway to register with a gatekeeper. Gatekeeper either confirms or rejects (RCF or RRJ). - AdmissionRequest (ARQ)
Request for access to packet network from terminal to gatekeeper. Gatekeeper either confirms or rejects (ACF or ARJ). - BandwidthRequest (BRQ)
Request for changed bandwidth allocation, from terminal to gatekeeper. Gatekeeper either confirms or rejects (BCF or BRJ). - DisengageRequest (DRQ)
If sent from endpoint to gatekeeper, DRQ informs gatekeeper that endpoint is being dropped; if sent from gatekeeper to endpoint, DRQ forces call to be dropped. Gatekeeper either confirms or rejects (DCF or DRJ). If DRQ sent by gatekeeper, endpoint must reply with DCF. - InfoRequest (IRQ)
Request for status information from gatekeeper to terminal. - InfoRequestResponse (IRR)
Response to IRQ. May be sent unsolicited by terminal to gatekeeper at predetermined intervals. - RAS timers and Request in Progress (RIP)
Recommended default timeout values for response to RAS messages and subsequent retry counts if response is not received.
Matt,
Setting the significant digits to 4 on an GK-controlled trunk is one way to discard the tech prefix, but don't forget about possible TEHO calls that may have to come in through the is trunk, in which case this will not work. You will need to look at another possible way to strip the tech prefix in CUCM.
James
Would translation patterns work?
I suspect that this is what James are hinting or also possible a outgoing voice translation profile tied to the dial-peer that points to the UCM. I believe both will do the job.
Roger
The good old num-exp could also be a way to get rid of the tech prefix
/Roger
Here is something that i tried. I used the same dial-peer on CME to send the calls to CCM (adding CME as h323 gw in CCM) keeping the GW setting exactly the way they were in GK trunk and calls completed without any issue. tried calls using g711/G729, same no of sig digits.
am i missing anything…still
Thanks for the post.
I thought i will get a solution to my issue as i am facing same issue but i still cannot figure out. I can make calls using g711/g729 from CCM to CME ( using GK) but reverse is not working. I end up hearing same message that ” your call cannot be completed as dialed….”
I tried struggling with it for 5 hrs and finally gave up. I did reset to GK, CME, CCM GK trunk numerous times but no help.I can see on GK main 10 debug that no string is being sent and tech prefix as well as zone prefix is matched ( no sent as 22#10001 ) but dont know why it doesnt goes to CCM. On CCM GK trunk sig digits are 5 so i should ring my extension on CCM 10001 but that is not happening.
anyone has any other ideas. I intially thought it may be due to codec mismatch but i verified that and infact used both g711 and g729 and it works great when CCM phone calls CME.
pls help !!
here is my GK main 10 debug
lab1(config-gk)#h323chan_dgram_send:Sent UDP msg. Bytes sent: 87 to 10.100.100.51:1719 fd=2
*Jul 17 19:40:28.905: RASLib::GW_RASSendRRQ: RRQ (seq# 1718) sent to 10.100.100.51
*Jul 17 19:40:28.905: RecvUDP_IPSockData successfully rcvd message of length 87 from 10.100.100.51:60383
*Jul 17 19:40:28.905: RRQ (seq# 1718) rcvd
*Jul 17 19:40:28.905: IPSOCK_RAS_sendto: msg length 68 from 10.100.100.51:1719 to 10.100.100.51: 60383
*Jul 17 19:40:28.905: RASLib::RASSendRCF: RCF (seq# 1718) sent to 10.100.100.51
*Jul 17 19:40:28.905: h323chan_chn_process_read_socket
*Jul 17 19:40:28.905: h323chan_chn_process_read_socket: fd=2 of type CONNECTED has data
*Jul 17 19:40:28.905: h323chan_chn_process_read_socket: h323chan accepted/connected fd=2
*Jul 17 19:40:28.905: h323chan_dgram_recvdata:rcvd from [10.100.100.51:1719] on fd=2
*Jul 17 19:40:28.905: RCF (seq# 1718) rcvd
*Jul 17 19:40:31.789: RecvUDP_IPSockData successfully rcvd message of length 185 from 172.181.12.5:58066
*Jul 17 19:40:31.789: ARQ (seq# 126) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen = 0
*Jul 17 19:40:31.789: IPSOCK_RAS_sendto: msg length 62 from 10.100.100.51:1719 to 172.181.12.5: 58066
*Jul 17 19:40:31.789: RASLib::RASSendACF: ACF (seq# 126) sent to 172.181.12.5
*Jul 17 19:40:41.141: RecvUDP_IPSockData successfully rcvd message of length 80 from 172.181.12.5:58066
*Jul 17 19:40:41.141: BRQ (seq# 127) rcvd
*Jul 17 19:40:41.141: IPSOCK_RAS_sendto: msg length 5 from 10.100.100.51:1719 to 172.181.12.5: 58066
*Jul 17 19:40:41.141: RASLib::RASSendBCF: BCF (seq# 127) sent to 172.181.12.5
*Jul 17 19:40:41.153: RecvUDP_IPSockData successfully rcvd message of length 94 from 172.181.12.5:58066
*Jul 17 19:40:41.153: DRQ (seq# 128) rcvdparse_rasusginfo_nonstd: Ras Usage Info Nonstd decode succeeded, remlen = 0
*Jul 17 19:40:41.153: IPSOCK_RAS_sendto: msg length 3 from 10.100.100.51:1719 to 172.181.12.5: 58066
*Jul 17 19:40:41.153: RASLib::RASSendDCF: DCF (seq# 128) sent to 172.181.12.5
guys..I feel little embarrase to tell you the resolution.
I have one router configured as MGCP/CME/GK and have sccp phone 4200 configured inside this. I was testing the setup using a diffrent router ( CME) registered to GK on this box and incidently i was using same extension in this CME for testing. But at anytime this skinnny phone was not registered as endpoint on GK or CME.
so if the endpt is not registed in GK the calls should still have routed to CCM..what do you think??