Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

CCME 4.0 matches number too early!

Hello,

once again I have a problem with my CCME 4.0.

It happens quite frequently that someone from the outside calls a extension within our organisation. But the CCME bagins matching too early, before all digits are received. One or sometimes even two digits are left out.

Example:

Caller dials 12345-234 with 12345 being the main number and 234 being the extension. Now the CCM begins matching at 12345-23 already. The voice rule for incoming calls now cuts all but the last three digits and tries to match that to an extension. But since there is a digit missing, the CCM tries to match "523" instead of "234". And of course the extension "523" does not exist. So the caller gets a "number not assigned".

This is quite annoying! How can I force the CCME to wait until all digits are received from the telephony service provider?

Regards,

Eyad Tayeb.

12 REPLIES
Blue

Re: CCME 4.0 matches number too early!

you could use the 'forward-digits all' command on the dialPeer(s) required for the call legs involved.

see this link for more info:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7f6d.html#wp1064204

this will ensure all digits provided to the dialPeer are forwarded for voice calls.

New Member

Re: CCME 4.0 matches number too early!

Thanks, I will try that. I will report back with the result.

Regards,

Eyad.

New Member

Re: CCME 4.0 matches number too early!

Thanks for the info.

Unfortunately, that did not seem to work.

Any other ideas on this problem?

Regards,

Eyad.

New Member

Re: CCME 4.0 matches number too early!

Hi if the call is entering to the gateway through a pots dial-peer you can use the command "direct inward dial" - Document ID: 14072

Good luck

New Member

Re: CCME 4.0 matches number too early!

The CME is not connected to a US phone system, so no DID lines. Or is there a misunderstanding?

Regards,

Eyad.

New Member

Re: CCME 4.0 matches number too early!

Do you receive the calls through a e1, t1 or fxo port?

If that is true when a call enters to the gateway you have an incoming dial-peer, and you can set the comand direct inward dial under that dial-peer, then when the gateway receives an incoming call it will wait until all the digits were received

Good luck

New Member

Re: CCME 4.0 matches number too early!

Many apologies for my dumbness today.

The calls are received through 6 BRI ports that share a common number (A specialty of German Telecom). A incoming call is assigned to a free port by the telephony provider. Therefore I have 6 dial-peer pots for incoming calls.

these 6 dial-peers contain:

description [blah]

incoming caled number.

direct-inward-dial

port X/Y/Z

What has to be modified here?

Regards,

Eyad.

New Member

Re: CCME 4.0 matches number too early!

Can you put the output of an incoming call with "debug isdn q931" activated?

In that output we can check the called number you receibed from the telco provider.

New Member

Re: CCME 4.0 matches number too early!

The requested debug (of a succesful call):

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960443: <009><009>Component = Invoke component

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960444: <009><009><009>Invoke Id = 22962

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960445: <009><009><009>Operation = Diversion Leg2

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960446: <009>Progress Ind i = 0x8183 - Origination address is non-ISDN

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960447: <009>Calling Party Number i = 0x2181, '3462211214'

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960448: <009><009>Plan:

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960449: ISDN, Type:National

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960450: <009>Called Party Number i = 0xC1, '9209299'

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960451: <009><009>Plan:ISDN, Type:Subscriber(local)

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960452: 533213: Sep 6 15:27:45.121: ISDN BR0/1/1 EVENT: process_rxstate: ces/callid 1/0x192A calltype 2 HOST_INCOMING_CALL

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960453: 533214: Sep 6 15:27:45.121: ISDN BR0/1/1 EVENT: host_incoming_call: call_id 0x192A, Guid = 50AAF3E5965D bchan 0

10.10.1.251 960462: 533223: Sep 6 15:27:45.125: ISDN BR0/1/1 Q931: extract_redirect_orig_called_ie: IE type redirecting num none reason 15 cnt 1 plan -1 type 0 pres 1

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960463: 533224: Sep 6 15:27:45.125: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960464: Calling Number=3462211214, Called Number=9209299, Voice-Interface=0x46AA9C28,

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960486: 2: Dial-peer Tag=299

2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960487: 533232: Sep 6 15:27:45.133: //-1/50AAF3E5965D/DPM/dpMatchPeersCore:

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960489: 533233: Sep 6 15:27:45.133: //-1/50AAF3E5965D/DPM/dpMatchPeersCore:

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960490: Match Rule=DP_MATCH_DEST; Called Number=299

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960491: 533234: Sep 6 15:27:45.133: //-1/50AAF3E5965D/DPM/dpMatchPeersCore:

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960492: Result=Success(0) after DP_MATCH_DEST

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960494: Result=SUCCESS(0)

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960495: List of Matched Outgoing Dial-peer(s):

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960496: 1: Dial-peer Tag=20003

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960497: 2: Dial-peer Tag=299

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960498: 533236: Sep 6 15:27:45.137: ISDN BR0/1/1 Q931: TX -> CALL_PROC pd = 8 callref = 0x81

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960499: <009>Channel ID i = 0x89

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960500: <009><009>Exclusive, B1

2006-09-06 13:27:37 UTC Local7.Debug 10.10.1.251 960501: 533237: Sep 6 15:27:45.153: ISDN BR0/1/1 Q931: TX -> ALERTING pd = 8 callref = 0x81

2006-09-06 13:27:43 UTC Local7.Debug 10.10.1.251 960502: 533238: Sep 6 15:27:51.825: ISDN BR0/1/1 Q931: TX -> CONNECT pd = 8 callref = 0x81

2006-09-06 13:27:43 UTC Local7.Debug 10.10.1.251 960503: <009>Channel ID i = 0x89

2006-09-06 13:27:43 UTC Local7.Debug 10.10.1.251 960504: <009><009>Exclusive, B1

2006-09-06 13:27:43 UTC Local7.Debug 10.10.1.251 960505: 533239: Sep 6 15:27:51.929: ISDN BR0/1/1 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01

2006-09-06 13:27:43 UTC Local7.Debug 10.10.1.251 960506: 533240: Sep 6 15:27:51.929: ISDN BR0/1/1 EVENT: process_rxstate: ces/callid 1/0x192A calltype 2 HOST_CONNECT

2006-09-06 13:27:44 UTC Local7.Info 10.10.1.251 960507: 533241: Sep 6 15:27:51.933: %ISDN-6-CONNECT: Interface BRI0/1/1:1 is now connected to 3462211214

New Member

Re: CCME 4.0 matches number too early!

Hi, you are receiving only 7 digits on the call setup message from the telco provider: "2006-09-06 13:27:36 UTC Local7.Debug 10.10.1.251 960450: <009>Called Party Number i = 0xC1, '9209299'" the callmanager will try to macth the destination dial-peer or to make the tranformations using 7 numbers.

New Member

Re: CCME 4.0 matches number too early!

Ok, the router receives 7 digits from the telco normally. These 7 digits then get processed by a vooice translation rule that cuts the first 4 digits of the number. the last three digits are the actual extensions that exist in the location.

But sometimes the telco does not send all 7 digits en block. Some times they send 5 and the last 2 some milliseconds later. But the CCME works with the 5 digits already.

Can I force the CCME to wait with the number processing until it has received 7 digits?

New Member

Re: CCME 4.0 matches number too early!

Nobody?

Can I force the CCME to wait with the number processing until it has received 7 digits?

224
Views
0
Helpful
12
Replies
CreatePlease login to create content