OBiTALK Community

General Support => Installation and Set-Up (Devices) => Topic started by: ianobi on December 15, 2012, 07:29:14 AM

Title: Call Barring
Post by: ianobi on December 15, 2012, 07:29:14 AM
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  ::)