Cisco 4331 does not route DID calls according to translation rule

[kilias]

Dear All

Recently we have migrated our company's voice gateway from 2911 to 4331 ISR. After dealing with

the new configuration parameters regarding the PVDMs and their position on the router (NIM card or motherboard) depending on the task required, we got it to work. However, the DID function behaves

weirdly! Despite the fact tha there is the following translation rule in the gateway's configuration , the only extensions that will not work are the 333 and 331. The provider is sending 3 digits through the PRI and only when those digits are 333 or 331 are not matched with any dial peer.!

The IOS version of the router is Cisco IOS XE Software, Version 03.16.04b.S and the dial-peer 

shown points to the CUCM. Has anyone seen any similar behaviour??

Please advise.

voice translation-rule 2
rule 1 /1031/ /350/
rule 2 /^.*\(31[0-6]$\)/ /\1/
rule 3 /^.*\(32[0-5]$\)/ /\1/
rule 4 /^.*\(33[0-5]$\)/ /\1/
rule 5 /^.*\(34[8-9]$\)/ /\1/
rule 6 /^.*\(36[0-9]$\)/ /502/
rule 7 /^.*396$/ /361/
rule 8 /^.*397$/ /351/
rule 9 /^.*398$/ /482/
rule 10 /^.*399$/ /360/voice translation-rule 2
rule 1 /1031/ /350/
rule 2 /^.*\(31[0-6]$\)/ /\1/
rule 3 /^.*\(32[0-5]$\)/ /\1/
rule 4 /^.*\(33[0-5]$\)/ /\1/
rule 5 /^.*\(34[8-9]$\)/ /\1/
rule 6 /^.*\(36[0-9]$\)/ /502/
rule 7 /^.*396$/ /361/
rule 8 /^.*397$/ /351/
rule 9 /^.*398$/ /482/
rule 10 /^.*399$/ /360/

dial-peer voice 301 voip
destination-pattern [134]..
session protocol sipv2
session target ipv4:10.1.1.250
codec g711alaw
no vad

Thank you in advance

Dimitrios

[Abhay Singh Reyal]

Kindly collect these 4 debugs and make a test call.
debug isdq931
debug voip ccapi inout
debug voice translation-rule
debug ccsip messages
Share the Show run and debugs , post them as an attachment in the thread. Also provide calling and called number details.

Regards
Abhay

[kilias]

Hello Abhay

I am attaching the debug outputs and the configuration of the gateway.

calling number XXXXXXX152, called number 333 (thats the number sent by the provider for the DID)

Thank you in advance

Regards

Dimitrios

[Abhay Singh Reyal]

As per the debugs, below set up comes from the provider with Calling Party Number i = 0x0180, 'XXXXXXX152' and Called Party Number i = 0x81, '333'
+++++++
Sep 6 08:35:54.431: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x17FE
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18396
Preferred, Channel 22
Calling Party Number i = 0x0180, 'XXXXXXX152'
Plan:ISDN, Type:Unknown
Called Party Number i = 0x81, '333'
Plan:ISDN, Type:Unknown

It matched below below translation
+++++++
Sep 6 08:35:54.431: //-1/xxxxxxxxxxxx/RXRULE/regxrule_profile_match_internal: Matched with rule 4 in ruleset 2
Sep 6 08:35:54.431: //-1/xxxxxxxxxxxx/RXRULE/sed_subst: Successful substitution; pattern=333 matchPattern=^.*(33[0-5]$) replacePattern=\1 replaced pattern=

This is the rule being used
+++++++
rule 4 /^.*\(33[0-5]$\)/ /\1/

Can you try below things one by one:-

1- Remove the dial-peer and reconfigure it.
dial-peer voice 301 voip

2- As the called no. which is coming from provider is already an exact match that you want to translate the number to, try removing from Rule 2
rule 4 /^.*\(33[0-5]$\)/ /\1/

3- For the testing purpose create a dial-peer with an exact match for the called number and see if that works or not.

