Multiple pattern matching weirdness

Hello,
I found a problem debugging a complex dialplan. I don’t know if it a desired behavior of it is a bug… In short, if an extension dialed is matched by more than one pattern, then the “execution row” is not reset. I simplified the dialplan to make an example for all of you.

context default {

    _59. => {
            NoOp(First Comment of 59 pattern);
            NoOp(Second Comment of 59 pattern);
    };

    _5. => {
            NoOp(First Comment of 5 pattern);
            NoOp(Second Comment of 5 pattern);
            NoOp(Third Comment of 5 pattern);
            NoOp(Fourth Comment of 5 pattern);
            NoOp(Fifth Comment of 5 pattern);
            NoOp(Sixth Comment of 5 pattern);
    };

};

If I dial 5955555555 I was expecting the First and Second comment for the 59 pattern (best matching pattern) and then from the First to Sixth comment for the 5 pattern. Instead I get only from the Third to Sixth comment of the 5 pattern.

-- Executing [5955555555@default:1] NoOp("SIP/572-jdtrix-00000010", "First Comment of 59 pattern") in new stack
-- Executing [5955555555@default:2] NoOp("SIP/572-jdtrix-00000010", "Second Comment of 59 pattern") in new stack
-- Executing [5955555555@default:3] NoOp("SIP/572-jdtrix-00000010", "Third Comment of 5 pattern") in new stack
-- Executing [5955555555@default:4] NoOp("SIP/572-jdtrix-00000010", "Fourth Comment of 5 pattern") in new stack
-- Executing [5955555555@default:5] NoOp("SIP/572-jdtrix-00000010", "Fifth Comment of 5 pattern") in new stack
-- Executing [5955555555@default:6] NoOp("SIP/572-jdtrix-00000010", "Sixth Comment of 5 pattern") in new stack

Is it the desired behavior or is it a bug? Is there a way to reset the “row” and make it restart from 1?

Thank you

Leandro

It’s correct behaviour. In the actual dialplan language, you could start the _5. rules at priority 3, but I don’t know if that capability is exposed in AEL.