| 00:00.43 | seanbright | kpfleming: it's kosher to cast a time_t to long, yes? |
| 00:01.23 | Laureano | seanbright, http://pastebin.ca/1178178 |
| 00:01.48 | Laureano | Also, I changed the getter from String to int and worked like a charm. |
| 00:02.00 | Laureano | Everything seems to be ok. |
| 00:02.02 | seanbright | might want to make it long |
| 00:02.11 | seanbright | err |
| 00:02.13 | seanbright | yeah |
| 00:02.15 | seanbright | make it a long |
| 00:02.26 | Laureano | Ok. |
| 00:02.33 | seanbright | but i'm glad it worked |
| 00:02.34 | seanbright | :) |
| 00:03.17 | Laureano | Me too. No strange behaviours or vortex to another dimensions appeared. |
| 00:03.24 | seanbright | always good |
| 00:04.03 | seanbright | quick way to convert epoch seconds to a string? |
| 00:04.06 | seanbright | anyone? |
| 00:04.11 | Laureano | Changed to Long. Everything all right. |
| 00:07.26 | seanbright | perl -e 'print localtime(1219103982) . "\n";' |
| 00:07.27 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:07.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:07.31 | seanbright | that does the trick |
| 00:07.38 | seanbright | Mon Aug 18 19:59:42 2008 |
| 00:07.40 | seanbright | bam |
| 00:08.06 | seanbright | parseable |
| 00:08.09 | seanbright | parsable |
| 00:08.12 | seanbright | ? |
| 00:17.13 | seanbright | ok, all done with that. |
| 00:55.56 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 00:55.56 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:04.10 | Laureano | Mmm, the doc about SipShowRegistry action and it's associated events is missing in doc/manager_1_1.txt. |
| 01:24.36 | seanbright | Laureano: can you write it and post a patch? |
| 01:25.51 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 01:26.54 | *** part/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 01:30.26 | Laureano | seanbright, Yes. I will. |
| 02:32.16 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:32.16 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:33.10 | *** join/#asterisk-dev luxxx77 (n=luxxx77@g228005135.adsl.alicedsl.de) |
| 02:34.19 | Laureano | Bye guys |
| 03:11.20 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 03:28.13 | *** join/#asterisk-dev moy (n=moy@189.169.82.40) |
| 03:28.20 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 03:45.19 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 03:55.20 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 04:35.05 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 05:15.40 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 05:48.17 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:48.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:52.39 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-16094.home.otenet.gr) |
| 06:18.57 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:18.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:19.55 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 06:20.53 | *** join/#asterisk-dev l0verb0y (n=l0verb0y@119.92.209.33) |
| 06:30.18 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:30.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:49.41 | snuff-work | mvanbaak: ping? |
| 06:51.29 | *** join/#asterisk-dev VoicePulse_ (n=contact@unaffiliated/voicepulse) |
| 07:05.53 | *** join/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) [NETSPLIT VICTIM] |
| 07:17.38 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 07:17.50 | *** join/#asterisk-dev d3wayne (n=dwayne@76.29.245.9) |
| 07:17.50 | *** mode/#asterisk-dev [+o d3wayne] by ChanServ |
| 07:18.04 | *** join/#asterisk-dev linuxstb (n=linuxstb@rockbox/developer/linuxstb) [NETSPLIT VICTIM] |
| 07:18.20 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.172.3) |
| 07:22.04 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-16094.home.otenet.gr) |
| 07:30.58 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:30.58 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:39.02 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 07:40.06 | mvanbaak | pong |
| 07:40.13 | mvanbaak | snuff-work: you rang ? |
| 07:49.42 | snuff-work | :) |
| 07:49.56 | snuff-work | M13113 |
| 07:49.58 | MuffinMan | [feedback] [Asterisk] Core/General 0013113: [patch] Can't build RPM with 1.4.21.1 (few errors & fix) reported by sybasesql (Karma: +1.50) http://bugs.digium.com/view.php?id=13113 |
| 07:50.09 | snuff-work | license approved now |
| 08:02.41 | mvanbaak | I see :) |
| 08:05.32 | wedhorn | mvanbaak: How's things? Browsing chan_skinny in relation to 12324 and it seems that the call waiting option isn't actually used anywhere. Any idea? |
| 08:07.56 | mvanbaak | wedhorn: busy busy busy here, but good |
| 08:08.05 | mvanbaak | yeah, I noticed that as well |
| 08:08.13 | mvanbaak | you can set the callwaiting option, but that's it |
| 08:08.17 | mvanbaak | it's never used |
| 08:08.21 | wedhorn | I might have a look at it |
| 08:08.24 | mvanbaak | not even in the show settings I think |
| 08:08.28 | wedhorn | it would be a good thing to hae |
| 08:08.47 | wedhorn | I think show lines is the only place it is used |
| 08:08.52 | mvanbaak | yeah |
| 08:09.00 | mvanbaak | pretty lame ;) |
| 08:09.06 | wedhorn | yep |
| 08:09.45 | mvanbaak | there's a bug on mantis about this |
| 08:09.51 | wedhorn | I'm also thinking about making the button templates configurable. Probably not important for the newer phone, but with my 26 buttons, it would be handy. |
| 08:10.11 | wedhorn | Any ideas about how it should look in skinny.conf |
| 08:10.21 | mvanbaak | the button template ? |
| 08:10.25 | mvanbaak | meh, no idea |
| 08:10.44 | mvanbaak | button01 = NewCall |
| 08:10.49 | mvanbaak | something like that ? |
| 08:11.26 | wedhorn | that wouldn't necessarily parse well, was thinking about button=LINE,3 |
| 08:11.41 | wedhorn | if 3 excluded, just adds 1 to prev |
| 08:13.25 | *** join/#asterisk-dev jmacz (n=jmacz@190.26.185.69) |
| 08:16.02 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.193) |
| 08:32.22 | mvanbaak | ah |
| 08:32.27 | mvanbaak | well, I did not think about it all |
| 08:32.35 | mvanbaak | just a brainfart there :) |
| 08:43.43 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 08:52.25 | *** part/#asterisk-dev dominic1 (n=dob@213.221.82.242) |
| 09:03.31 | wedhorn | anyone know if AST_LIST_EMPTY empties a list or tests it? |
| 09:12.40 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-16094.home.otenet.gr) |
| 09:35.36 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 09:38.24 | jmacz | hi everyone, I'm looking inside libpri (1.4.7) directory to find out where the default values for the PRI ISDN timers are defined, but in pri_timers.h most of them are omitted |
| 09:38.30 | jmacz | any ideas where I should look? |
| 09:48.18 | tzafrir_laptop | OT: penis_enhancement patch: http://dev.rubyonrails.org/ticket/10919 |
| 10:09.03 | *** join/#asterisk-dev nikolaev (n=nikolaev@78.83.145.98) |
| 10:31.25 | *** join/#asterisk-dev l0verb0y (n=l0verb0y@119.92.209.33) |
| 10:35.45 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:01.46 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:01.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:17.45 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-110621.home.otenet.gr) |
| 11:18.33 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 11:18.33 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 11:21.39 | *** join/#asterisk-dev friendly12345 (n=friendly@ppp59-167-128-87.lns3.mel6.internode.on.net) |
| 11:21.56 | mvanbaak | hide! |
| 11:21.59 | mvanbaak | russellb is here |
| 11:23.42 | *** part/#asterisk-dev nikolaev (n=nikolaev@78.83.145.98) |
| 11:23.51 | wedhorn | i'll take him .... |
| 11:24.01 | wedhorn | nothing to lose .... |
| 11:24.04 | russellb | O.o |
| 11:24.06 | wedhorn | bloody skinny |
| 11:24.17 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:24.27 | wedhorn | chan_ that is |
| 11:24.43 | mvanbaak | lol wedhorn |
| 11:24.46 | mvanbaak | hey eliel |
| 11:24.54 | eliel | mvanbaak: good morning |
| 11:25.00 | mvanbaak | wedhorn: we can rewrite it :) |
| 11:25.12 | wedhorn | from scratch |
| 11:25.16 | mvanbaak | yes |
| 11:25.16 | wedhorn | yay |
| 11:25.39 | mvanbaak | maybe not a bad idea eh ? |
| 11:26.07 | eliel | We need to fix a bug (??) introduce by me that shows a warning message while compiling in dev-mode |
| 11:26.09 | wedhorn | yeah maybe, actually a big chunk of my shared lines stuff was along those lines |
| 11:26.17 | mvanbaak | eliel: yeah |
| 11:26.32 | mvanbaak | eliel: I was going to bug you about it after the chan_skinny talk |
| 11:27.23 | wedhorn | mvanbaak: can you call your skinny phone, answer it, then call it again from somewhere else. Then just hang up and see what happens |
| 11:27.37 | eliel | it is because of the reverse_helper, I tried __attribute__ in many ways but it continue showing it... it says the function is a candidate for printf attribute, but the problem is that we have to possible formats and we can check only one puttin something like __attribute__((format(printf,4,5))) |
| 11:27.37 | mvanbaak | wedhorn: I'm at work right now, so no |
| 11:27.59 | wedhorn | oh, ok |
| 11:28.03 | mvanbaak | eliel: yup |
| 11:28.13 | eliel | s/have to/have two/ |
| 11:28.41 | mvanbaak | eliel: I looked at where you call those functions |
| 11:28.56 | mvanbaak | we already know wether reverse is set or not when we call that function |
| 11:29.17 | mvanbaak | so, why not give it a single format argument, and feed it the correct one ? |
| 11:30.50 | wedhorn | anyway, I got the callwaiting stuff working, but noticed that when the other call is hung up, it rips down the main call (well the rtp part anyway - how the hell does that happen) |
| 11:30.58 | mvanbaak | if (reverse) xmldoc_reverse_helper(reverse, len, syntax, ")", name); else ...")%s" |
| 11:31.17 | eliel | mvanbaak: yeaph, I tried creating a macro definition (and pass only one format) but new warnings appear, I will make a patch and send it to you, or pastebin the errors |
| 11:31.28 | mvanbaak | wedhorn: maybe a wrong transmit_* call that's wrong ? |
| 11:36.35 | wedhorn | nah, the inbound call sets itself as the activesub when it's not (new_call = activesub). So hangup thinks it's got to cancel the rtp, but the rest of the sub is still there |
| 11:36.50 | mvanbaak | hhhmm |
| 11:37.10 | wedhorn | and when you make is small change, it all falls in a heap |
| 11:48.01 | eliel | mvanbaak: http://pastebin.com/d166bbe63 |
| 11:48.13 | eliel | possible candidate |
| 11:48.30 | eliel | We can do this or check reverse in every call to reverse_helper |
| 11:50.57 | eliel | The problem appears when calling reverse_helper with two different kind of format like "(" and "" so, when the preprocessor check the arguments passed to the function against fmt is says that we are passing too many arguments in the "(" situation. |
| 11:51.03 | eliel | huh? |
| 11:51.14 | eliel | \%s test |
| 11:51.41 | eliel | "" so = "\%s" so |
| 11:52.04 | *** join/#asterisk-dev mrjack2 (i=vend3r@office.smart-weblications.net) |
| 11:52.07 | mrjack2 | hi |
| 11:53.17 | mrjack2 | is it planned to integrate a function for sending a sms after the voicemail recieved a call or is there another solution how to send email after voicemail recorded a message? it currently just hangs up the channel so my priorities after the voicemail() are not handeled... any ideas? |
| 11:53.22 | wedhorn | whohoo, callwaiting now (sort of, at least on my phones) working in skinny. |
| 11:53.26 | wedhorn | m12691 |
| 11:53.28 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny 0012691: chan_skinny doesn't respect callwaiting=no reported by sbisker (Karma: +2.00) http://bugs.digium.com/view.php?id=12691 |
| 11:54.17 | mrjack2 | sorry, i mistyped.. i mean sending sms, not email! |
| 11:58.54 | mvanbaak | eliel: looks ok to me. and I get why it will generate that warning |
| 11:59.07 | mvanbaak | printf(")", something); |
| 11:59.14 | eliel | exactly |
| 11:59.20 | mvanbaak | you dont specify any format entry |
| 11:59.42 | eliel | maybe there is a way to pass or not pass __VA_ARGS__ depending on format content (??) |
| 11:59.45 | mvanbaak | isn't there an 'ignore' format entry ? |
| 12:04.54 | mvanbaak | wedhorn: gheh, we missed a lot of l->activesub = sub entries in chan_skinny ;) |
| 12:06.48 | wedhorn | nah, it was in the skinny_new which meant that every time a sub was created, it became the active sub |
| 12:08.20 | wedhorn | I think I can do better than the patch, but I think I should move the new_sub stuff of on its own - there's a lot of replication in creating a sub |
| 12:09.40 | mvanbaak | yup |
| 12:10.45 | wedhorn | and I'm not sure about the impact on the new phones. It could break them because of the different sub grabbing |
| 12:10.51 | eliel | mvanbaak: don't think so... :-( |
| 12:11.25 | wedhorn | anyway, I'm off to bed. Enjoy the rest of your day |
| 12:15.00 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:21.15 | mvanbaak | wedhorn: thanks |
| 12:21.24 | mvanbaak | wedhorn: I'll test with the 7960 and 7905 later today |
| 12:24.36 | eliel | mvanbaak: commited |
| 12:36.23 | mvanbaak | eliel: nice |
| 12:43.59 | eliel | Now we need to focus on argumentas and their description... |
| 12:44.17 | eliel | If you have an idea on where to show those arguments, please let me know. |
| 12:49.23 | mvanbaak | under the description in 'core show application foo' |
| 12:52.31 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:52.31 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 12:57.19 | eliel | mvanbaak: great |
| 13:27.57 | *** join/#asterisk-dev puzzled (n=patrick@dw77242119219.amsterdam-tc.dataweb.net) |
| 13:32.34 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-f07a6be1e3a0a2c7) |
| 13:32.34 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 13:33.27 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-bb00fede21ab0c3f) |
| 13:42.16 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 13:42.16 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 14:18.03 | seanbright | so why doesn't UpdateConfig check for malicious filenames? like ../../etc/passwd or whatever? |
| 14:21.44 | tzafrir_laptop | seanbright, GetConfig can read /etc/zaptel.conf :-( |
| 14:22.25 | tzafrir_laptop | Besides, don't tell me you run Asterisk as root :-( |
| 14:22.50 | seanbright | no, but some users do |
| 14:23.33 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:23.33 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:27.14 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:35.42 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 14:46.22 | mvanbaak | seanbright: good one |
| 14:49.16 | kpfleming | and checking for malicious filenames wouldn't accomplish a whole lot, because AMI users can do even more directly nasty stuff anyway |
| 14:49.32 | kpfleming | crunky |
| 14:49.35 | mvanbaak | yup |
| 14:49.49 | mvanbaak | only good way to combat that is to chroot the whole process |
| 14:50.31 | mvanbaak | in combination with a good systrace policy, and not running asterisk as root |
| 14:50.34 | mvanbaak | ;) |
| 14:54.19 | seanbright | mvanbaak: hmm? |
| 14:55.28 | mvanbaak | yeah I know |
| 14:55.35 | seanbright | what? |
| 14:55.39 | mvanbaak | lots of work |
| 14:55.45 | seanbright | "seanbright: good one" |
| 14:55.48 | seanbright | what was that in reference to? |
| 14:55.55 | mvanbaak | 16:18 <@ seanbright> so why doesn't UpdateConfig check for malicious filenames? like ../../etc/passwd or whatever? |
| 14:56.08 | seanbright | ok |
| 14:56.20 | seanbright | i guess "good one" means something else in .nk |
| 14:56.26 | seanbright | s/nk/nl/ |
| 14:56.43 | mvanbaak | it means: good question |
| 14:56.57 | seanbright | here it means: that was funny |
| 14:57.10 | mvanbaak | it can mean that as well here in .nl |
| 14:57.14 | seanbright | ah |
| 14:57.22 | mvanbaak | depends on the way you say it |
| 14:57.23 | seanbright | well that's how i read it, thus the "hmm?" ;) |
| 14:57.27 | mvanbaak | ah |
| 14:57.49 | mvanbaak | if only everyone in the world would have english as main language. |
| 14:57.54 | seanbright | i know |
| 14:57.59 | seanbright | it would be glorious |
| 14:58.08 | mvanbaak | yup |
| 14:59.19 | seanbright | so config_text_file_save calls stat() on the original filename to get the file mode and sets that on the new file when it is linked |
| 14:59.59 | seanbright | so if one were to change UpdateConfig to not try to unlink the original if it wasn't there |
| 15:00.06 | seanbright | what would the correct chmod be on the new file? |
| 15:00.58 | mvanbaak | 644 |
| 15:01.18 | mvanbaak | or, whatever the current umask tells you |
| 15:01.21 | jsmith | Wouldn't it be better to honor the umask value |
| 15:01.26 | jsmith | Yeah... |
| 15:01.37 | mvanbaak | that's even better |
| 15:05.51 | seanbright | so in other words, don't fchmod at all |
| 15:06.28 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 15:08.51 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-77b990aaf2e3cad2) |
| 15:08.51 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:09.28 | mvanbaak | seanbright: indeed |
| 15:09.45 | mvanbaak | seanbright: only in the case you described |
| 15:10.10 | mvanbaak | seanbright: I think it's nice to set the file permissions on the new file based on the file used as original |
| 15:10.21 | seanbright | which is what is done now |
| 15:10.27 | seanbright | meh... |
| 15:10.47 | seanbright | i'll just wait til this guy's license gets approved and look at his patch |
| 15:10.48 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 15:11.07 | mvanbaak | gheh |
| 15:11.27 | mvanbaak | blegh, I dont like php |
| 15:11.41 | mvanbaak | stupid inconsistent language without normal errorhandling |
| 15:12.20 | seanbright | if you use localeconv() or get_meta_tags() you can thank me |
| 15:12.21 | mvanbaak | but, it's my daytime job. so have to find a way to like it again ! |
| 15:12.38 | Qwell | switch to VB for a day |
| 15:12.46 | mvanbaak | Qwell: whehehehehe |
| 15:12.58 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:12.58 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:13.04 | mvanbaak | I know. we still have a couple of things in ASP here |
| 15:13.16 | mvanbaak | and yes, I totally know what you mean |
| 15:13.31 | seanbright | Set Qwell = Nothing |
| 15:13.40 | Qwell | though, going from C to PHP is probably the same type of thing |
| 15:15.41 | mvanbaak | Qwell: yes, basically |
| 15:15.55 | mvanbaak | I'm going to rewrite all shit to python or C I think |
| 15:16.06 | Qwell | tcl |
| 15:16.15 | mvanbaak | tcl isn't that bad |
| 15:16.17 | seanbright | yikes |
| 15:16.29 | seanbright | my *only* experience with tcl was eggdrop |
| 15:16.33 | mvanbaak | mine too |
| 15:16.35 | seanbright | and that was... oh... 10 years ago |
| 15:16.42 | seanbright | nay... 15 years ago |
| 15:16.44 | seanbright | christ i am old |
| 15:16.54 | mvanbaak | last eggdrop stuff I did was like 4 years ago |
| 15:17.50 | seanbright | i hated when people said "tickle-tk" |
| 15:17.56 | seanbright | wanted to punch them in the face. |
| 15:18.10 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:20.38 | *** join/#asterisk-dev km- (n=pgrace@fmservices.v6.fierymoon.com) |
| 15:20.55 | km- | anyone seen john todd around lately |
| 15:21.20 | Juggie | a few days ago yes |
| 15:22.51 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-159b65de3c3c6009) |
| 15:22.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:23.19 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:23.37 | km- | I wonder if any of the iax clients available for linux have native isn support |
| 15:23.42 | km- | that sounds like an easy enough project |
| 15:23.50 | km- | err, not linux, windows. |
| 15:29.06 | mvanbaak | going home. latero all |
| 15:29.58 | eliel | see ya |
| 15:47.42 | jameswf-home | home is where the heartburn is |
| 15:58.00 | mvanbaak | back |
| 16:00.07 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 16:02.32 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:05.39 | russellb | seanbright: top poster! |
| 16:06.27 | mvanbaak | lol |
| 16:09.23 | bkruse | mvanbaak: hello |
| 16:10.13 | mvanbaak | hey bkruse |
| 16:10.24 | bkruse | how's life and such |
| 16:10.34 | mvanbaak | busy but good :) |
| 16:10.36 | mvanbaak | and there ? |
| 16:10.51 | mvanbaak | gheh, codefreeze-lap just borked trunk |
| 16:11.01 | bkruse | Same same. Appdocsxml still cruising along? |
| 16:11.03 | bkruse | lol |
| 16:11.26 | mvanbaak | yeah, eliel is doing a lot of work on it |
| 16:11.53 | mvanbaak | we're close to show the real powers of it |
| 16:12.12 | mvanbaak | if that's done, I'm going to writeup on it so ppl can have a look at it etc |
| 16:12.24 | mvanbaak | if that comes out ok, I'm going to convert all the stuff |
| 16:12.29 | mvanbaak | and we're done |
| 16:12.30 | mvanbaak | :) |
| 16:12.45 | eliel | ouo! sound so simple, heh |
| 16:12.52 | mvanbaak | yup ! |
| 16:12.53 | mvanbaak | lol |
| 16:12.59 | mvanbaak | brb, have to pickup my wife |
| 16:15.14 | seanbright | russellb: hmm? |
| 16:17.56 | russellb | seanbright: google top posting, heh |
| 16:17.58 | jsmith | seanbright: Your emails to the list... http://www.river.com/users/share/etiquette/#inline |
| 16:17.59 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 16:18.59 | putnopvut | Hmm, I may have discovered a potential deadlock in app_chanspy...more to come... |
| 16:19.09 | seanbright | i'm not top posting |
| 16:19.12 | seanbright | wtf are you talking about? |
| 16:19.20 | seanbright | http://lists.digium.com/pipermail/asterisk-dev/2008-August/thread.html |
| 16:20.03 | russellb | http://lists.digium.com/pipermail/asterisk-dev/2008-August/034252.html |
| 16:20.06 | putnopvut | seanbright: I think they're referring specifically to the "ExtensionStatus" thread. |
| 16:20.12 | russellb | http://lists.digium.com/pipermail/asterisk-dev/2008-August/034250.html |
| 16:20.42 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 16:20.54 | seanbright | i'm confused |
| 16:20.58 | seanbright | they show threaded on that page to me |
| 16:22.41 | seanbright | oh |
| 16:22.51 | seanbright | you mean putting my response at the top of the reply? |
| 16:24.08 | seanbright | anyone: ping |
| 16:24.16 | jpeeler | yes that is what he means |
| 16:24.30 | seanbright | oh |
| 16:24.34 | seanbright | well that's silly |
| 16:24.54 | seanbright | i thought top posting was posting a response to a thread as a new post |
| 16:25.12 | putnopvut | seanbright: I'm not sure what the term for that is. |
| 16:25.34 | jpeeler | that's called hijacking a thread |
| 16:25.39 | seanbright | ok, well it won't happen again |
| 16:25.46 | seanbright | or it will |
| 16:25.52 | seanbright | and i won't apologize for it then, either. |
| 16:25.53 | seanbright | :) |
| 16:32.30 | *** join/#asterisk-dev ManxPower (n=manxpowe@176.sub-75-200-17.myvzw.com) |
| 16:34.56 | *** part/#asterisk-dev ManxPower (n=manxpowe@176.sub-75-200-17.myvzw.com) |
| 16:48.35 | eliel | mvanbaak: maybe the wrapping function could be exported for general use... |
| 16:49.24 | mvanbaak | eliel: hhmm. any case where it can be usefull ? |
| 16:50.43 | putnopvut | Okay, regarding that potential deadlock in app_chanspy I mentioned earlier, I think it's the real deal. Basically it's an issue of lock order between the spyee channel and the chanspy_ds lock. When a masquerade occurs and the spyee channel is the "clone" channel in the masquerade, the clone channel is locked first and then when chanspy's chan_fixup callback is called, the chanspy_ds is locked. However, within app_chanspy, the cha |
| 16:50.43 | putnopvut | nspy_ds_free function locks the two locks in the opposite order. I believe that if the spyee is transferred at the same time that the spyer hangs up, this could potentially create a deadlock. |
| 16:50.48 | putnopvut | Thoughts? |
| 16:50.50 | eliel | s/maybe the wrapping function could be exported for general use.../nothing heh/ |
| 16:51.11 | eliel | I though about core show applications |
| 16:51.18 | eliel | but is not neccesary. |
| 16:52.45 | eliel | mvanbaak: Do you want the argument description inside [description] or in another tag? |
| 16:53.22 | mvanbaak | hhmm |
| 16:53.27 | mvanbaak | what do you think |
| 16:53.32 | mvanbaak | [arguments] ? |
| 16:53.40 | mvanbaak | maybe |
| 16:53.57 | eliel | I like that, to show in [description] only what is inside that node |
| 16:54.05 | mvanbaak | yup |
| 16:54.14 | mvanbaak | that's my idea |
| 16:55.13 | codefreeze-lap | I must have been on vacation when 1.6.1 was forked.... I assume we use mergetrunk6 for 1.6.1 just like 1.6.0, right? |
| 16:55.26 | Qwell | codefreeze-lap: yep |
| 16:55.33 | Qwell | trunk > 1.6.0, and trunk > 1.6.1 |
| 16:56.00 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.static.dsl.tele.dk) |
| 16:56.11 | codefreeze-lap | Qwell: thanks. Checked repotools just in case of something weird like trunk > 1.6.0 > 1.6.1 |
| 17:03.45 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-9a0246c8d5796539) |
| 17:03.55 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:05.20 | codefreeze-lap | OK, sorry everybody! if anybody checked out or updated to revs between 138815 and 138845 (trunk), 138846 in 1.6.0, or 138853-138854 in 1.6.1, do an svn update to get back to normal! |
| 17:06.44 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:08.21 | jsmith | codefreeze-lap: If only that could return *me* to normal |
| 17:09.03 | seanbright | jsmith: unlikely |
| 17:09.38 | jsmith | sighs and wanders off to find some lunch |
| 17:09.41 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 17:09.47 | seanbright | didn't mean that |
| 17:09.50 | seanbright | jsmith <3 |
| 17:09.53 | codefreeze-lap | jsmith: you need to svn update in the jsmith repo |
| 17:10.26 | codefreeze-lap | that and a choc chip cookie should put you "right as rain" |
| 17:11.10 | seanbright | oracle? is that you? |
| 17:13.12 | codefreeze-lap | seanbright: only if by "oracle" you are referring to a database engine... |
| 17:13.51 | codefreeze-lap | uh, oh yeah, no diff. OK. |
| 17:29.21 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.184.154) |
| 17:30.10 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 17:31.40 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 17:34.49 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:44.16 | russellb | putnopvut: it should be safe to swap the lock order inside chanspy_ds_free |
| 17:44.23 | russellb | actually ... no ... |
| 17:44.32 | putnopvut | yeah, channel_spy uses that same order, too. |
| 17:45.04 | putnopvut | Swapping the order in chanspy_ds_free was my first idea too. |
| 17:45.38 | russellb | yeah, you can't change it |
| 17:45.46 | russellb | that would defeat the whole purpose of this stuff |
| 17:46.32 | russellb | so, we need to look at the other path .. |
| 17:46.58 | putnopvut | like, unlock the channel lock before locking the chanspy_ds lock? |
| 17:47.06 | putnopvut | in chan_fixup? |
| 17:47.33 | putnopvut | That seems unsafe, though. |
| 17:47.59 | russellb | it would be unsafe, yeah |
| 17:48.00 | russellb | crap. |
| 17:48.56 | russellb | I can't think of a good way to fix this right now ... |
| 17:49.05 | seanbright | rm -f apps/app_chanspy.c |
| 17:49.09 | seanbright | svn commit -m "Oh well" |
| 17:49.14 | putnopvut | seanbright: lol |
| 17:49.21 | mvanbaak | kpfleming: why did you rename the svnmerge -B and -A to -b and -a ? |
| 17:49.30 | russellb | if ast_channel was refcounted we could remove all of this datastore hack magic and the issue would be gone |
| 17:49.34 | russellb | sighs |
| 17:50.03 | russellb | seanbright: that wouldn't do anything. You'd have to svn rm it, just just rm. |
| 17:50.05 | seanbright | eyes russell's chan_refcount branch |
| 17:50.13 | seanbright | russellb: details schmetails |
| 17:50.17 | kpfleming | mvanbaak: what? |
| 17:50.33 | russellb | seanbright: yeah, and it's in conflict, out of date, and my time is compeltely booked for the near future |
| 17:50.44 | russellb | and it _certainly_ can't go in 1.4, anyway |
| 17:50.51 | seanbright | good point |
| 17:51.10 | mvanbaak | kpfleming: I'm looking at the diff between rev 18345 of the original svnmerge, and digiums svnmerge |
| 17:51.23 | codefreeze-lap | Murphy is going to go vote soon. Will soon return, but has to go like 13 miles to do so... |
| 17:51.23 | putnopvut | russellb: I appreciate your looking at the chanspy potential deadlock. Really all I want right now is confirmation that the deadlock is possible. I can work on a solution myself. |
| 17:51.36 | mvanbaak | kpfleming: I see the -B and -A flag in the original version are replaced by -b and -a in digium's version |
| 17:51.43 | russellb | putnopvut: yes, I agree with your analysis. |
| 17:51.52 | russellb | putnopvut: I have no suggestions on a fix, yet, but I'll think about it. |
| 17:51.54 | kpfleming | probably because we added a new option that works with them but couldn't be uppercase IIRC |
| 17:51.58 | putnopvut | russellb: all right. Thanks! :) |
| 17:52.34 | mvanbaak | makes it harder to update it to rev 31773 |
| 17:52.45 | kpfleming | no pain, no gain :-) |
| 17:52.55 | mvanbaak | whehehehe |
| 17:52.57 | seanbright | mvanbaak: if it was easy, anyone could do it. |
| 17:53.07 | mvanbaak | I'm working on it right now |
| 17:53.39 | mvanbaak | let's hope they will take the patch once I'm done with it |
| 17:53.48 | seanbright | subversion? |
| 17:53.57 | mvanbaak | yup |
| 17:54.04 | seanbright | nice |
| 17:56.57 | *** join/#asterisk-dev Dovid (n=Dovid@tony09-118-62.inter.net.il) |
| 17:57.54 | mvanbaak | ah, found it |
| 17:57.59 | mvanbaak | -P and -B |
| 17:58.14 | mvanbaak | to specify the merged and block props |
| 17:58.26 | kpfleming | yep |
| 17:58.43 | mvanbaak | -B was already in original svnmerge for 'show the blocked revision list' |
| 17:59.21 | mvanbaak | so you renamed it to -b, and to be consistent you changed -A to -a 'show both avail and blocked' |
| 17:59.43 | kpfleming | i knew it was something like that |
| 18:00.05 | seanbright | and then bounced it right back to the back of mr. big's limo |
| 18:00.08 | seanbright | it's almost too easy |
| 18:00.30 | seanbright | (wayne's world 2) |
| 18:06.31 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 18:19.33 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 18:20.10 | *** join/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 18:34.16 | codefreeze-lap | It'd be nice if svnmerge could handle merged/blocked problems, especially where, say, in 1.4, you add a fix and commit it.... You go to trunk....svn update it; svnmerge in your 1.4 fix; but before you can commit it, someone else commits a fix there. |
| 18:34.20 | codefreeze-lap | ...so, |
| 18:34.35 | codefreeze-lap | you get a dir-conflicts |
| 18:35.29 | codefreeze-lap | it'd be nice if some nifty command would fold your version of merged/blocked into the one you have in your copy... |
| 18:41.45 | russellb | svn 1.5 may make all of this moot .. |
| 18:42.02 | russellb | i haven't read up on the 1.5 merge tracking features enough yet |
| 19:03.09 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:10.10 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 19:10.40 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:10.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:25.18 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 20:02.49 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:09.23 | *** join/#asterisk-dev pedxing (n=batherto@209-207-73-169.ip.van.radiant.net) |
| 20:34.08 | *** part/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 20:34.25 | pedxing | Is anyone here familiar with chan_sip? I have a question about the transmit_refer() function. |
| 20:36.20 | russellb | ~ask |
| 20:36.21 | jbot | ask is, like, Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 20:36.52 | pedxing | Apologies for violating the code of conduct. |
| 20:37.01 | russellb | heh, it's all good |
| 20:37.07 | pedxing | I have a problem with failed blind transfers in SIP. |
| 20:37.28 | russellb | "~ask" is least amount of typing required to answer the question |
| 20:37.58 | pedxing | My application requests a transfer and expects to have the transfer fail if the line is busy, etc. But it always reports OK. |
| 20:38.14 | pedxing | There is a comment about a todo to fix this in the code. |
| 20:38.28 | pedxing | Has anyone fixed it? Have pointers as to how I can fix it myself? |
| 20:40.42 | pedxing | I asked at http://forums.digium.com/viewtopic.php?t=26029 but so far no answers. |
| 20:41.02 | russellb | I'm not aware of any current work in that area. |
| 20:41.15 | russellb | developers do not tend to use the forums |
| 20:41.34 | russellb | feel free to ask about implementation details here (which is hit or miss depending on time of day, what people are busy with at the moment) |
| 20:41.47 | russellb | or ask on the asterisk-dev mailing list, which will reach a bigger audience (lists.digium.com) |
| 20:42.32 | seanbright | russellb: for the life of me i *cannot* beat menuselect... |
| 20:42.57 | russellb | o.O |
| 20:43.29 | seanbright | that's one feature i didn't put in nmenuselect |
| 20:44.24 | seanbright | and you only get 1 life! weak! |
| 20:44.43 | russellb | "Game over! You win!" |
| 20:44.45 | russellb | pwnt |
| 20:44.55 | seanbright | i'm not at the console |
| 20:45.08 | seanbright | silly network |
| 20:45.43 | pedxing | Ok, thanks. Does anybody here have any thoughts about how to support section http://www3.tools.ietf.org/html/draft-ietf-sipping-cc-transfer-09#section-6.3.1 of the spec? |
| 20:46.28 | pedxing | Returning NOTIFY 486 Busy Here (etc) for a response to a transfer? |
| 20:51.18 | pedxing | Or another question. My application is the transferor, the one * extension is the transferee, another * extension is the transfer target. Is transmit_refer() the correct function to be looking at, or should I be looking at something that receives the REFER and triggers the INVITE? |
| 20:53.09 | kpfleming | what triggers the invite is the dialplan |
| 20:53.25 | kpfleming | yes, you need to look at handle_refer() or something like that, assuming your phone is sending REFER |
| 20:54.25 | pedxing | It is my application that is sending the REFER. |
| 20:55.28 | pedxing | An * extension calls in to my application, and after some voice prompts the application transfers them to talk to another extension. |
| 20:56.10 | pedxing | But if the second extension is busy, the application has no way of knowing. It just gets a NOTIFY 200 OK. |
| 20:57.32 | pedxing | I see no handle_refer anywhere in Asterisk 1.6.0. |
| 20:57.32 | kpfleming | what do you mean by 'application'? an asterisk application, or somethign running in another process or on another box that speaks SIP? |
| 20:57.40 | pedxing | The latter. |
| 20:58.29 | kpfleming | you need to learn to search a little better.... i said 'handle_refer or somethign like that', and the function is called handle_request_refer() |
| 20:58.39 | pedxing | Ahh, sorry. |
| 20:58.43 | kpfleming | because it handles REFER requests :-) |
| 20:59.44 | pedxing | Thanks for the pointer. I'll dig into that and come back if I have any questions. |
| 21:00.00 | kpfleming | ok |
| 21:03.25 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:42.36 | *** join/#asterisk-dev codefreeze-lap (n=murf@209-181-20-227.chyn.qwest.net) |
| 21:42.36 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 21:43.00 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 21:43.29 | *** part/#asterisk-dev codefreeze-lap (n=murf@209-181-20-227.chyn.qwest.net) |
| 21:55.10 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:14.04 | *** join/#asterisk-dev ibercom (i=581c6120@gateway/web/ajax/mibbit.com/x-4be12ac16488326b) |
| 22:37.33 | *** part/#asterisk-dev ibercom (i=581c6120@gateway/web/ajax/mibbit.com/x-4be12ac16488326b) |
| 22:42.42 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 22:52.16 | snuff-work | putnopvut: i see the guy has replicated his issue.. (13338) |
| 22:52.27 | putnopvut | Is that the chanspy one? |
| 22:52.29 | putnopvut | M13338 |
| 22:52.31 | snuff-work | mm |
| 22:52.32 | MuffinMan | [feedback] [Asterisk] Applications/app_chanspy 0013338: Crash in chanspy mutex reported by ruddy (Karma: neutral) http://bugs.digium.com/view.php?id=13338 |
| 22:52.34 | putnopvut | Yes... |
| 22:52.41 | *** join/#asterisk-dev DarkRift (n=dark@bas10-montreal02-1177582861.dsl.bell.ca) |
| 22:53.48 | snuff-work | oh what do ppl think of 13326.. extending the amount of chars shown for username |
| 22:54.00 | putnopvut | M13326 |
| 22:54.02 | MuffinMan | [feedback] [Asterisk] Channels/chan_iax2 0013326: [patch] Column width with cli command sip/iax2 show registry reported by ib2 (Karma: neutral) http://bugs.digium.com/view.php?id=13326 |
| 22:55.10 | snuff-work | either we can still limit the size to the 10-12 chars via cli and have AMI has unrestricted length aka 80chars or somethin ? |
| 22:55.14 | putnopvut | Ah, chan_iax2. I can't imagine why the name is limited to just 10 chars of output. It seems like it should be either a larger buffer or should be dynamic. |
| 22:56.08 | snuff-work | see attached patch.. its for 'neatness' in cli i'm guessing |
| 22:56.45 | snuff-work | but maybe.. its worth making a 'ami' version of show registry |
| 22:56.55 | snuff-work | which doesn't have the restriction |
| 22:59.03 | putnopvut | Really, I think both should probably be extended. |
| 22:59.12 | putnopvut | but that may just be me :) |
| 23:00.07 | seanbright | putnopvut: how about a 'sorted dictionary' too? |
| 23:00.08 | seanbright | :) |
| 23:00.22 | putnopvut | that seems silly :) |
| 23:00.48 | snuff-work | i haven't run asterisk in almost a month.. only compile errors for my astobj2 project :) |
| 23:01.08 | seanbright | silly schmilly |
| 23:01.25 | seanbright | skip lists were invented at UMD |
| 23:01.33 | seanbright | which would have been my alma mater had i graduated |
| 23:01.35 | putnopvut | Yes, I saw that. By William Pugh. |
| 23:01.41 | seanbright | aye |
| 23:01.56 | putnopvut | I read several of his papers on it before I decided to use that as the sorted container for astobj2. |
| 23:02.58 | seanbright | i like algorithms like that |
| 23:03.10 | seanbright | simple additions to existing data structures that drastically improve performance |
| 23:03.40 | putnopvut | Yes, and I figured out that with Asterisk's linked list API, a skip list is a very easy thing to implement. |
| 23:03.42 | seanbright | i once had to write a b+tree implementation for a client that stored dictionary terms |
| 23:03.52 | seanbright | and we also wanted a way to access the keys by index |
| 23:04.21 | seanbright | so a friend and i sat down and came up with a way of doing it (next to each substree pointer we kept a count of all the children in the entire subtree) |
| 23:04.39 | seanbright | and 2 months later i was searching the interweb and found an identical implementation :-/ |
| 23:05.43 | putnopvut | I luckily never actually had to implement anything more than a binary search tree in college. Any more advanced trees were covered in data structure classes, but we never actually had to program them :) |
| 23:06.04 | seanbright | b+trees are hot |
| 23:06.19 | putnopvut | Yeah, I recall learning about those in my database class. |
| 23:06.23 | seanbright | all of the data is in the leaf nodes |
| 23:06.27 | seanbright | yeah |
| 23:06.38 | putnopvut | Right. Don't the leaf nodes actually point to each other, too? |
| 23:06.42 | seanbright | yup |
| 23:06.44 | seanbright | bonus! |
| 23:06.45 | seanbright | :) |
| 23:06.58 | seanbright | hmmmm |
| 23:07.01 | seanbright | now that i think about it |
| 23:07.02 | putnopvut | That's where the + comes from, I think. |
| 23:07.14 | seanbright | there is your sorted dictionary |
| 23:07.18 | seanbright | but i digress |
| 23:09.34 | snuff-work | M13098 |
| 23:09.36 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_agent 0013098: [patch] p->ackcall not reset when agent logs out reported by davidw (Karma: +1.50) http://bugs.digium.com/view.php?id=13098 |
| 23:10.04 | snuff-work | was left by bbryant waiting on review from someone else |
| 23:10.36 | putnopvut | snuff-work: I'll take a look. |
| 23:11.25 | snuff-work | k :) |
| 23:11.40 | putnopvut | patch seems good. I'll commit it. |
| 23:11.49 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:11.49 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:11.55 | snuff-work | hello russ |
| 23:12.34 | russellb | waves |
| 23:13.20 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:14.55 | snuff-work | while i'm talking bugs.. |
| 23:14.58 | snuff-work | M13165 |
| 23:14.59 | MuffinMan | [new] [Asterisk] Resources/res_features 0013165: [patch] Add various app_dial features to app_bridge reported by tim_ringenbach (Karma: +7.50) http://bugs.digium.com/view.php?id=13165 |
| 23:15.10 | snuff-work | any comments about this persons patch |
| 23:26.43 | putnopvut | app_bridge, eh... |
| 23:27.09 | putnopvut | I guess I'm hesitant to touch that because I don't know what file's bridging branch means with regards to app_bridge. |
| 23:27.18 | russellb | nothing right now |
| 23:27.21 | file | nothing right now |
| 23:27.28 | putnopvut | file: buy him a coke |
| 23:27.36 | russellb | as long as those features don't depend on stuff happening inside of app_dial, it should be ok |
| 23:27.49 | russellb | in other words, as long as the features enabled are entirely processed within the bridge code, it's fine |
| 23:32.20 | putnopvut | Yeah, all those options were bridge_config options, so I suppose they're fine. |
| 23:35.03 | russellb | merge away, then, i guess |
| 23:43.00 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 23:46.22 | jpeeler | is the CLI thread reported in core show threads output? |
| 23:46.45 | putnopvut | let's find out... |
| 23:47.31 | putnopvut | jpeeler: I believe it is. I think it's the "listener" thread listed as starting in asterisk.c |
| 23:47.57 | jpeeler | ok, then how about the editline stuff |
| 23:48.51 | putnopvut | hmmm, not sure about that. |
| 23:48.53 | jpeeler | i thought the listener thread was for network connections... |
| 23:48.56 | seanbright | heh... http://pastebin.ca/1179178 |
| 23:49.02 | seanbright | russellb: Qwell: ^^ |
| 23:49.37 | seanbright | it's a little... verbose |
| 23:50.39 | *** join/#asterisk-dev easycrypt (n=Savek@lak-31-154.wohnheime.ruhr-uni-bochum.de) |
| 23:50.59 | jpeeler | i guess i am quite wrong! |
| 23:51.39 | putnopvut | jpeeler: actually... |
| 23:51.53 | easycrypt | hi @all |
| 23:51.58 | putnopvut | It appears that cli and editline stuff is handled at the bottom of the main function in asterisk.c and that is not listed in core show threads. |
| 23:52.04 | russellb | that is correct |
| 23:52.07 | russellb | if you run in console mode |
| 23:52.23 | putnopvut | right. listener is apparently for remote connections like you thought, jpeeler. |
| 23:52.33 | russellb | nods |
| 23:52.52 | jpeeler | tries non-console mode |
| 23:53.07 | russellb | wonders what jpeeler is chasing down ... |
| 23:53.11 | putnopvut | same here... |
| 23:54.07 | jpeeler | i'm really just trying to see which threads are actually responsible for making a request using originate |
| 23:54.23 | putnopvut | jpeeler: ah |
| 23:54.23 | jpeeler | i already know the answer, but the core show threads output confused me initially |
| 23:54.37 | russellb | oic |
| 23:54.38 | easycrypt | does anyone in here have a pointer on how to write a channel driver for asterisk? |
| 23:54.51 | russellb | easycrypt: heh, the best place to start is one of the simpler channel drivers |
| 23:55.05 | russellb | easycrypt: the console channel drivers are the most straight forward. chan_alsa/chan_oss/chan_console |
| 23:55.26 | easycrypt | k - will start reading there |
| 23:55.43 | russellb | specifically, if you want to get to the bare bones, look for ast_channel_tech |
| 23:56.09 | russellb | you'll see that the channel driver implements a table of functions that define an asterisk channel technology |
| 23:56.21 | russellb | and then load_module/unload_module registers/unregisters that interface with the asterisk core |
| 23:57.18 | russellb | However, there is no decent documentation on what each API call is expected to do other than the example implementations |
| 23:57.37 | russellb | what are you interested in implementing? |
| 23:58.56 | jpeeler | launching asterisk without -c still doesn't appear to show all the threads. where am i being dumb? |
| 23:59.22 | russellb | what thread are you looking for? |