| 00:20.40 | alecdavis | cresl1n: did you get the debug email? |
| 00:42.19 | *** part/#asterisk-dev Cresl1n (~matt@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 01:03.15 | *** join/#asterisk-dev snuff-work (~aaa@120.19.76.108) |
| 01:03.15 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:45.48 | *** join/#asterisk-dev italorossi (~italoross@189.124.198.166) |
| 02:02.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-75-87-99-1.kc.res.rr.com) |
| 02:03.20 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 02:03.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 02:06.15 | *** join/#asterisk-dev ticoit (~ticoit@201.191.190.112) |
| 02:21.54 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 04:33.20 | *** join/#asterisk-dev jnfuller (~jnfuller@d64-180-195-142.bchsia.telus.net) |
| 04:34.53 | *** join/#asterisk-dev jnfuller (~jnfuller@d64-180-195-142.bchsia.telus.net) |
| 04:48.18 | *** join/#asterisk-dev jnfuller (~jnfuller@d64-180-195-142.bchsia.telus.net) |
| 04:49.12 | *** part/#asterisk-dev jnfuller (~jnfuller@d64-180-195-142.bchsia.telus.net) |
| 06:36.52 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 07:02.45 | *** join/#asterisk-dev fiddur (~fiddur@192.121.104.121) |
| 07:22.28 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 07:22.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:33.31 | *** join/#asterisk-dev oej (~olle@eduroam-193-157-113-13.uio.no) |
| 07:33.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:34.09 | oej | morning folks |
| 07:37.01 | snuff-work | mornin oej |
| 07:42.34 | *** join/#asterisk-dev mpe (~mpe@217.74.220.92) |
| 08:04.39 | *** join/#asterisk-dev lmsteffan (~laurent@reef.ac-noumea.nc) |
| 08:09.34 | *** join/#asterisk-dev steliosk (~Stelios@ipa107.2.tellas.gr) |
| 08:11.12 | *** join/#asterisk-dev steliosk (~Stelios@ipa107.2.tellas.gr) |
| 08:14.54 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 08:17.33 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:30.36 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 08:46.14 | *** join/#asterisk-dev sgimeno (~chatzilla@80.33.64.226) |
| 08:53.13 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 09:08.58 | *** join/#asterisk-dev |Cybex| (~John@atwork-21.r-212.178.82.atwork.nl) |
| 09:27.27 | *** join/#asterisk-dev oej_ (~olle@eduroam-193-157-113-13.uio.no) |
| 09:27.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:17.47 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:16.02 | *** join/#asterisk-dev oej (~olle@eduroam-193-157-113-13.uio.no) |
| 12:16.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:28.15 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:28.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:34.04 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 12:34.04 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 12:36.00 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:36.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:37.51 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 12:42.46 | *** join/#asterisk-dev lftsy (~lftsy@leonhart.leurent.eu) |
| 12:44.35 | lftsy | Hello everybody, since my server is currently in a CPU 100% mode, and flooding SIP OPTIONS, I was able to provide many logs for ticket https://issues.asterisk.org/view.php?id=16382 . Is there a developper that can say if there is another useful trace that I can do before restarting the server since I cannot keep it down for a long time... Thanks Best Regards |
| 13:09.16 | tzafrir_laptop | lftsy, I'm not really familiar with that issue, |
| 13:09.32 | tzafrir_laptop | but the console output looks rather thin |
| 13:10.06 | tzafrir_laptop | what's the output of: 'logger show channels' there? (specifically, the 'console' line) |
| 13:10.14 | tzafrir_laptop | leifmadsen, ==^ |
| 13:10.50 | leifmadsen | looking |
| 13:11.45 | lftsy | tzafrir_laptop: looking... |
| 13:12.18 | lftsy | pul-lav-vp-ast-03*CLI> logger show channels |
| 13:12.18 | lftsy | Channel Type Status Configuration |
| 13:12.18 | lftsy | ------- ---- ------ ------------- |
| 13:12.44 | lftsy | tzafrir_laptop: oh, you will find the full log file in the enclosed files |
| 13:12.51 | lftsy | with all the information |
| 13:12.54 | leifmadsen | lftsy: your backtrace seems to have values optimized out too |
| 13:13.08 | leifmadsen | lftsy: you've got DONT_OPTIMIZE enabled right? |
| 13:13.33 | lftsy | leifmadsen: I do not know, sorry, what's this |
| 13:14.11 | leifmadsen | in menuselect, under the Compiler Flags option, you need DONT_OPTIMIZE enabled in order to produce useful backtraces |
| 13:14.57 | lftsy | leifmadsen: no, sorry it was a simple installation, I haven't modified the source since it's a in production server |
| 13:15.16 | leifmadsen | well, it's not modifying the source, it's enabling a feature in menuselect :) |
| 13:16.02 | lftsy | leifmadsen: I can try to modify a dev server and reproduce the bug again |
| 13:16.10 | leifmadsen | ok |
| 13:17.48 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 13:18.46 | lftsy | leifmadsen: but it is quite easy to reproduce it on Asterisk 1.4.x+realtime peer, I have put the procedure in the ticket. I will try it now |
| 13:19.29 | leifmadsen | ya, but setting up a test environment for testing this will take a developer some time, and if you can already reproduce it on your dev system, it saves a lot of time for you to just produce the information |
| 13:19.38 | leifmadsen | thx for trying! |
| 13:53.11 | *** join/#asterisk-dev |Cybex| (~John@atwork-21.r-212.178.82.atwork.nl) |
| 13:56.24 | lftsy | Regarding the debug, do you need more than DONT_OPTIMIZE in the compilation flags options? |
| 14:00.13 | jsmith | lftsy: That will *probably* be enough |
| 14:03.09 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:03.10 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:07.38 | lftsy | Is it possible to set the MENUSELECT_CFLAGS=DONT_OPTIMIZE LOADABLE_MODULES by a command line in my compilation scripts? |
| 14:13.43 | jsmith | I think so, but I don't remember how off the top of my head |
| 14:13.55 | jsmith | tzafrir_laptop: Do you remember how? Seems like it was you that showed me how last time |
| 14:14.13 | lftsy | make menuselect.makeopts && sed -i "s/MENUSELECT_CFLAGS=.*/MENUSELECT_CFLAGS=DONT_OPTIMIZE LOADABLE_MODULES/" menuselect.makeopts |
| 14:14.32 | lftsy | how can I verify once compiled that it is enabled? |
| 14:15.16 | tzafrir_laptop | lftsy, start building and see if your editing is still in place |
| 14:15.28 | tzafrir_laptop | or build with NOISY_BUILD=yes |
| 14:38.45 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:06.35 | lftsy | tzafrir_laptop: now that I have the option enabled, what should I report once I have reproduced the problem? Thanks |
| 15:07.29 | tzafrir_laptop | attach the trace to the bug report? |
| 15:08.08 | leifmadsen | typically console output with debugging enabled in logger.conf, core set verbose 10, core set debug 10, SIP trace with SIP history enabled via sip.conf, and the backtrace with DONT_OPTIMIZE enabled |
| 15:08.21 | leifmadsen | that's just the general things requested for SIP related issues |
| 15:10.57 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-2925257034.dsl.bell.ca) |
| 15:27.35 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:27.35 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:32.40 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:32.40 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:37.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:37.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:59.51 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:59.51 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:10.37 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 16:10.38 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:15.54 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:19.36 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 16:21.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:21.22 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:21.49 | *** join/#asterisk-dev cobolfoo (~cobolfoo@bas7-quebec14-1096763909.dsl.bell.ca) |
| 16:22.18 | cobolfoo | Hello I have some issues with DAHDI development and hook state detection for a TDM400P card, someone can help me? |
| 16:24.16 | tzafrir_laptop | cobolfoo, maybe, if you're actually more specific |
| 16:24.31 | cobolfoo | http://pastebin.com/m17399aa1 Thre is a short code that help explain my problem |
| 16:24.40 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 16:25.00 | cobolfoo | With this code I can get the audio data but not the hook state (aka events) |
| 16:25.15 | cobolfoo | I would like to detect when someone pick the phone handset or hangup |
| 16:25.31 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 16:25.43 | cobolfoo | I also tested the same code on a SANGOMA/wanpipe A200 and have exactly the same result. Audio data but no events |
| 16:25.47 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:25.59 | tzafrir_laptop | cobolfoo, userspace code? |
| 16:26.01 | cobolfoo | It means my code might be the problem :) |
| 16:26.02 | cobolfoo | yes |
| 16:26.49 | cobolfoo | ioctl(fd, DAHDI_GETEVENT,&j) always return 0 |
| 16:28.08 | moy | cobolfoo: are you using the iomux ioctl? |
| 16:28.21 | cobolfoo | No I dont think so (you means waiting for events?) |
| 16:28.28 | moy | yes |
| 16:30.10 | cobolfoo | No I don't use it. If I use it, my program wait indefinitely for an event |
| 16:31.35 | kpfleming | you have to use IOMUX and wait for *either* data or an event, then act appropriately when it returns |
| 16:32.44 | cobolfoo | In my program I just do a while() with read(), this is not correct? |
| 16:33.03 | kpfleming | not if you want to receive events, as you've already learned |
| 16:33.08 | kpfleming | events won't wake up read() |
| 16:33.49 | *** join/#asterisk-dev JT (~j@unaffiliated/jt) |
| 16:35.53 | cobolfoo | I do a ioctl(fd, DAHDI_IOMUX, &i) where i == DAHDI_IOMUX_SIGEVENT |
| 16:36.04 | cobolfoo | I guess I need to add a flag for data? |
| 16:36.07 | kpfleming | yes |
| 16:36.16 | kpfleming | and then when it returns it will tell you what is available |
| 16:36.40 | cobolfoo | ok I'till try this right now |
| 16:44.35 | *** join/#asterisk-dev jtexter3 (~jtexter3@72.242.229.213) |
| 16:50.49 | cobolfoo | http://pastebin.com/mdcb4b16 There are my changes |
| 16:50.54 | *** join/#asterisk-dev JT (~j@unaffiliated/jt) |
| 16:50.55 | cobolfoo | still no events |
| 16:51.15 | cobolfoo | I am calling ioctl(fd, DAHDI_IOMUX) with DAHDI_IMOUX_SIGEVENT | DAHDI_IOMUX_READ |
| 16:55.23 | cobolfoo | I can get events like ringing but no hook state |
| 16:55.43 | cobolfoo | Do I need to increase RX gian? |
| 16:55.44 | cobolfoo | gain |
| 16:59.15 | kpfleming | gain has nothing to do with events |
| 16:59.35 | kpfleming | what kind of card and port are you using? |
| 16:59.46 | cobolfoo | Right now I am using a TDM400p / analog |
| 16:59.55 | cobolfoo | But I had the same results with Sangoma A200 / analog |
| 17:00.02 | kpfleming | what kind of port |
| 17:00.06 | cobolfoo | fxo |
| 17:00.24 | kpfleming | then there is no hook state events... the outside party does not control hook state on an fxo port |
| 17:00.25 | kpfleming | you do |
| 17:00.40 | cobolfoo | I dont want to control it, just snoop the events |
| 17:00.57 | kpfleming | what events are you expecting to see? |
| 17:01.09 | cobolfoo | Juste one, hook state |
| 17:01.11 | moy | cobolfoo: which means you can send offhook/onhook commands, but not receive events since you originated the status in the first place :) |
| 17:01.31 | cobolfoo | I need the card to tell me if the line is currently in use |
| 17:01.39 | kpfleming | the card can't do that |
| 17:01.52 | kpfleming | you can periodically query the hook state, i suppose |
| 17:01.58 | kpfleming | but you won't be able to get hook state events |
| 17:02.10 | cobolfoo | I already do this with different hardware but I would have prefered using TDM cards |
| 17:02.28 | cobolfoo | How I can query hook states without using events? |
| 17:02.38 | kpfleming | there is a specific ioctl for that |
| 17:02.48 | cobolfoo | Since I have data I can do silence detection but it is a very weak approach |
| 17:03.48 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 17:04.38 | cobolfoo | kpfleming, do you know the name of this ioctl? |
| 17:05.01 | kpfleming | not off the top of my head, but it's defined in dahdi/user.h |
| 17:05.57 | cobolfoo | I tried with DAHDI_GET_PARAMS and checked dahdi_params.rxisoffhook but without any result |
| 17:06.05 | kpfleming | it's not a parameter |
| 17:06.08 | kpfleming | it's a state |
| 17:07.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:07.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:10.14 | cobolfoo | a search for "state" keyword return no signifiant result hehe |
| 17:16.08 | moy | cobolfoo: check for DAHDI_CHECK_HOOKSTATE in channels/chan_dahdi.c |
| 17:16.28 | kpfleming | it appears i was wrong... there is an ioctl to set the hook state, but not one to retrieve it |
| 17:17.52 | moy | seems like asterisk uses GET_PARAMS |
| 17:17.56 | moy | to check hook state |
| 17:19.29 | *** join/#asterisk-dev JT (~j@unaffiliated/jt) |
| 17:20.20 | cobolfoo | I think I will need to play with drivers code to see how hook state is checked on TDM400p |
| 17:21.17 | cobolfoo | wxctm_user.h have some IOCTL defined like: WCTDM_GET_STATS which contains voltage information |
| 17:21.36 | cobolfoo | wxctdm_user.h I mean, do its compatible with TDM400p? |
| 17:23.52 | tzafrir_laptop | cobolfoo, is it on Linux? |
| 17:23.55 | cobolfoo | yes |
| 17:23.58 | cobolfoo | oh it is working! |
| 17:24.13 | cobolfoo | WXTDM_GET_STATS return voltage information (aka hook state) |
| 17:24.25 | tzafrir_laptop | I wonder if such information is not better exported via sysfs |
| 17:24.27 | cobolfoo | I guess It would not work with sangoma but at least I have a solution for TDM400p |
| 17:29.35 | cobolfoo | tzafrir_laptop, what do you mean by sysfs? |
| 17:29.38 | cobolfoo | checking in /proc? |
| 17:32.38 | *** join/#asterisk-dev italorossi (~italoross@201.76.154.123.intranet.digi.com.br) |
| 17:39.25 | cobolfoo | btw, thank you guys :) |
| 17:40.06 | cobolfoo | do DTMF detection, Caller ID an other CAS stuff needs to be done in software? My doing FSK decoding on the audio stream for example? |
| 17:40.13 | cobolfoo | By |
| 17:43.39 | cobolfoo | tzafrir_laptop, when you said Linux, do you means that asterisk + TDM400p can run on windows |
| 17:59.46 | tzafrir_laptop | cobolfoo, I guess they can, if you write the drivers :-( |
| 18:01.31 | Corydon76-dig | putnopvut: ping |
| 18:24.56 | Deeewayne | leifmadsen, ping |
| 18:28.47 | jtexter3 | I see an old commit about epoll support being removed because it was causing issues. Since it hasn't been uncommented from the configure script, I'm assuming that's still the case? |
| 18:36.02 | putnopvut | Corydon76-dig: pong |
| 18:36.26 | Corydon76-dig | putnopvut: what's holding up review 219? |
| 18:36.36 | putnopvut | um, let me take a look. |
| 18:37.44 | putnopvut | Corydon76-dig: After discussing things on the dev list, it was determined that a different approach would be used. The idea was that a separate lock would be used in channels for queuing frames and reading frames from the frameq. Damien Wedhorn started working on it some, but I haven't seen hide nor hair of him for a long time now. |
| 18:38.33 | putnopvut | I should probably just remove that review from reviewboard at this point since the way posited there is not going to be pursued. |
| 18:39.10 | Corydon76-dig | Actually, I'm wondering if we should pursue it, and remove the implementation when something better is actually completed |
| 18:39.21 | Corydon76-dig | Otherwise, we're being held up by vaporware |
| 18:39.27 | russellb | the better approach is already implemented and waiting on review |
| 18:39.28 | russellb | it's in mantis |
| 18:39.42 | Corydon76-dig | Ah, okay |
| 18:39.50 | russellb | it's buried in our queue somewhere ... |
| 18:39.57 | Corydon76-dig | Heh |
| 18:40.12 | russellb | :-( |
| 18:40.17 | Corydon76-dig | One of the issues you just imported would be fixed by that |
| 18:40.29 | Corydon76-dig | M16811 |
| 18:40.31 | MuffinMan | [acknowledged] [Asterisk] Core/ManagerInterface 0016811: Heavy locking in manager.c results in eventual crash and loss of CLI commands and intense CPU load reported by aragon https://issues.asterisk.org/view.php?id=16811 |
| 18:40.40 | russellb | oh dear. |
| 18:40.53 | Corydon76-dig | I looked at it, and it's a chan_local deadlock |
| 18:52.46 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 18:53.22 | *** part/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 18:53.34 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 18:53.34 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 19:05.47 | *** join/#asterisk-dev oej (~olle@eduroam-193-157-113-13.uio.no) |
| 19:05.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:06.27 | *** join/#asterisk-dev oej_ (~olle@1x-193-157-196-250.uio.no) |
| 19:06.27 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 19:13.54 | jsmith | putnopvut: RE: M16809, how hard would it be to add multiple priorities for the same extension? |
| 19:14.26 | putnopvut | jsmith: it wouldn't be all that difficult, I suppose. |
| 19:14.45 | putnopvut | The benefit of doing so is not especially apparent to me though. |
| 19:15.02 | jsmith | putnopvut: The reason that I ask is that I know one of the samples I uploaded to the notes on that bug dealt with priorities on CID matching |
| 19:15.27 | putnopvut | Ah, the goto. |
| 19:15.28 | jsmith | putnopvut: (where the first priority would match the extension with the CID, but then it would go on to priority 2 *without* the CID match) |
| 19:15.30 | Qwell | exten => _X.,1,foo() exten => 201,2,bar() |
| 19:15.33 | Qwell | there's that too |
| 19:15.45 | jsmith | Aye :-) |
| 19:15.49 | putnopvut | people do that? ugh |
| 19:15.50 | Qwell | similar concept |
| 19:15.51 | putnopvut | :) |
| 19:15.54 | jsmith | putnopvut: Yup! |
| 19:16.00 | Qwell | putnopvut: think regexten |
| 19:16.04 | jsmith | Or, my favorite: |
| 19:16.09 | jsmith | [something] |
| 19:16.13 | Qwell | the opposite of my example, but w/e |
| 19:16.21 | jsmith | include => else |
| 19:16.33 | jsmith | exten => 123,1,Verbose(2,apple) |
| 19:16.36 | jsmith | [else] |
| 19:16.53 | jsmith | exten => 123,1,Verbose(2,alien) |
| 19:17.07 | jsmith | exten => 123,2,Verbose(2,blargh) |
| 19:17.14 | Qwell | shudders |
| 19:17.16 | jsmith | Dial 123 in the [something] context |
| 19:17.24 | Qwell | apple blargh! |
| 19:18.00 | putnopvut | wow |
| 19:18.03 | putnopvut | you're sick |
| 19:18.06 | putnopvut | :) |
| 19:18.37 | leifmadsen | wow! |
| 19:18.48 | leifmadsen | these are all on the mantis issue right? :) |
| 19:18.54 | leifmadsen | stares at Qwell |
| 19:19.02 | Qwell | leifmadsen: I dunno - have you added them? :D |
| 19:19.05 | leifmadsen | damnit! |
| 19:19.10 | leifmadsen | I will do so now |
| 19:22.40 | putnopvut | that was quick |
| 19:23.48 | jsmith | could spend all day coming up with more nasties |
| 19:23.54 | putnopvut | do it! |
| 19:24.19 | putnopvut | We need that stuff in the test so that we can absolutely hammer things and never have an extension matching regression ever again. |
| 19:29.02 | kpfleming | do you have any examples that mix pattern and non-pattern priorities in the same extension? |
| 19:29.33 | putnopvut | This is going to be the most badass test EVER! |
| 19:29.53 | kpfleming | if you don't, i can provide one. i used to use that method a lot, it's where 'n' and 's' came from :-) |
| 19:30.06 | Qwell | kpfleming: yeah, the one I came up with above |
| 19:30.17 | Qwell | exten => _X.,1,foo() exten => 201,2,bar() |
| 19:30.39 | Qwell | (or the reverse) |
| 19:30.44 | kpfleming | that's not quite what i meant |
| 19:30.53 | kpfleming | you would need to add _X.,2,baz() |
| 19:31.01 | kpfleming | and then check that 201 uses bar(), and 202 uses baz() |
| 19:33.05 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.87.99.1) |
| 19:34.21 | kpfleming | it really should use 'n' for the second line, and 's' for the third line as well, to test that those work properly |
| 19:35.01 | Corydon76-dig | Another test is whether "_2" and "_[2]" compare equal and whatever second is disallowed |
| 19:35.34 | Corydon76-dig | They used to be unequal, but they now are equal |
| 19:35.45 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:39.07 | Corydon76-dig | Here's another dialplan test: does While(0) go to the right place? |
| 19:40.51 | Corydon76-dig | How about While(1) ExitWhile NoOp(this should never happen) EndWhile ? |
| 19:46.35 | jsmith | Corydon76-dig: Add it to the bug, please! |
| 19:47.21 | Corydon76-dig | I only added the first, as he's asking about patterns |
| 19:48.15 | Corydon76-dig | Just thought of something REALLY painful to read... |
| 19:48.33 | seanbright | parade magazine?/ |
| 19:48.37 | Corydon76-dig | A While() at a pattern, with all of the EndWhile's on non-patterns |
| 19:49.09 | Corydon76-dig | maybe the EndWhile's in different (included) contexts |
| 19:49.23 | jsmith | Corydon76-dig: That's almost as bad as a Goto (to a different extension/context) between the While() and EndWhile() |
| 19:49.32 | putnopvut | I'm not sure how I can test While()s in the test I'm writing since I don't ever execute the PBX code. |
| 19:49.45 | Corydon76-dig | putnopvut: you can, though |
| 19:49.47 | putnopvut | All I'm doing is making sure that we end up at the proper exten/priority/context given an input. |
| 19:50.04 | Corydon76-dig | See how Gosub does it |
| 19:50.08 | putnopvut | I can, but that seems like a completely different bag of hammers. |
| 19:50.16 | Corydon76-dig | like the GOSUB AGI command |
| 19:51.12 | Corydon76-dig | Nah, it's more of a bag of hyperactive paranoid weasels high on angel dust |
| 19:51.47 | Corydon76-dig | Good luck holding that bag shut |
| 19:53.16 | kpfleming | yeah, first step will be focusing on pattern matching, that sounds more manageable to me :-) |
| 19:55.03 | putnopvut | I added a note to the bug stating so. |
| 19:55.27 | putnopvut | I purposely placed the test in a file called test_pbx.c with the intention that other PBX-related tests may also be added there. |
| 19:55.40 | putnopvut | But for now, pattern-matching is the only test I'm focusing on. |
| 19:56.56 | jsmith | I've got a good one |
| 19:57.07 | jsmith | It's more related to the difference between gotos and includes |
| 19:57.17 | jsmith | Should I include it, or wait? |
| 19:57.25 | kpfleming | which are like monkeys and spaceships |
| 19:57.38 | jsmith | Sure... |
| 19:57.48 | putnopvut | jsmith: I don't really think that has a place in the test I'm writing, but it certainly should be tested. |
| 19:57.56 | kpfleming | but not monkeys *in* spaceships, that's different |
| 19:58.08 | jsmith | kpfleming: Right... |
| 19:58.20 | jsmith | puts a monkey in kpfleming's spaceship, just because he can |
| 19:58.45 | putnopvut | All my pattern-matching test consists of are calls to pbx_find_extension(), then comparing the returned extension to what we expected to be returned. |
| 20:21.07 | *** join/#asterisk-dev wedhorn (~nnnnnnnnn@123-243-209-34.static.tpgi.com.au) |
| 20:28.47 | jsmith | chuckles at M16813 |
| 20:31.01 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 20:33.28 | putnopvut | M16813 |
| 20:33.30 | MuffinMan | [new] [Asterisk] Core/General 0016813: Failure of canary reported by globalnetinc https://issues.asterisk.org/view.php?id=16813 |
| 20:37.09 | Corydon76-dig | Hey, hey! Proof that the canary works! |
| 20:37.48 | jsmith | Corydon76-dig: I just chuckled, as not an hour ago I had to help my kids chase a sparrow out of the house before the cats ate it |
| 20:38.41 | Corydon76-dig | jsmith: the problem is that for the canary to work, you basically have to make your machine unusable for about a minute or two |
| 20:39.04 | jsmith | Sure, I understand that |
| 20:39.22 | Corydon76-dig | So testing it is hell |
| 20:40.12 | |Rain| | M16815 in case anyone was paying attention to my discussion with myself a week ago |
| 20:43.44 | Corydon76-dig | It'll get into the queue and be looked at as priorities permit |
| 20:46.31 | |Rain| | aye |
| 20:55.18 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 21:16.02 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 21:16.03 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:29.49 | *** join/#asterisk-dev oej (~olle@1x-193-157-196-250.uio.no) |
| 21:29.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:52.45 | snuff-work | anyone have ideas why someone might think that the cdr duration is 0.5 sec longer than what the other end switch says? |
| 22:53.24 | snuff-work | (response to my hr billing patch) |
| 22:53.44 | kpfleming | what protocol is being used for the call signaling? |
| 22:55.04 | Corydon76-dig | snuff-work: I don't think it's really your problem... you're accurately reporting it, not generating it. |
| 22:55.42 | snuff-work | mm yer that's what i thought.. |
| 22:55.47 | snuff-work | kp i think its isdn.. |
| 22:56.06 | kpfleming | well, no, the process of tearing down the call shouldn't take 0.5 seconds |
| 22:56.22 | snuff-work | https://issues.asterisk.org/view.php?id=16559 |
| 22:56.52 | kpfleming | what precision are the durations reported in at both ends? |
| 22:58.06 | snuff-work | mm.. wait a second.. why does he consider duration and billsec to be similar |
| 22:58.23 | kpfleming | they are similar... they are both measures of time :-) |
| 22:58.40 | snuff-work | yes but 1 depends on the other side actually answering |
| 22:58.44 | Corydon76-dig | Because he thinks if the first step in the dialplan is Answer, both the duration and billsec started at the same time (not actually true) |
| 22:58.50 | kpfleming | right |
| 22:59.38 | Corydon76-dig | duration starts when the channel comes up. billsec starts when the PBX is started, which are two different points in time |
| 23:01.27 | kpfleming | billsec should start when the call is answered |
| 23:02.09 | file | I hate CDRs. |
| 23:04.04 | snuff-work | and it is.. |
| 23:23.19 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 23:25.59 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-2925257034.dsl.bell.ca) |
| 23:25.59 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:26.55 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:26.56 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 23:46.02 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:46.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |