12-10-2008 11:18 PM - edited 03-15-2019 03:01 PM
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.
12-11-2008 03:48 AM
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.
12-11-2008 09:45 PM
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. :)
12-12-2008 01:07 PM
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.
12-12-2008 01:10 PM
Good afternoon,
Thanks for that, at least now I know that I was mistaken in what I was expecting.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide