IRC log for #asterisk-bugs on 20120914

01:04.37*** join/#asterisk-bugs newtonr (~newtonr@64.34.219.47)
01:04.37*** mode/#asterisk-bugs [+o newtonr] by ChanServ
01:07.19*** join/#asterisk-bugs zerohalo (~zerohalo@74.61.196.236)
01:13.12*** join/#asterisk-bugs zerohalo (~zerohalo@74.61.196.236)
01:30.00*** join/#asterisk-bugs mjordan (~mjordan@user-69-1-6-49.knology.net)
01:30.01*** mode/#asterisk-bugs [+o mjordan] by ChanServ
02:16.38*** join/#asterisk-bugs mjordan (~mjordan@user-69-1-6-49.knology.net)
02:16.39*** mode/#asterisk-bugs [+o mjordan] by ChanServ
05:52.20*** join/#asterisk-bugs seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright)
05:52.21*** mode/#asterisk-bugs [+o seanbright] by ChanServ
06:08.42*** join/#asterisk-bugs vfabi (~fabi@host-static-93-116-255-140.moldtelecom.md)
09:08.33*** join/#asterisk-bugs elguero (~miguel323@2001:470:1f06:12c4::2)
09:08.48*** join/#asterisk-bugs vfabi (~fabi@host-static-93-116-255-140.moldtelecom.md)
13:00.11*** join/#asterisk-bugs serafie (~erin@nat/digium/x-ygzlmimciohoblfp)
13:03.24*** join/#asterisk-bugs zerohalo (~zerohalo@74.61.196.236)
13:08.21*** join/#asterisk-bugs mjordan (~mjordan@nat/digium/x-tnyocwuyiarmgkov)
13:08.22*** mode/#asterisk-bugs [+o mjordan] by ChanServ
13:32.23*** join/#asterisk-bugs vfabi (~fabi@host-static-93-116-255-140.moldtelecom.md)
15:25.35mjordanleifmadsen: ping
15:25.46leifmadsenmjordan: omgpong
15:26.25mjordan!
15:26.39mjordanI'm thinking through ASTERISK-20313
15:26.39leifmadsenWAT?!
15:27.18mjordanI agree that this is probably 'works as designed', but I'm not sure of the dialplan evaluation rules when DUNDi comes into play
15:27.29leifmadsenupdating myself
15:28.37leifmadsenmjordan: basically, he is using a switch, so at that point I'm like "you're on your own"
15:28.50leifmadsenswitches seem to cause havoc when it comes to consistent matching rules
15:29.05mjordan:-(
15:29.06mjordansad panda
15:29.28leifmadsenwell basically the matching in a switch probably doesn't have all the things required -- I dont' think it is a dundi thing
15:29.33leifmadsenhe just happens to be using a dundi switch
15:29.39leifmadsenmy guess, is a realtime switch acts the same way
15:29.49mjordanright.  And any 'fix' is going to break someone
15:29.50leifmadsenor any other switch
15:29.52leifmadsenright
15:29.59leifmadsenand there is a work around
15:30.05leifmadsenbasically, "don't use switches"
15:30.09mjordanI'd be fine throwing it in as a candidate to fix in some major release
15:30.14leifmadsenagreed
15:30.24leifmadsenbut it's not a "bug" -- it's probably undefinied behaviour
15:30.31mjordanheh
15:30.36leifmadsenwhich is a bug :)
15:30.38mjordanit may even be defined, just inconsistent with the rest of the dialplan
15:30.39mjordan:-D
15:30.46leifmadsenwell, switches are OLD SCHOOL
15:30.50leifmadsenI've never used a switch
15:30.53leifmadsenNOT ONCE
15:30.58mjordanyikes
15:31.14leifmadsenif I had used them a few times I might have found a use for them, but I've never required them
15:31.32leifmadsenthey are kind of the old school method of accessing things that are more readily accessible :)
15:32.08leifmadsenessentially, the switch is eating up the match, which kind of makes sense, since it is kind of an include
15:32.17leifmadsenthat's how I'm kind of viewing it -- just a high matching include
15:32.20leifmadsen* match local
15:32.22leifmadsen* match switch
15:32.23mjordanand apparently it takes precedence
15:32.25leifmadsen* match includes in order
15:32.26mjordanright
15:32.27leifmadsenright
15:32.30leifmadsenso that's how I would see it
15:32.36leifmadsenthere -- defined behaviour :)
15:32.42mjordanactually, it almost appears in this case as if it takes precendence over the local
15:32.51leifmadsenI would not be opposed to it being modified to work at an include level so you could order it
15:32.55leifmadsenoh really
15:33.03mjordanthe label jump ignores the fact that the extension its currently in has the label
15:33.06leifmadsenthen that would not be expected behaviour, but could be defined
15:33.06mjordanand goes to the switch first
15:33.10leifmadsenthere is a work around for that too
15:33.14leifmadsenplace the switch in an include
15:33.26mjordanew
15:33.28leifmadsenthen place your included context with the switch at the bottom
15:33.39leifmadsennot really... that's how you define matching order in dialplan
15:33.41leifmadsenthat's how it's always worked
15:33.43mjordanyeah... see, that's where I agree with Noah.  That's fugly
15:33.54leifmadsenthat's how dialplans have always worked though
15:33.58leifmadsenyou always match local, then includes in order
15:34.03leifmadsenonly way to define matching order
15:34.08mjordanoh I agree with that
15:34.10leifmadsenI agree switch being highest priority is kind of wrong
15:34.21mjordanI meant having the switch take precedence over the local, and using an include to work around it
15:34.25leifmadsenright
15:34.32leifmadsenI would say if there is a bug, it's that switch is highest priority
15:34.36leifmadsenit should be 2nd highest
15:34.52Qwellswitch should either be first or last, shouldn't it?
15:34.58leifmadsenI'd not say "fugly" though -- it's not ideal, but it's not that ugly
15:35.10leifmadsenQwell: I'd say it should be in the order defined along with includes
15:35.12leifmadsenideally...
15:35.15leifmadsenmight be nice to do
15:35.17leifmadseninclude
15:35.19leifmadsenswitch
15:35.20Qwellbut switch can be another system entire..
15:35.20leifmadseninclude
15:35.24Qwellentirely*
15:35.26leifmadsentrue true
15:35.36mjordanQwell: https://issues.asterisk.org/jira/secure/attachment/44415/dialplan.txt
15:35.41leifmadsenso if switch should be first, then it should be controlled via an include
15:35.51mjordanQwell: I don't think the switch should override the (notloggedin) label in the current extension
15:36.01leifmadsenmjordan: no, so he's wrong
15:36.14Qwellmjordan: I agree.  Hence my comment. :D
15:36.23leifmadsenbasically in that example, switch IS the local dialplan
15:36.33leifmadsenI would never expect internal to match first there
15:36.49leifmadsenswitch will always match before an include
15:36.55leifmadsensame rule as local dialplan
15:37.31leifmadsennow if switch matches over local dialplan... then ya, maybe a debate could be had over that, but in that example, switch is definitely highest order
15:38.05leifmadsenif the switch was local dialplan, you would say that is defined behaviour, and he should use an include to control the order of matching
15:38.12leifmadsenwhich was what I suggested he do
15:38.33leifmadsenreally, my best practice is that top level contexts should be nothing but includes
15:39.14leifmadsenhope that helps
15:40.08leifmadsenI'll let you explain my rational and make your own comment on the issue. I'd do it myself, but I'm way behind on work for the day
15:40.19Qwellgives leifmadsen an e
15:40.32leifmadsene for excellent, nice
15:40.50Qwelle for eff you, buddy
15:40.55Qwellwait, wrong channel
15:40.58leifmadsenlolz
15:41.48mjordanleifmadsen: np, thanks for the explanation
15:45.10leifmadsenideally I'd be smart and put it into Asterisk 4e
15:45.36mjordanleifmadsen: something tells me y'all have enough updates to make
15:45.41leifmadsenno kidding
15:45.49leifmadsenquite behind for where we're supposed to be at
15:46.02leifmadsenbut that is something that comes up pretty often, and that is a good example I htink
15:46.12leifmadsenat least should talk about order matching and how to override that if we don't already
16:04.31mjordanhm.
16:04.33mjordanrut roh.
16:04.55mjordanleifmadsen: Qwell: http://pastebin.com/4SCxQj3y
16:05.12Qwellcalled it!
16:05.18mjordanthat's from the delivered extensions.conf.  That seems to blow the theory out of the water - switches should be evaluated after includes
16:06.02leifmadsennot really...
16:06.12leifmadsenthe first half doesn't agree with the latter half
16:06.13mjordanhm
16:06.20leifmadsenit tells you to put a switch in a context and include it
16:06.47mjordanexcept that it says to do that in order to get it evaluated before context matching (which seems odd0
16:06.49mjordanodd0
16:06.50mjordanodd)
16:06.52mjordanstupid shift key
16:07.05leifmadsenwhere did that come from? extensions.conf?
16:07.29mjordanyup
16:08.28leifmadsenya, that makes sense
16:08.31leifmadsenhere is what it says to do
16:08.33leifmadsen[cC]
16:08.37leifmadsenswitch => A
16:08.41leifmadsen[cB]
16:08.46leifmadseninclude => cC
16:09.19leifmadsenwait
16:09.21leifmadsen2nd part
16:09.24leifmadsen[cA]
16:09.27leifmadseninclude => cC
16:09.29leifmadseninclude => cB
16:09.34leifmadsen<PROTECTED>
16:09.43leifmadsenit's not worded that well, but that's generally what I think the latter half is say
16:09.44leifmadsensaying *
16:09.48leifmadsenwhich is what I recommended
16:09.55leifmadsenbut the wording the first half is wrong
16:09.59mjordanI agree on the second part's recommendation, but it conflicts with the strongly worded first part
16:10.03leifmadsenagreed
16:10.07leifmadsenfirst the first part :)
16:10.09leifmadsenbug closed
16:10.12leifmadsendocumentation issue
16:10.53leifmadsenit suggests switches are matched last (as Qwell said it should be first or last), but the 2nd half implies a switch is matched before an include, which means it needs to be matched first
16:10.56leifmadsenwhich it appears to be
16:11.28leifmadsen; The order of matching within a context is always: switches, exact extensions, pattern match extensions and includes.
16:11.36leifmadsen; Includes are always processed... etc
16:11.46leifmadsenso just fix the first sentence
16:11.57mjordanwell, that'll be part of the documentation issue
16:12.03Qwellleifmadsen: I don't think that's right either
16:12.04mjordanthe asterisk wiki is a bit ... lacking ... on this topic
16:12.09leifmadsenyou can feel free to suggest a change in order for a major version
16:12.14mjordannah
16:12.16leifmadsenmjordan: because no one uses switches
16:12.19mjordanleifmadsen: really, where's the benefit?
16:12.29mjordanthe problem here is that the behavior caught him unawares
16:12.29leifmadsenmjordan: I don't agree it should be changed
16:12.32leifmadsenagreed
16:12.46leifmadsenyou suggested it could maybe be changed in a future version, so I was just saying I'd be ok with that, but not suggest it be done.
16:12.52leifmadsenjust sayin' :)
16:12.54mjordanleifmadsen: I'm back peddling
16:12.59leifmadsenfair enough
16:13.04mjordanI disagree with my past self
16:13.16leifmadsenI don't like changed behaviour if there is a way to make things work the way you want as is
16:13.18leifmadsenwhich it appears there is
16:13.22leifmadsenQwell: how so?
16:13.41leifmadsenor does a switch only match before an include, and not before local dialplan
16:13.47leifmadsensomeone just needs to test that to verify
16:14.07leifmadsenI'd expect local exact, local pattern match, [switch,include]
16:14.17mjordanI think the problem is that the channel is in [users], which means there is no local dialplan.
16:14.19leifmadsenswitch or include order doesn't matter to me as long as it's defined
16:14.29leifmadsenmjordan: right, there is only includes
16:14.44leifmadsenso in this case, a switch is a higher priority than an include, which does seem to make sense to me
16:14.49mjordanso it evaluates switch before includes, and borks out because there was an extension match in the switch, but no label amtch
16:14.50mjordanmatch
16:14.57Qwellleifmadsen: it's a depth thing.  switches are still after includes.  But if you have 2 includes, one of which has a switch...
16:14.57leifmadsenright
16:15.06QwellYour switch will, in effect, be processed before the second include.
16:15.14Qwell[A]
16:15.17Qwellinclude => b
16:15.18Qwellinclude => c
16:15.25Qwell[b] switch => ...
16:15.29Qwell[c] exten => someshit
16:15.39Qwellthat switch will have higher priority than the exten
16:15.43leifmadsenQwell: uhhhh.... the reporter is stating that a switch is matched before include
16:15.53leifmadsenQwell: yes, in your example that is exactly what I would expect to happen
16:15.57leifmadsenexactly
16:16.05QwellI'm saying what the documentation says.  It's not conflicting in my mind.
16:16.11leifmadsenif you had exten => someshit in [b] I'd expect it to match b first as well
16:16.16Qwellcorrect
16:16.22leifmadsenok so here is the resolution
16:16.24Qwellor if you swapped the order in which you included b and c
16:16.32leifmadsen1) make sure switch does indeed match after local and pattern
16:16.39leifmadsen2) we know switch matches before include
16:16.44Qwellbut it doesn't
16:16.46leifmadsen3) update documentation to reflect that, and leave 2nd half
16:16.46Qwellor, shouldn't
16:16.50leifmadsenit does
16:16.56Qwellwhat issue is this?
16:16.59leifmadsenand I don't care if it does or not, but I'm saying that's how it works
16:17.04mjordanASTERISK-20313
16:17.15leifmadsenlocal, pattern, switch, include
16:17.21Qwellyeah that's broken
16:17.22leifmadsenthat's the order based on the reporters report
16:17.31leifmadsenI don't necessary agree, but if you want to change the order, that's fine
16:17.47leifmadsenI'd prefer to just update documentation than to change behaviour
16:17.53mjordanI'm treating this as documentation first.  If we actually have the behavior written down, then we can argue about what it should be
16:18.03QwellIt is written down. :)
16:18.07mjordanbut with as poorly defined as this scenario *feels* to be, I don't want to go rushing off changing the behavior
16:18.14leifmadsenagreed
16:18.16mjordanQwell: yes, as a badly written paragraph
16:18.29mjordan(and if you wrote that I apologize)
16:18.30Qwellit reads fine to me.  It may just need an example.
16:18.47leifmadsendocumentation does seem to indicate switch should match last
16:18.49leifmadsensoooo
16:18.57leifmadsencheckout 1.2, and see if the behaviour changed
16:18.58mjordanQwell: I'd be down with that.  But it doesn't feel as clear as it should be, given the complexity that some dialplans will get into with switches
16:19.04leifmadsenif it changed, revert it
16:19.08leifmadsenif it always worked that way, update docs
16:19.25mjordanleifmadsen: can I assign the resulting "omg your broke my dialplan" issues to you? :-)
16:19.35leifmadsenmjordan: now that I've ready it a couple times, the example does imply you need to include before another include to make the switch match first
16:19.43leifmadsenmjordan: yes. yes you can.
16:20.06leifmadsenI'd find out which major version it changed in
16:20.09leifmadsenand only change it in asterisk 11
16:20.12mjordan12
16:20.15leifmadsen12 yes.
16:20.23Qwellsilly question.  do we know if he's using patternmatchnew or something silly?
16:20.31mjordanI'm still starting out on documentation.
16:20.37mjordanQwell: now why did you have to go there
16:20.39leifmadsenQwell: I don't think so -- but it's easy enough to test standard and verify the behaviour
16:20.49leifmadsenI'd ignore that entirely
16:20.53*** join/#asterisk-bugs MLNoah (~MLNoah@noc.metalink.net)
16:20.58Qwellwell, it would help to know it's disabled
16:21.00leifmadsenjust run your own test and verify as we've finished defining how it should be working
16:21.13mjordanwell, MLNoah just entered so he can answer whether or not he's using new pattern matching
16:21.14leifmadsenQwell: this is very easy to test, so I'd just do that rather than wasting time
16:21.17leifmadsenget the issue closed out
16:21.31leifmadsenwe have a grasp of the issue, so who cares what the reporter has setup
16:23.25MLNoahi am not using the new pattern matcher, no.
16:25.09Qwellwait.  which gotoif is triggering this weirdness?  Is it the gotoIf that would be at priority 5 in internal?
16:25.56MLNoahyes.
16:26.26MLNoahif I do it as n,GotoIf($[${ODBCROWS} < 1]?9) then it jumps to [internal],exten,9
16:26.30QwellSo none of the ordering stuff we just discussed is really relevant.  It's already getting there properly...
16:26.36MLNoahbut as written in my attachment, it complains.
16:26.51QwellI don't doubt that the switch is causing a problem, but I think it's for other reasons than we think
16:27.07MLNoahi also messed with Goto and GotoIfTime with the same basic logic and they do the same thing.  a numeric priority works.  a label does not.  a context,extension,label does work.
16:27.18leifmadsensounds like switch also isn't aware of priority names then
16:27.28leifmadsens/names/labels/
16:27.28Qwellmaybe, or it's some weirdness with same =>
16:27.33leifmadsenQwell: maybe
16:27.40leifmadsenprobably the switch though
16:27.43leifmadsenthat's where I'd hedge my bets
16:27.51leifmadsenswitches are not used very often
16:27.56Qwelltrue enough
16:27.58leifmadsenso they can cause all sorts of weirdness
16:28.03leifmadsenas we're seeing here
16:28.08MLNoahi can test without the same really quick.
16:29.46MLNoahidentical behavior with exten => _3XX,n instead of same => n
17:20.39*** join/#asterisk-bugs JunK-Y (~junky@pdpc/supporter/active/junk-y)
17:20.39*** mode/#asterisk-bugs [+o JunK-Y] by ChanServ
18:59.57*** join/#asterisk-bugs MLNoah (~MLNoah@noc.metalink.net)
21:41.01*** part/#asterisk-bugs mjordan (~mjordan@nat/digium/x-tnyocwuyiarmgkov)
22:32.44*** join/#asterisk-bugs n0tk (~n0tk@gateway/tor-sasl/n0tk)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.