call matching multiple dial peers with different COR's no blocked

Unanswered Question
Dec 10th, 2008

Good day,

I followed one of the Cisco sample COR configs for call blocking and ran into a strange problem with dial peers. I'll shorthand the relative items here, as I don't have my config handy.

I have:

dial-peer cor custom

name longdistance

name blocked

dial-peer cor list user

member longdistance

dial-peer cor list callblocked

member blocked

dial-peer cor list callld

member longdistance

dial-peer 1

cor outgoing callld

destination-pattern 91..........

preference 10

dial-peer 2

cor outgoing callblocked

destination-pattern 91900.......

preference 1

ephone-dn 1

cor incoming user

The problem: When I dial a 1900 number, it matches both dial peers because 2 is a subset of 1. COR authorization fails on dial-peer 2, but the call goes through on dial-peer 1 because COR authorization succeeds(verfied with debug voip ccapi inout).

I thought that the system used most digits matched for dial-peer selection, or preference if that is supplied. I have given the blocking DP a lower preference to try and force its use. Is there a way to stop the call from falling back to the less preferred dial peer when COR authorization fails? I also tried to huntstop on DP2, but that had no effect.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
allan.thomas Thu, 12/11/2008 - 03:48

Hi Graham, firstly can you clarify your requirement? The issue you have is that the DPs overlap, and are associated with the same custom member longdistance.

Are you try to restrict only specific long distance called numbers to 1900? Or do you require restricting all long distance numbers?

If you are attempting to restrict all Long Distance calls for ephone-dn1 then there is not need to configure dial-peer 2.

Just ensure that the user corlist does not have the member longdistance, and then no outgoing DP will be matched.

On the other hand, if you are restricting only 1900 calls, then you should configure the destination-pattern on DP 1 to be more explicit such as 91[1-8]00....... and assign a different corlist member and use DP 2 specifically for outgoing calls to 1900.

dial-peer cor custom

name 1900LongDistance

name OtherLongDistance

!

dial-peer cor list 1900LongDistance

member 1900LongDistance

!

dial-peer cor list OtherLongDistance

member OtherLongDistance

!

dial-peer cor list Advanced

member OtherLongDistance

member 1900LongDistance

!

dial-peer cor list Standard

member OtherLongDistance

!

dial-peer 1

cor outgoing OtherLongDistance

destination-pattern 91[1-8]00.......

!

dial-peer 2

cor outgoing 1900LongDistance

destination-pattern 91900.......

!

ephone-dn 1

cor incoming Standard

With this configuration ephone-dn1 will be able to call other LongDistance numbers but not 1900. For other ephone-dns you can assign the Advance corlist which will allow them to call both.

Hope this helps.

Allan.

ghtracey08 Thu, 12/11/2008 - 21:45

Hi Allan,

Thanks for the response. To clarify, I am trying to block 1-900 dialing. Your example works, but will also block any area code beginnng with a 9 as well. A call to Nova Scotia (Area code 902) would not match DP1 and would not have permission for DP2.

The correct two destination patterns would be:

DP1: 91[2-9].........

DP2: 91900.......

However, when you use these two patterns, a 1-900 call matches both (as I mentioned before, 2 is a subset of 1) and the dial peers form a huntgroup. When DP2 fails to authorize due to the cor requirement, the call falls back to DP1, regardless of preference or huntstop commands. In effect, if you allow long distance dialling, you are allowing 1900 dialing. The only way to block this is through an after-hours block or called digit translation to (/19000/ // - this is what Cisco Configuration Professional does). Using either of those two prevents me from allowing a class of users the ability dial 1900 numbers if they are required. This does not seem like ideal behavior.

I've tried many variations on the patterns and cannot find any that prevent the fallback to a less preferred match. I thought that if a call matched to dialpeers the one with the most digits matched would be the one used. Apparently its not the *only* one used though.

Any other suggestions are welcome. For now I am just going to use digit translation to remove 1900 and 1976.

Regards,

Graham

edit: I suppose I could try 3 peers

DP1: 91[2-8].........

DP2: 9190[1-9].......

DP3: 919[1-9]........

DP4: 91900.......

and give cor OtherLongDistance to 1, 2 and 3, cor 1900LongDistance to 4. A little finicky, but it would work. Of course 1976 will require even more rules than that to block.

Seems like a lot of work arounds for something that was supposedly builtin. :)

Nicholas Matthews Fri, 12/12/2008 - 13:07

You should be aware that dial-peer matching on CME is not the same as CUCM.

CME will match dial-peers as soon as there is a match. In CUCM, the more specific dial peer match.

For example:

destination-pattern 9

This will match any number that starts with a 9, as soon as it is dialed. Even if there is a destination-pattern 9........

You will want to make sure that none of your dial peers share the same prefix / complete match.

ghtracey08 Fri, 12/12/2008 - 13:10

Good afternoon,

Thanks for that, at least now I know that I was mistaken in what I was expecting.

Actions

This Discussion