dial-peer matching not working as expected (but functioning nonetheless)

[pkluss]

I've always had a suspicion that my dial-peers are not functioning like I think they should, but haven't ever been able to prove it. Obviously this is somewhat of a minor issue since we're able to place/take calls without any serious problems, but when I look at the log it seems as though there is a lot of unnecessary "matching" going on. Another issue is that I cannot block certain incoming numbers as I'd like. I created the rules below:

voice translation-rule 6

rule 1 reject /^1234567890/

voice translation-profile BLOCK

translate calling 6

dial-peer voice 1011 voip

translation-profile incoming BLOCK

translation-profile outgoing OUT

destination-pattern 9(1?)[2-9].........

voice-class codec 1

session protocol sipv2

session target dns:chcg.global.voip.mcleodusa.net

incoming called-number .

dtmf-relay rtp-nte

but the incoming translation profile is ignored completely. The call gets through without a hitch. I will attach a copy of my debug log and see if that makes sense to anyone. It does seem to be picking the correct dial-peer (probably based on the "incoming called-number ." line), but it doesn't reject the number. Strangely, if I change the rule to rewrite the incoming number to a blank string, this works. It blanks the caller ID on my end. So I know that the translation-profile is working to some degree.

Let me know what you're thinking. I can provide any extra logs necessary.

Thanks.

pk

[paolo bevilacqua]

Hi, is the incoming a SIP circuit? chances are, reject has been tested/supported for ISDN only.

[pkluss]

It is indeed a SIP circuit. I never thought about that being the problem. Perhaps I'll have to open up a TAC case and see I can verify that. If that's the case, it saves me lots of troubleshooting time :).

Thanks.

[paolo bevilacqua]

You can use COR, or a "prefix" technique, to match an incoming DP with "answer-address" then route to a non-existent destination, or disconnect script, like one that I wrote:

http://pbevila.fastmail.fm/public/disconnect.tcl

[pkluss]

I opened a TAC case and here's what I found. The issue was with how the translation profile was being applied in the dial-peer. There is a specific call-block command for the purpose of rejections.

So now my config file is as follows:

------------------------------------

!

voice translation-rule 6

rule 1 reject /^3127266700/

rule 2 reject /^2817909977/

!

voice translation-profile BLOCK

translate calling 6

!

dial-peer voice 1011 voip

translation-profile outgoing OUT

call-block translation-profile incoming BLOCK

call-block disconnect-cause incoming user-busy

destination-pattern 9(1?)[2-9].........

voice-class codec 1

session protocol sipv2

session target dns:chcg.global.voip.mcleodusa.net

incoming called-number .

dtmf-relay rtp-nte

!

------------------------------------

You can choose how you want the call to be rejected in the second call-block command. I chose user-busy because I'd like the caller to waste as much time as possible reaching us in the future :).

For more info: http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7f17.html#wp1212098

Hope this helps someone.

pk

[paolo bevilacqua]

Very good info, thanks!

[amorales]

Im having almost the same of problem on ASA5400xm IOS 12.4.(9)T6 but with the translation-profile outgoing.

Here is my config:

!voice translation-rule 10

rule 1 /^520232\(16[4-9].\)/ /\1/

rule 2 /^520232\(18[0-5].*\)/ /\1/

rule 3 /^520281\(54[0-3].\)/ /\1/

rule 4 /^520761\(60[4-9].\)/ /\1/

rule 5 /^520377\(59[6-9].\)/ /\1/

rule 6 /^520281\(39[0-5].\)/ /\1/

rule 7 /^505525\(47[4-9].\)/ /\1/

rule 8 /^505525\(49[0-3].\)/ /\1/

!

voice translation-profile CYRA

translate called 10

!

dial-peer voice 50001 voip

description =====================> VOIP TO TUCCCMSUB01

translation-profile outgoing CYRA

preference 3

service session

destination-pattern 52023218[0-5].

voice-class codec 1

session target dns:TUCCCMSUB01

dtmf-relay cisco-rtp h245-signal h245-alphanumeric

ip qos dscp cs3 signaling

no vad

!