John Todd
2003-Jun-25 18:05 UTC
[Asterisk-Users] Pattern matching: least-to-most specific PITA
My synapses are rather fried after a long few days of debugging other problems, so perhaps I'm being lazy in sending this to the general list, but I can't think straight about it. Forgive me if there is an overly obvious solution to this. I have a list of phone numbers that are SIP extensions. I'd like to dial them via SIP if ${EXTEN} is equal to one of those numbers. If ${EXTEN} is not equal to one of those numbers, I'd like to send the call out to a PRI group, regardless of dialed sequence length or pattern. It seems I cannot do this with *'s pattern matching, due to the order in which extensions are parsed, which seems to be least-specific to most-specific. This causes all kinds of headaches when trying to use wildcards, since wildcards are super-least-specific. My desire would be to have the more specific matches done first, so that if ${EXTEN} would be matched in an order that makes sense. I understand why matching goes from least-to-most specific for analog equipment, but it makes certain tasks impossible from a dialplan point of view when I have the full number and I'm not waiting on a user to finish typing the digits. If presented with 12123669751 I would expect the match to happen and the SIP extension to be dialed. It doesn't. It dials the Zap extension. [foo] ; exten => _1212366975X,1,Dial(SIP/${EXTEN}) exten => _181772721[8-9]X,1,Dial(SIP/${EXTEN}) exten => _191481287[4-7]X,1,Dial(SIP/${EXTEN}) exten => _141550926[0-2]X,1,Dial(SIP/${EXTEN}) ; exten => _.,1,Dial(Zap/g1/${EXTEN}) ; How do I invert this match examination to make it go most- to least-specific execution? JT
Martin Pycko
2003-Jun-25 19:09 UTC
[Asterisk-Users] Pattern matching: least-to-most specific PITA
I think that if you put exten => _X.,1,DIal,Zap it'll improve the matching dramatically Martin On Wed, 25 Jun 2003, John Todd wrote:> > My synapses are rather fried after a long few days of debugging other > problems, so perhaps I'm being lazy in sending this to the general > list, but I can't think straight about it. Forgive me if there is an > overly obvious solution to this. > > I have a list of phone numbers that are SIP extensions. I'd like to > dial them via SIP if ${EXTEN} is equal to one of those numbers. If > ${EXTEN} is not equal to one of those numbers, I'd like to send the > call out to a PRI group, regardless of dialed sequence length or > pattern. > > It seems I cannot do this with *'s pattern matching, due to the order > in which extensions are parsed, which seems to be least-specific to > most-specific. This causes all kinds of headaches when trying to use > wildcards, since wildcards are super-least-specific. > > My desire would be to have the more specific matches done first, so > that if ${EXTEN} would be matched in an order that makes sense. I > understand why matching goes from least-to-most specific for analog > equipment, but it makes certain tasks impossible from a dialplan > point of view when I have the full number and I'm not waiting on a > user to finish typing the digits. > > If presented with 12123669751 I would expect the match to happen and > the SIP extension to be dialed. It doesn't. It dials the Zap > extension. > > [foo] > ; > exten => _1212366975X,1,Dial(SIP/${EXTEN}) > exten => _181772721[8-9]X,1,Dial(SIP/${EXTEN}) > exten => _191481287[4-7]X,1,Dial(SIP/${EXTEN}) > exten => _141550926[0-2]X,1,Dial(SIP/${EXTEN}) > ; > exten => _.,1,Dial(Zap/g1/${EXTEN}) > ; > > > How do I invert this match examination to make it go most- to > least-specific execution? > > JT > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users >
Apparently Analagous Threads
- Pattern matching rules for least cost routing
- Debugging Samba is a total PITA and this needs to improve
- Debugging Samba is a total PITA and this needs to improve
- Debugging Samba is a total PITA and this needs to improve
- Debugging Samba is a total PITA and this needs to improve