News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Call Barring

Started by ianobi, December 15, 2012, 07:29:14 AM

Previous topic - Next topic

ianobi

Following a recent post where call barring was an issue, I decided to set up a series of tests. I used a simple Line Port DigitMap and a simple User Defined DigitMap as shown below. On each test I dialled 1234 to see if the blocking rule !1234 was working and 1235 to see if the xx. rule was also working.

Here are the results:

ste = (!1234)

(!1234|xxxxxxxS4|1xxxxxxxxxx|xx.) 1234 blocked, 1235 allowed.

((Mste)|xxxxxxxS4|1xxxxxxxxxx|xx.) 1234 allowed, 1235 allowed.

((Mste)|!1234|xxxxxxxS4|1xxxxxxxxxx|xx.) 1234 blocked, 1235 allowed.


ste = (!1234|xx.)

((Mste)|xxxxxxxS4|1xxxxxxxxxx) 1234 blocked, 1235 allowed.

These tests appear to show that the host DigitMap is processed first, followed by the embedded DigtMap. If your blocking rule is in ste in this scenario:

ste = (!1234)
((Mste)|xxxxxxxS4|1xxxxxxxxxx|xx.) 1234 allowed, 1235 allowed.

The xx. rule in the host DigitMap will allow 1234 before the blocking rule !1234 in the embedded DigitMap has a chance to block it.

This could have all sorts of implications for how DigitMaps work, not just regarding call barring.

Edit: Further testing reveals that this only applies to call barring rules. Odd and undocumented  ::)