Call failed when user dial 003, and user heard busy tone immediately

[kenji8462]

Dears

I have a voice gateway problem.

We have a voice gateway connect to PBX using FXS port, and the phone is connected to the PBX.

The voice gateway have two SIP trunk to CUCM Pub & Sub, and there is a MGCP gateway that managed by the CUCM.

The MGCP gateway connect to a PSTN line using T1/E1 port.

So if the user pick up the phone and call 009XXXXXXXX(09XXXXXXXX is taiwan cell phone number, and the first 0 is tell the CUCM to make a outbound call to PSTN), the PBX will transit the dial number to voice gateway, the voice gateway see the called number , and match a outbound dial-peer .T, then send the call to CUCM.

CUCM config a route pattern 0.!, and route the pattern to the MGCP gateway, then the MGCP gateway will transit the call to PSTN.

It worked fine.

Also when the user call 007XXXXXXX(07 is taiwan area code, and the first 0 is tell the CUCM to make a outbound call to PSTN), the call routing path is the same, and it also work fine.

But when the user call 003XXXXXXX(03 is taiwan area code,  and the first 0 is tell the CUCMto make a outbound call to PSTN), but there is a problem.

When the user call 003, then the phone has busy tone immediately, and the call failed.

We try 003, 004, 005, 006, and all failed, but 007, 008 is fine

We also think maybe there is something wrong about the PBX, so we direct connect a phone to the voice gateway FXS port.

But it still can not work fine.

I using debug command and I found that when the user dials 003, the phone immediately sends out the number 003 without waiting for the entire number to be dialed.

I've check the voice gateway config, but I can not see and config mistake about this.

I upload the config, and topology.

Can anyone help to check what happen

[Leo Laohoo]

Dial plan

[Maren Mahoney]

You write that dialing 003 causes CUCM to send the call immediately to the gateway, which sends it out the .T dial-peer and fails. So the issue would be within CUCM (why is it sending the 003 calls immediately when it does not send 009, 008, or 007).

This is undoubtedly a dialplan issue. The first thing I would do is use the Route Plan Report and search for patterns that begin with 00 to see what is configured in CUCM that might be interfering. Also a search for patterns that begin with just 0. Is there another pattern that is matching before the 0.! pattern?

Also, try the Dialed Number Analyzer (in Serviceability) and have a "Phone" dial the pattern "003" to see what CUCM is doing with it.

If neither of these methods shows you what is happening, you may need to dig around in the trace files to view the DigitAnalysis portion looking for the pattern that CUCM is using for these calls.

Let us know what you find and what we can do to help.

Maren

[kenji8462]

Dear Maren

Thanks for you reply.

But in my unstanding, the voice gateway is sip gateway, and in the voice port, I config the timeout interdigit for 3 second.

I think the router should wait for 3 second after the user dial all the number, and then send the call to CUCM.

But in my situation, the call send to CUCM immediately after the third number 3 dialed.

So I think this is the voice gateway config problem.

Or is there something I have misunderstood

thanks

[Nithin Eluvathingal]

Share with us the Failed call Logs. 

2.12.0.0

[Nithin Eluvathingal]

On your post, you mentioned: "I used the debug command and found that when the user dials 003, the phone immediately sends the number 003 without waiting for the full number to be dialed."
Could you share the debug logs you collected for this failed call?
My understanding is that the phone is connected to the PBX, and when 003 is dialed, the call is immediately routed to the next hop, which is the voice gateway. Why does the PBX shows this behavior and not allow the user to enter the full digits? Have you consulted with the PBX vendor regarding this issue and verified the PBX configurations?

2.12.0.0

[kenji8462]

Because We also think maybe is the PBX problem, so we try to direct connect the phone to the voice gateway FXS port and bypass the PBX.

But we still have problem, so we think maybe is not the PBX problem

[Nithin Eluvathingal]

Would you able to share with us the Logs ??

2.12.0.0

[Roger Kallberg]

Something does not add up in your shared configuration. In it you have configuration that IMO should be impossible to have. Copied from your shared file.

dial-peer voice 900 pots
 preference 4
 destination-pattern 39520
 session target ipv4:172.16.1.1
 dtmf-relay rtp-nte
 no vad

The last three lines should not be possible to put in on a POTS dial peer as those are VOIP options. When I test in one of our test gateways I get this when trying to put in those commands.

selurt-cube-03(config-dial-peer)#session target ipv4:172.16.1.1
Incorrect format for Session Target
Must be of the form     ^loopback:(compressed|uncompressed)$

selurt-cube-03(config-dial-peer)#dtmf?
% Unrecognized command

selurt-cube-03(config-dial-peer)#no vad ?
% Unrecognized command

Not directly related to your question as such, more an observation on something that stood out to me.

As @Nithin Eluvathingal wrote, if you could share the captured debug output we might be able to help you further on this. 

[kenji8462]

Here is the debug log and right config

thanks

[Roger Kallberg]

Can you please get a clean output that only contains the calls. As it is now there are debug output and show parts or whole config intermixed in each other and that makes it quite hard to follow what's happening in your gateway. Please collect the output for both a working and a failed call scenarios so that we can compare the two. When you do please provide the called and calling numbers plus the time of the call so we can identify it in the logs.

One observation done is that there are never any SIP dialog that takes place in your shared debug output. That in itself would indicate that something isn't alright in your configuration.

[Nithin Eluvathingal]

I found this in the logs: the gateway waited for additional digits, but an interdigit timeout occurred, causing "003" to be considered the dialed number. This was processed through dial-peers 998 and 999, which is the expected path.

Could you share the logs of a working call for comparison?

I believe these logs are from a phone connected to the PBX. Please capture logs with the phone connected to the PBX and dialing a working number so we can compare them.

One thing I'm puzzled about is why the logs show "003T" as the called number.

Aug  5 16:33:09.873 Tokyo: //-1/430853E98077/DPM/dpMatchPeersMoreArg:

   Result=MORE_DIGITS_NEEDED(1)

Branch951-3b#

Aug  5 16:33:12.874 Tokyo: //62782/430853E98077/CCAPI/cc_handle_inter_digit_timer:

   Generate inter-digit timeout CC_EV_CALL_DIGIT_END event

Aug  5 16:33:12.874 Tokyo: //62782/430853E98077/CCAPI/cc_handle_inter_digit_timer:

   Generate inter-digit timeout CC_EV_CALL_DIGIT_END event

Aug  5 16:33:12.874 Tokyo: //-1/430853E98077/DPM/dpMatchPeersCore:

   Calling Number=, Called Number=003T, Peer Info Type=DIALPEER_INFO_SPEECH

Aug  5 16:33:12.874 Tokyo: //-1/430853E98077/DPM/dpMatchPeersCore:

   Match Rule=DP_MATCH_DEST; Called Number=003T

Aug  5 16:33:12.874 Tokyo: //-1/430853E98077/DPM/dpMatchPeersCore:

   Result=Success(0) after DP_MATCH_DEST

Aug  5 16:33:12.874 Tokyo: //-1/430853E98077/DPM/dpMatchSafModulePlugin:

   dialstring=003T, saf_enabled=1, saf_dndb_lookup=0, dp_result=0

Aug  5 16:33:12.874 Tokyo: //-1/430853E98077/DPM/dpMatchPeersMoreArg:

   Result=SUCCESS(0) 

   List of Matched Outgoing Dial-peer(s): 

     1: Dial-peer Tag=998 

     2: Dial-peer Tag=999

2.12.0.0