Hold on, this could be a bumpy ride

These call barring rules can be very tricky. I have looked at them before:
http://www.obitalk.com/forum/index.php?topic=4799.msg31198#msg31198Let's look at this particular case. In theory this should work for an outgoing DigitMap:
(!1?6065559999|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
In practice it blocks 6065559999, but does not block 16065559999. This is because rule 1xxxxxxxxxx provides a better match for 16065559999 than the rule !1?6065559999. Looks crazy, but that's just how the "precedence rules" seem to work – this is not documented anywhere that I can find.
This digitMap does block both numbers:
(!16065559999|!6065559999|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
For an InboundCallRoute this, as suggested by Shale, should work:
{(1?6065559999):},
This is because there are unlikely to be other rules that might take precedence.
Confused? A lot of us are a lot of the time