If still there is an issue, would request you to provide a working debugs [All as mentioned earlier] for a call with similar called type number.

HTH
Regards
Abhay

[kilias]

Hello Abhay

I have removed the 301 dial-peer, reconfigure it, add a new one with an exact match and the 

DID for the 333 worked OK. Then I removed the dial-peer added (for the exact match)

and the 333 DID continue to work! However the 331 DID still does not work although I

followed the exact procedure as the 333 one. I have tried to change the rules under

translation rule 2 from  

rule 3 /^.*\(32[0-5]$\)/ /\1/ to rule 3 /\(32[0-5]\)/ /\1/

but same behaviour. 

I am attaching the debugs taken for 333 DID (successfull) and 331 (failed).

What I have noticed is although when 333 call comes in , the rule rule 4 /\(33[0-5]\)/ /\1/

is matched, when 331 DID call comes in , the router is matching to the rule 2 /\(31[0-6]\)/ /\1/ rule.

This is not right...

Any suggestions?

Thank you in advance

[Ayodeji Okanlawon]

Kilias,

May I ask why you atcully need this rule. It doesnt seem to be doing anything. The call is delievered using the 3 digit numbers, why not route the call like it is.

Yes you are correct that the wrong rule is been matched but since the rule is not doing anything the destination-pattern is still the same as 331..

Sep  6 13:13:23.566: //-1/FB56DEEF8009/RXRULE/sed_subst: Successful substitution; pattern=331 matchPattern=(31[0-6]) replacePattern=\1 replaced pattern=3

But I can see the gateway is disconnecting the call with (un allocated number reason)

Sep  6 13:13:23.566: //13/FB56DEEF8009/CCAPI/ccCallDisconnect:
   Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

I will suggest that you remove all of this redundant xlation rules. Always best to keep things simple. Second you may want to reload the router as this behaviour is wrong..

[Abhay Singh Reyal]

I agree to Ayodeji, there is no need of redundant rules.

Regards
Abhay

[kilias]

Hello 

Thank you both for the help.

The incoming rules are used in order to route calls to the AA/IVR when a DID number is used that does not correspond to an internal extension. I have reloaded the gateway several times but it does no seem to be fixing any problem. What amazes me is that that same configuration (as far as the xtranslation rules is conserned) was working fine on my previous gateway, a 2911.

Is there a chance that something is wrong with the IOS on this 4331?

Regards

Dimitrios

[Ayodeji Okanlawon]

What happens if you delete the xaltion rule..matched 31[0-6]) replacePattern=\1

The other thing to worry about is actual not this rule since it is not doing anything, the issue is that the destination-pattern 331 is not matching any outbound dial-peer..

So lets try this, delete the xaltion rule and test again..

Send the output of

debug voip ccapi inout 

debug voice translation

debug ccsip message

[kilias]

Hello Ayodeji

It actually does. This rule matches DIDs 310 to 316 which are working fine, so I cannot delete
this one.

Regards
Dimitrios

[Ayodeji Okanlawon]

But the voice xlation rule is not doing anything at the moment. So I dont see any impact for a few minutes for you to test..Your provider sends you a 3 digit number, hence why I said the rule does not do anything

[kilias]

Hello All

The solution to the problem was to add the ^ wildcard in front of every rule

voice translation-rule 2
rule 1 /1031/ /350/
rule 2 /^\(31[0-6]\)/ /\1/
rule 3 /^\(32[0-5]\)/ /\1/
rule 4 /^\(33[0-5]\)/ /\1/
rule 5 /^\(34[8-9]\)/ /\1/
rule 6 /^\(36[0-9]\)/ /502/
rule 7 /396/ /361/
rule 8 /397/ /351/
rule 9 /398/ /482/
rule 10 /399/ /360/
rule 11 /^.*$/ /350/

then 331 was matched by the rule 4 and not rule 2.

Thank you all for the solutions provides

Regards 

Dimitrios