| 00:27.36 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 00:27.36 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 00:41.07 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 00:41.07 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:17.13 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 01:17.13 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:46.09 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:46.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:19.47 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:19.47 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:21.20 | *** join/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 02:51.51 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 03:10.56 | *** part/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 03:18.29 | *** join/#asterisk-dev voipmonk (n=voipmonk@74-132-202-71.dhcp.insightbb.com) |
| 03:19.29 | *** part/#asterisk-dev voipmonk (n=voipmonk@74-132-202-71.dhcp.insightbb.com) |
| 03:51.34 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 04:42.13 | *** part/#asterisk-dev korihor (n=korihor@190.205.251.61) |
| 05:29.39 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.122) |
| 05:59.05 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.12.42) |
| 06:18.09 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:18.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:26.50 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:37.01 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:37.01 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:45.41 | oej | morning |
| 06:45.52 | snuff-work | morning oej |
| 07:12.31 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:19.38 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 07:26.11 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 07:27.07 | tzafrir_laptop | I have a question about the preffered place for hiding bodies^Wstate information |
| 07:27.33 | tzafrir_laptop | Under http://svn.digium.com/svn/asterisk/team/tzafrir/monitor-rtp-14 , |
| 07:28.08 | tzafrir_laptop | e.g. in http://svn.digium.com/svn/asterisk/team/tzafrir/monitor-rtp-14/res/res_monitor.c monitor2rtp_start() |
| 07:29.30 | tzafrir_laptop | I (ab)use the filename part of the channel's monitor data structure to store the state informaition |
| 07:30.11 | tzafrir_laptop | e.g.: rtp_state_rx = (struct monitor_rtp_state *)(monitor->read_stream->filename); |
| 07:30.51 | tzafrir_laptop | This actually works in 1.4, but breaks when forward=porting the code to trunk |
| 07:31.12 | tzafrir_laptop | So where should I store the extra state information? |
| 07:37.58 | snuff-work | trunk it probably fails cause of the 'rtp engine' code correct? |
| 07:41.18 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:41.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:45.32 | tzafrir_laptop | snuff-home, I'm not using the main RTP code. See the SVN log of that branch for reasoning and information |
| 07:45.56 | tzafrir_laptop | Basically I want to just dump an RTP stream. I don't want to wait for a response from the other side |
| 07:46.51 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.122) |
| 07:46.51 | tzafrir_laptop | I don't have a proper VoIP session |
| 07:49.10 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.214) |
| 07:53.39 | snuff-work | mm i cant help.. as usual :( sorry tzafrir_laptop |
| 07:56.53 | tzafrir_laptop | looks at oej |
| 07:57.16 | oej | Just got a strange feeling and zoomed this window to front |
| 07:57.45 | oej | You are doing cool stuff, tzafrir. Sending RTP out into space. |
| 07:59.06 | tzafrir_laptop | so where can I put such state information? |
| 08:06.07 | snuff-work | channel datastore? |
| 08:23.29 | *** join/#asterisk-dev fenlander (n=fenlande@82.152.81.57) |
| 08:48.39 | kaii | M14538 |
| 08:48.41 | MuffinMan | [closed] [Asterisk] Utilities/General 0014538: [patch] astcanary does not exit when asterisk dies reported by KNK (Karma: +11.00) https://issues.asterisk.org/view.php?id=14538 |
| 09:03.55 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 09:04.56 | tzafrir_laptop | yikes. using datastore seems like a rather complicated solution to the problem here |
| 09:05.35 | tzafrir_laptop | the monitor struct is already included in the channel. I want to pass information along side it |
| 09:06.17 | tzafrir_laptop | I want the information to be part of the monitor of the channel. Not of the channel (in case of complicated inheritance) |
| 09:30.19 | oej | I guess you will have to extend the monitor structure, seems like the safest bet |
| 10:16.38 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-69-079.xd-dynamic.ctbcnetsuper.com.br) |
| 10:47.07 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 10:47.07 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:23.11 | *** join/#asterisk-dev korihor (n=korihor@190.205.251.61) |
| 11:28.53 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:28.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:34.25 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:34.25 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:35.58 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) |
| 11:59.59 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:59.59 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:25.41 | snuff-home | who wants to help with stupid discard qualifiers (x86) |
| 12:26.12 | kpfleming | i don't know what they are |
| 12:28.07 | *** join/#asterisk-dev voipmonk (n=voipmonk@74.132.202.71) |
| 12:29.41 | snuff-home | http://pastebin.com/d385f1134 |
| 12:29.59 | snuff-home | i think it might be to do with const qualifiers? |
| 12:30.40 | snuff-home | that's a very small excerpt from the code.. |
| 12:31.06 | *** part/#asterisk-dev voipmonk (n=voipmonk@74.132.202.71) |
| 12:31.07 | kpfleming | probably yes |
| 12:31.15 | snuff-home | i've updated the big mgcp patch for 15159 |
| 12:31.26 | kpfleming | something has been declared 'const char *' and is being passed to a function that is declared 'char *' |
| 12:31.49 | snuff-home | not easy when formatting in the whole patch was inconsistant |
| 12:32.10 | kpfleming | but you can't pass a 'const char *' to strncpy()... are ast_str objects being used in that code? |
| 12:33.26 | snuff-home | 4369: var->name = ast_strip(strncpy(var->name, input + offset, var_len)); |
| 12:33.49 | kpfleming | oh, that's awful |
| 12:33.54 | snuff-home | but yer.. i think his code is really just playing fast n loose |
| 12:34.23 | snuff-home | a lot of the code isn't great.. |
| 12:36.35 | snuff-home | have u seen a lot of the mgcp code..? its not a huge amount better from what i've seen |
| 12:36.38 | snuff-home | :) |
| 12:38.43 | snuff-home | i will fix at least those bad errors of him mauling argv's from ast_cli |
| 12:57.19 | snuff-home | mm.. there is some really dodgey stuff |
| 12:58.00 | snuff-home | i will try to make it more better |
| 13:00.30 | kpfleming | no, i have not looked at the mgcp code in a very long time, but i understand it is not an example of good coding practices :-) |
| 13:02.00 | *** join/#asterisk-dev voipmonk_ (n=voipmonk@74-132-202-71.dhcp.insightbb.com) |
| 13:06.15 | *** part/#asterisk-dev voipmonk (n=voipmonk@74-132-202-71.dhcp.insightbb.com) |
| 13:08.15 | snuff-home | :) |
| 13:14.53 | snuff-home | omg.. bad bad stuff going on in this guys patch now i look at what he's really doing |
| 13:14.56 | snuff-home | :( |
| 13:22.27 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 13:27.05 | *** join/#asterisk-dev bbryant (n=brett@68.208.65.50) |
| 13:27.05 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 13:38.08 | *** join/#asterisk-dev elfguy516 (n=elfguy51@96.56.103.35) |
| 13:38.22 | *** part/#asterisk-dev elfguy516 (n=elfguy51@96.56.103.35) |
| 13:39.10 | *** join/#asterisk-dev bbryant (n=brett@68.208.65.50) |
| 13:39.10 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 13:49.36 | *** join/#asterisk-dev msetim (n=setim@189.32.44.21) |
| 13:54.57 | *** join/#asterisk-dev jsmith (n=nnjsmith@asterisk/training-and-documentation-guru/jsmith) |
| 13:54.57 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:01.17 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:01.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:02.16 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:02.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:03.40 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:03.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:04.02 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:04.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:08.24 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733667.dsl.bell.ca) |
| 14:14.49 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:14.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:43.10 | *** join/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 14:57.06 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:59.38 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:59.38 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:34.39 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:35.46 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:35.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:36.13 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:36.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:39.13 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) |
| 15:39.14 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:42.11 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:42.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:47.52 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:52.36 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 15:55.56 | *** join/#asterisk-dev bbryant (n=brett@68.208.65.50) |
| 15:55.56 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 16:07.42 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 16:07.52 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 16:07.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 16:28.53 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:29.08 | *** part/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:29.21 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:37.29 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:37.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:39.58 | *** part/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 16:49.17 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 17:03.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:03.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:07.41 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:07.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:09.18 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:09.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:10.42 | *** join/#asterisk-dev errotan (n=errotan@5403E426.catv.pool.telekom.hu) |
| 17:11.12 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:11.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:14.34 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:14.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:16.24 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:19.17 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:19.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:38.20 | *** join/#asterisk-dev wildzero-cw (n=Kristija@f053115023.adsl.alicedsl.de) |
| 17:45.29 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 17:47.46 | wildzero-cw | hello, something was wrong with svnmerge with changeset r210777 (app_fax), "Blocked revisions" this changeset so is not in 1.6.2, only in trunk |
| 17:49.39 | file | it wasn't a bug fix, so it did not go into 1.6.2 |
| 17:52.18 | oej | But 1.6.2 isn't released, right? |
| 17:52.19 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:52.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:52.20 | oej | Or is it? |
| 17:52.37 | putnopvut | oej: nope, it's in beta status, but feature-frozen. |
| 17:52.57 | oej | Hmm. Must have missed that mail to the -dev list. |
| 17:53.13 | oej | Or does such information only get published on IRC nowadays? |
| 17:53.45 | putnopvut | I have no idea if there was a specific announcement for 1.6.2, but the release process states that when a new version is branched, it is feature-frozen. |
| 17:54.25 | putnopvut | And whenever the betas for 1.6.2.0 have been released, there have been announcements. |
| 17:54.39 | oej | Ok, but I've seen so many committs to 1.6.2 so I thought there was a change. Sorry. |
| 17:54.55 | kpfleming | yeah, bug fix commits |
| 17:55.20 | wildzero-cw | but it was supposed to? because svn log -r210778 in 1.6.2 branch show's it |
| 17:56.23 | file | it was blocked from that branch, as the commit message says at the top |
| 17:57.42 | wildzero-cw | ok, one more patch i need to add to my backport patch folder for 1.6.2 ... |
| 17:58.09 | file | why do you need it? |
| 18:02.35 | wildzero-cw | as i remember, it fix a flooded debug log, this is the main reason for me |
| 18:04.35 | russellb | commit asterisk 210777 |
| 18:04.38 | MuffinMan | [210777] Committed by kpfleming on 2009-08-06T16:07:15.144592Z: Minor improvements to app_fax. |
| 18:04.38 | MuffinMan | .. |
| 18:04.38 | MuffinMan | ..This patch makes some small changes to handle watchdog timeouts in a better way, |
| 18:04.38 | MuffinMan | ..and also uses a 'cleaner' method of including the spandsp header files. |
| 18:04.39 | MuffinMan | .. |
| 18:04.41 | MuffinMan | ..(closes issue #14769) |
| 18:04.44 | MuffinMan | ..Reported by: andrew |
| 18:04.45 | MuffinMan | ..Patches: |
| 18:04.48 | MuffinMan | .. app_fax-20090406.diff uploaded by andrew (license 240) |
| 18:04.51 | MuffinMan | .. v1-14769.patch uploaded by dimas (license 88) |
| 18:04.53 | MuffinMan | ..Tested by: freh, deti, caspy, dimas, sgimeno, Dovid |
| 18:04.56 | MuffinMan | .. |
| 18:04.58 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=210777 |
| 18:15.18 | russellb | oej: which developer prompted your request? |
| 18:16.16 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:16.37 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:19.51 | oej | russellb: Marquis |
| 18:20.13 | oej | I haven't seen you introduce anyone for a while... Please don't forget. |
| 18:20.38 | russellb | Thanks. |
| 18:21.32 | Marquis42 | oej: I thought you might have been talking about me. I'm not a 'committer' in the proper sense. Russell just gave me some space for my distributed events via PubSub work (btw, thanks again!). |
| 18:22.08 | russellb | but you're still doing work in the open, and people will wonder who you are. :-) |
| 18:22.08 | oej | Well, I think everyone needs a presentation. Now I got to know your project. Pls tell me more |
| 18:22.58 | oej | Even if someone just gets access to 1.0 branches, I think they deserve a presentation... ;-) |
| 18:23.26 | Marquis42 | Basically, it's distributed device state and MWI (a la Russell's existing AIS work) via PubSub nodes. It should be more suitable to event distribution than AIS, and it also has the opportunity for XMPP client integration. |
| 18:23.39 | russellb | in the future, I'll ask people to introduce themselves on the -dev list when they get commit access (or I may introduce them if it's a new employee or something.) |
| 18:23.51 | oej | That's way cool, Marquis42. I am very interested in following that work |
| 18:24.03 | Marquis42 | ERr... That should say "event distribution over the WAN"... AIS is obviously adequately suitable for event distribution over a LAN. |
| 18:24.46 | Marquis42 | oej: Glad to hear there is interest from people (leifmadsen also expressed interest). Mostly I'm just glad I'm not the only loon who thinks it might be a cool idea. ;) |
| 18:25.11 | oej | I've been toying around using XMPP for manager. Using pubsub for events makes a lot of sense. |
| 18:25.50 | russellb | yep, in hindsight, I should have used XMPP in the first place instead of AIS |
| 18:25.52 | oej | which pubsub server are you going to use |
| 18:26.00 | russellb | I had grand visions of using AIS for much more than I did |
| 18:26.09 | Marquis42 | Feel free to check it out and hack away at it. Let me know what you think. It's certainly in a "working" state right now, at least of device state. MWI should be added later this week, and then barring any real problems I just have some rough edges to clean up. |
| 18:27.05 | Marquis42 | The PubSub server I'm testing most heavily against is Tigase, because it seems to be the only XEP-0248 implementation that is sufficiently complete. The code is written so that you should be able to use any XEP-0060 or XEP-0248-compliant pubsub server. |
| 18:27.41 | Marquis42 | There are two different modes, set by the collection_nodes configuration variable in jabber.conf. |
| 18:27.56 | oej | The important question here after having your work and Russell's work with the internal event structure is whether that architecture fits the bill. Does it work? You're one of the few that has worked with it. |
| 18:28.43 | oej | Hmm. Why are udev devices under /etc... Messes with my subversion backup. |
| 18:28.51 | russellb | o.O |
| 18:29.39 | oej | Ejabberd just released a pubsub server addition. And there's a free one using component mode. Valhalla or something similar. |
| 18:29.47 | oej | I don't know the compliance state for them though. |
| 18:30.43 | putnopvut | needs to research XMPP more... |
| 18:30.56 | russellb | putnopvut: no, you need to work on CCSS! :-p |
| 18:30.57 | oej | XMPP is cool |
| 18:31.05 | putnopvut | russellb: heh, I didn't say now :P |
| 18:31.14 | russellb | I'm just messin' |
| 18:31.34 | Marquis42 | Yeah, I originally started using ejabberd /trunk (which becamse the 2.1.0 betas now in testing), but there are couple of things not supported which I needed for what I was doing with PubSub. In hindsight, I may have to go back and see if the current implementation really needs those features. I'd prefer to have the code work with as many pubsub servers as possible. |
| 18:33.10 | oej | That's a good strategy. |
| 18:33.18 | oej | Find out if you can discover extra features with disco |
| 18:33.26 | oej | To have adaptive code |
| 18:34.04 | Marquis42 | Unfortunately, at least as the spec is written right now, what was missing from ejabberd's XEP-0248 implementation wasn't something I'd find out from a disco#info request. :( |
| 18:35.12 | Marquis42 | But it may be unnecessary anyway. Certainly one of the things I intend to do once I'm feature-complete is to run tests against as many pubsub servers as I can get my hands on and see if I can broaden support. |
| 18:35.57 | oej | Well, we can also use Asterisk to push those developers |
| 18:36.11 | oej | Have you discussed this with process one? They're good at listening. |
| 18:37.12 | Marquis42 | I haven't discussed it with them yet, no. The fellow who actually wrote the XEP-0248 support for ejabberd insists that what I want is 'optional'. I disagree. :) But at any rate, it doesn't do it right now. |
| 18:38.23 | Marquis42 | FWIW, if you subscribe to a collection node with subscription type 'node', it never actually notifies you when a node is associated with that collection.... :/ |
| 18:38.59 | russellb | well that's no good .. |
| 18:39.06 | Marquis42 | I concur! :) |
| 18:40.23 | Marquis42 | The good news, is that for Asterisk you don't even have to use collection nodes. Regular pubsub nodes work fine, most especially if what you're worried about are solely other Asterisk instances. Collection nodes are big win, however, if you want individual clients to be able to subscribe to nodes associated with their devices (or voicemail messages). |
| 19:16.31 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:17.53 | putnopvut | astobj2 is so convenient |
| 19:18.03 | putnopvut | Just sayin' :) |
| 19:23.20 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 19:23.20 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:28.20 | *** join/#asterisk-dev ctooley (n=ctooley@c-71-228-176-237.hsd1.al.comcast.net) |
| 19:28.20 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 19:28.50 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 19:32.30 | russellb | putnopvut: DUDE. |
| 19:32.41 | russellb | I think Qwell and I just found the filestream destructor crash. |
| 19:32.48 | leifmadsen | russellb: !!! |
| 19:32.52 | file | russellb: what what WHAT |
| 19:32.55 | russellb | YES |
| 19:33.00 | russellb | it's like ... at least 5 open issues |
| 19:33.01 | leifmadsen | ftw! |
| 19:33.01 | Qwell | M15041 |
| 19:33.03 | MuffinMan | [assigned] [Asterisk] Addons/format_mp3 0015041: Crash on attended transfer reported by maxnuv (Karma: neutral) https://issues.asterisk.org/view.php?id=15041 |
| 19:33.10 | Qwell | russellb: check out the bt there |
| 19:33.34 | russellb | yep, same bug |
| 19:33.53 | russellb | so get this ... the problem (we think), is a bug in format_mp3. |
| 19:33.58 | russellb | which could be fixed with a 1 line change. |
| 19:34.14 | russellb | though the patch I'm about to post changes a bit more to remove some no-op code ... |
| 19:34.41 | russellb | ... AST_FRIENDLY_OFFSET FAIL |
| 19:35.20 | putnopvut | russellb: !!!!! |
| 19:35.54 | putnopvut | wow, format_mp3... |
| 19:36.03 | putnopvut | I never would have thought to look there. |
| 19:36.07 | file | ditto |
| 19:36.12 | russellb | mad props to Qwell |
| 19:36.13 | putnopvut | russellb: pastebin your patch when you have it. |
| 19:36.18 | russellb | will do |
| 19:36.28 | putnopvut | gives an imaginary high-five hug to Qwell |
| 19:36.30 | Qwell | he already has it! he's just not sharing yet :p |
| 19:36.37 | russellb | I'm compiling :-p |
| 19:36.50 | file | uh huh |
| 19:36.56 | putnopvut | Good effing lord, if that fixes the problem... |
| 19:36.57 | file | you should be standing on a chair sword fighting with Qwell then |
| 19:37.22 | russellb | I am _really_ confident that this is it |
| 19:37.25 | russellb | it perfectly explains it |
| 19:37.37 | Qwell | how many other places do you think it's possible that caused crashes in? |
| 19:37.57 | russellb | unlikely to cause crashes unless they were filestream related |
| 19:38.05 | russellb | but other filestream related crashes, for sure |
| 19:38.14 | putnopvut | So was the bug not a refcount error? |
| 19:38.18 | russellb | no. |
| 19:38.23 | Qwell | putnopvut: nothing like that at all. |
| 19:38.28 | russellb | http://pastebin.com/f5b8986c8 |
| 19:38.29 | Qwell | you'll cry when you see the patch. |
| 19:38.30 | putnopvut | wow |
| 19:38.44 | russellb | so the heart of the bug is the last change in the patch |
| 19:38.51 | russellb | specifically = s->fr.data = s->buf; |
| 19:38.59 | russellb | that should have been ... s->fr.data = s->buf + AST_FRIENDLY_OFFSET; |
| 19:39.02 | russellb | that's it. |
| 19:39.08 | Qwell | M15735 |
| 19:39.09 | MuffinMan | [feedback] [Asterisk] Channels/chan_agent 0015735: Asterisk Chrashes Daily reported by thom4fun (Karma: neutral) https://issues.asterisk.org/view.php?id=15735 |
| 19:39.10 | putnopvut | Now, why did that cause the crash? |
| 19:39.13 | Qwell | that too |
| 19:39.33 | russellb | because a consumer of the frame will assume that s->buf - AST_FRIENDLY OFFSET is ready for its use |
| 19:39.35 | Qwell | putnopvut: it's possible for s->f to have been overwritten with garbage... |
| 19:39.41 | Qwell | so fclose would have just crapped itself |
| 19:39.44 | russellb | however, in fromt of s->buf is the ast_filestream structure itself |
| 19:39.45 | putnopvut | Ah, that's why it was always fclose that caused it. |
| 19:39.54 | file | right. |
| 19:39.57 | putnopvut | OH HELL |
| 19:39.58 | file | fun. |
| 19:39.59 | Qwell | putnopvut: it wasn't always fclose though. Look at 15041 |
| 19:40.01 | file | Qwell: nice find! |
| 19:40.06 | putnopvut | Yeah I totally get it now. |
| 19:40.25 | putnopvut | Qwell: how in the hell did you find that? |
| 19:40.40 | Qwell | I was looking at the first part of his patch, thinking the problem was there |
| 19:40.45 | Qwell | russellb put two and two together |
| 19:41.04 | Qwell | M15719 |
| 19:41.05 | Qwell | and that |
| 19:41.06 | MuffinMan | [acknowledged] [Asterisk] Core/FileFormatInterface 0015719: Crash in ast_readaudio_callback reported by rgj (Karma: neutral) https://issues.asterisk.org/view.php?id=15719 |
| 19:41.23 | Qwell | (orig_chan_name is at the end of struct ast_filestream) |
| 19:41.37 | putnopvut | Wow, I think 5 open issues may be an underestimate. |
| 19:41.44 | Qwell | it's like 7 so far |
| 19:41.45 | russellb | so we're at 7 issues so far that this should close |
| 19:42.24 | putnopvut | anxiously waits the commit followed by the flood of messages in the inbox. |
| 19:42.28 | russellb | :-) |
| 19:42.37 | putnopvut | s/waits/awaits/ |
| 19:42.41 | russellb | I think I'm going to post the patch ... |
| 19:42.45 | russellb | and let people test |
| 19:42.46 | putnopvut | boo |
| 19:42.48 | putnopvut | :P |
| 19:42.53 | putnopvut | Good idea. |
| 19:42.57 | russellb | well that way I can commit with (closes issue #) tags instead of (issue #) |
| 19:43.01 | russellb | that'll be more fun :-) |
| 19:43.23 | putnopvut | Yeah, no need to be impatient. I imagine aragon will be quick to tell you if the patch fixes the issue on 15109 |
| 19:43.38 | russellb | yeah |
| 19:44.10 | putnopvut | I wonder if this just will fix any of the across-the-board format_mp3 weirdness issues... |
| 19:44.23 | russellb | this has always been broken for 1.4 and later |
| 19:44.25 | putnopvut | That was a weird way of saying that, but I think I got my point across. |
| 19:44.27 | russellb | so yeah, it may |
| 19:46.28 | Qwell | hmm |
| 19:46.35 | Qwell | russellb: you said 64 bytes? |
| 19:47.07 | Qwell | an ast_filestream is only like 48 on 32-bit. it could have written before that even? |
| 19:47.33 | russellb | it could have, yes |
| 19:47.33 | putnopvut | So it could have corrupted some moh or channel fields. |
| 19:47.40 | Qwell | putnopvut: channel, yeah |
| 19:47.46 | russellb | though only if something actually tried to use all 64 |
| 19:47.48 | Qwell | OMG! |
| 19:47.58 | Qwell | look at what is before chan->stream. |
| 19:48.05 | russellb | no no, ast_filestream is not _in_ ast_channel |
| 19:48.11 | putnopvut | yeah, just a pointer. |
| 19:48.12 | russellb | it would have corrupted off in ??? land |
| 19:48.13 | putnopvut | I just realized. |
| 19:48.14 | Qwell | chan->stream is a filestream |
| 19:48.23 | Qwell | err, eh? |
| 19:48.28 | Qwell | nm :D |
| 19:48.35 | putnopvut | But it would have caused corruption on whatever adjoined the filestream in the heap. |
| 19:48.39 | putnopvut | Which could be...anything. |
| 19:48.50 | putnopvut | or nothing. |
| 19:48.52 | putnopvut | it is a mystery |
| 19:48.59 | russellb | closes every crash in mantis ... |
| 19:49.02 | russellb | :-p |
| 19:49.03 | putnopvut | yes! |
| 19:49.03 | Qwell | w00t! |
| 19:51.06 | putnopvut | So...I suppose that valgrind never complained because we were writing to valid memory the whole time. |
| 19:51.13 | *** join/#asterisk-dev zeroHalo (n=zeroHalo@173.13.92.17) |
| 19:51.21 | putnopvut | It's not as though the filestream had been freed yet. |
| 19:51.26 | russellb | correct |
| 19:52.08 | putnopvut | Wow, it's amazing how it all just ... makes perfect sense now. |
| 19:52.24 | putnopvut | Of course, watch this not fix the crash :P |
| 19:52.32 | russellb | lol .. |
| 19:52.36 | russellb | IT WILL |
| 19:52.48 | zeroHalo | #15109? |
| 19:52.53 | Qwell | zeroHalo: among others. |
| 19:53.04 | zeroHalo | Awesome... Saw the updates. |
| 19:53.44 | Qwell | you know |
| 19:53.54 | Qwell | saying 15609 would be pretty f'ing convenient |
| 19:53.59 | Qwell | err |
| 19:54.01 | Qwell | saying it's related |
| 19:54.33 | Qwell | I doubt it is, but with chan->sched being before chan->stream, I'd like to hope otherwise :P |
| 19:54.41 | putnopvut | heh |
| 19:54.46 | Qwell | especially considering the trouble we've had with sched stuff.. |
| 19:54.47 | putnopvut | M15609 |
| 19:54.50 | MuffinMan | [acknowledged] [Asterisk] Core/Channels 0015609: WARNING[23025]: channel.c:952 __ast_queue_frame: Exceptionally long voice queue length queuing to Local reported by aragon (Karma: +4.25) https://issues.asterisk.org/view.php?id=15609 |
| 19:54.53 | Qwell | BUT! it was aragon that reported that. |
| 19:55.08 | Qwell | convenient :P |
| 19:56.06 | russellb | I have marked it as related |
| 19:56.09 | russellb | as it is possible, for sure |
| 19:56.25 | putnopvut | So, 15109 has 9 related issues listed... |
| 19:56.30 | putnopvut | Wow |
| 19:56.44 | zeroHalo | epic |
| 19:57.00 | putnopvut | What's so weird is that this issue has to have existed for a long time. |
| 19:57.07 | Qwell | putnopvut: since 1.4 |
| 19:57.31 | putnopvut | Since 1.4 was created, you mean? |
| 19:57.45 | russellb | well, since at some point during 1.4 development |
| 19:57.48 | Qwell | putnopvut: it was changed in trunk before 1.4 was branches |
| 19:58.14 | putnopvut | So the bug has been there for probably about 3 years or maybe a bit more, then. |
| 19:58.23 | Qwell | pretty much |
| 19:58.25 | russellb | >_< |
| 19:58.28 | kpfleming | wholey cheese |
| 19:58.36 | putnopvut | kpfleming: you're late to the party |
| 19:58.40 | russellb | meeting time! |
| 19:58.49 | kpfleming | no, i know about the party |
| 19:59.01 | kpfleming | no meeting for me! |
| 19:59.18 | jsmith | Party? |
| 19:59.20 | jsmith | Meeting? |
| 19:59.25 | jsmith | misses all the fun |
| 19:59.44 | putnopvut | On a scale of meeting to party, how would you rate this get-together? |
| 20:01.34 | Marquis42 | Somewhere between shindig and soiree perhaps? |
| 20:02.59 | putnopvut | I'm a watcher on probably at least 5 of the affected issues. So I'm going to get flooded with mail when the commit goes in to fix all of them. I'm going to love it. |
| 20:04.28 | Qwell | format_jpeg is probably busted too, not that it's ever used |
| 20:07.17 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:11.44 | kpfleming | tzafrir_laptop: i see a number of coding guidelines issues there... you might want to run over that code with 'indent' or something to try to get it closer our preferred style |
| 20:12.01 | tzafrir_laptop | ok |
| 20:12.36 | Qwell | M15616 |
| 20:12.38 | MuffinMan | [new] [Asterisk] General 0015616: random crashes reported by rgj (Karma: neutral) https://issues.asterisk.org/view.php?id=15616 |
| 20:12.47 | Qwell | maybe? thirdcrash-bt.txt almost certainly |
| 20:13.25 | putnopvut | Possibly. Appears to be using format_wav, though. |
| 20:13.47 | Qwell | not in thirdcrash though |
| 20:14.04 | Qwell | there's no indication there, and he does mention MoH |
| 20:14.36 | putnopvut | Ask if he's using format_mp3. If he is, then I'd say it's related. |
| 20:16.11 | Qwell | I don't see it loading in his BT |
| 20:22.48 | zeroHalo | We're not using format_mp3 in 15109, see bt_scrubbed.txt |
| 20:23.49 | Qwell | zeroHalo: That backtrace doesn't look like the others. |
| 20:25.09 | zeroHalo | yikes. |
| 20:25.21 | zeroHalo | been a while since I've looked. |
| 20:27.52 | zeroHalo | I'm not even sure what I posted... I'll look at another more recent bt and see if it's loaded. |
| 20:34.46 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.12.42) |
| 20:47.30 | zeroHalo | I've got one that looks similar for 1.4.26.1 but will take me a while to scrub it. |
| 20:47.45 | zeroHalo | no format_mp3 |
| 20:51.17 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:51.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:56.56 | Qwell | M15460 |
| 20:56.57 | Qwell | another one |
| 20:56.58 | MuffinMan | [new] [Asterisk] PBX/General 0015460: Asterisk Crashed When made a attended Transfer reported by marhbere (Karma: neutral) https://issues.asterisk.org/view.php?id=15460 |
| 20:57.04 | putnopvut | damn, son! |
| 21:01.36 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 21:01.36 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 21:03.16 | Qwell | russellb: app.s, does linear_generator() look correct? |
| 21:04.02 | putnopvut | app.s? You're looking at the assembly code? :P |
| 21:04.10 | eliel | lol |
| 21:04.15 | Qwell | yes! |
| 21:04.17 | Qwell | app.c :p |
| 21:04.38 | Qwell | the AST_FRIENDLY_OFFSET/2 makes my brain hurt |
| 21:04.41 | *** join/#asterisk-dev wedhorn (n=nnnnnnnn@123-243-209-34.static.tpgi.com.au) |
| 21:05.17 | putnopvut | Qwell: I see one problem but it's not major. |
| 21:05.27 | putnopvut | Still looking though. |
| 21:05.28 | Qwell | wassat? |
| 21:05.49 | putnopvut | the if statement halfway through should be using AST_FRIENDLY_OFFSET/2 instead of AST_FRIENDLY_OFFSET |
| 21:06.06 | putnopvut | The bug there is that even though there may be room for the samples in the buffer, we may say there isn't. |
| 21:06.11 | putnopvut | Not a huge deal. |
| 21:06.42 | putnopvut | I don't know why we're using AST_FRIENDLY_OFFSET/2 throughout though... |
| 21:07.07 | Qwell | and why .offset isn't being set to /2 |
| 21:07.16 | putnopvut | heh, that too :) |
| 21:07.25 | Qwell | looks fishy |
| 21:07.29 | putnopvut | I agree. |
| 21:08.02 | putnopvut | I don't know offhand what sorts of problems it would cause, maybe missing the first 16 samples of audio or something? |
| 21:10.03 | Qwell | putnopvut: well, if something tried to write to f.data - f.offset |
| 21:10.22 | Qwell | it would write to like...somewhere |
| 21:11.06 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.69) |
| 21:11.12 | russellb | thactually, the if statement is correct |
| 21:11.23 | russellb | in fact, all of that function is correct |
| 21:11.31 | Qwell | that code has been there forever too |
| 21:11.33 | russellb | the / 2 has to do with the fact that it's used with short |
| 21:11.38 | Qwell | r2956, heh |
| 21:12.03 | russellb | short buf[AST_FRIENDLY_OFFSET / 2]; is AST_FRIENDLY_OFFSET bytes |
| 21:12.29 | Qwell | but it's doing pointer math after that |
| 21:12.59 | russellb | pointer math on a short * |
| 21:13.59 | tzafrir_laptop | A small SIP question: |
| 21:14.05 | kpfleming | no such thing |
| 21:15.25 | tzafrir_laptop | in the rtp monitoring branch we send RTP streams and for each stream we send dummy INVITE and BYE SIP messages |
| 21:16.06 | tzafrir_laptop | According to someone from Orex this hack should not only be good enough for their recording code, |
| 21:16.14 | *** join/#asterisk-dev xpot-mobile (n=james@66-182-88-85.static.sdyl010.digis.net) |
| 21:16.43 | tzafrir_laptop | but also allow wireshark to get "sip calls" from listening to such streams |
| 21:17.26 | tzafrir_laptop | Sadly the wireshark doesn't work |
| 21:18.02 | tzafrir_laptop | Any idea what we could try to do to convince wireshark that this is a "SIP call"? |
| 21:28.36 | kpfleming | no, you won't be able to |
| 21:28.59 | kpfleming | wireshark will want to dissect a proper 3-way SIP INVITE/200 OK/ACK exchange before treating it as a SIP call |
| 21:39.27 | kpfleming | who wants to lay claim to this gem? ---> ast_copy_string(buf, "0", sizeof("0")); |
| 21:43.30 | eliel | svn blame |
| 21:43.41 | kpfleming | chan_sip.c in 1.4 |
| 21:44.50 | jsmith | Oooh... that's nice |
| 21:47.51 | eliel | m..g.r...an |
| 21:47.54 | eliel | hides |
| 21:47.57 | kpfleming | there are 2 problems with it... know what they are? (there are no prizes) |
| 21:49.40 | jsmith | Sure... the quotes around the 0? |
| 21:49.46 | kpfleming | nope |
| 21:49.53 | jsmith | Or was it meant to be \0? |
| 21:49.58 | kpfleming | nope |
| 21:50.01 | jsmith | throws out random answers |
| 21:50.04 | Qwell | the fact that it's using ast_copy_string at all? |
| 21:50.10 | kpfleming | nope |
| 21:50.13 | eliel | sizeof("0") = 2? |
| 21:50.17 | kpfleming | close |
| 21:50.25 | kpfleming | sizeof("0") != strlen("0") |
| 21:50.26 | jsmith | sizeof("0") = 1 |
| 21:50.35 | jsmith | Oh... |
| 21:50.37 | jsmith | duh! |
| 21:51.00 | kpfleming | although we had a discussion about this a few weeks ago... it's possible the compiler is smart enough to fix this common problem |
| 21:51.25 | eliel | mmmm, without optimization it is saying that sizeof("0") == 2 |
| 21:51.30 | kpfleming | but in any case, when copying into a buffer with ast_copy_string, you don't specify the length of the string to be copied, you specify the size of the buffer to copy into |
| 21:51.39 | kpfleming | eliel: so it is smart enough then |
| 21:51.50 | kpfleming | so that part is OK, although still looks wrong |
| 21:51.51 | jsmith | Of course... compilers are smart enough to fix all kinds of problems... until you try to do something creative and get second-guessed by the compiler |
| 21:51.56 | eliel | yes |
| 21:51.59 | eliel | sizeof(buf) |
| 21:52.06 | kpfleming | because technically sizeof("0") == sizeof(char *) |
| 21:52.26 | eliel | kpfleming, for this kind of error, there is an attribute to check if the passed sizeof is the size of the buffer |
| 21:52.39 | eliel | (though) |
| 21:52.50 | kpfleming | for some functions, yes |
| 21:52.58 | kpfleming | anyway, back to your fun |
| 21:53.04 | kpfleming | my brain is full of t.38 pain |
| 21:53.30 | jsmith | Looks like there are several instances of that in chan_sip.c |
| 21:53.48 | jsmith | A possible one in pbx_dundi.c |
| 21:54.13 | jsmith | and res_agi.c |
| 21:59.02 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@202.49.106.158) |
| 22:01.34 | *** part/#asterisk-dev zeroHalo (n=zeroHalo@173.13.92.17) |
| 23:28.31 | philipp64 | corydon76-dig: noooo... don't close out 15169 yet. |
| 23:28.39 | philipp64 | it's been confirmed on 1.4. it's not yet been confirmed on 1.6. |
| 23:28.48 | philipp64 | so it's premature to mark it "closed". |
| 23:29.34 | philipp64 | jsmith: -pedantic -Wall is your friend. |
| 23:33.33 | *** join/#asterisk-dev w9sh (n=sph@adsl-068-209-117-205.sip.asm.bellsouth.net) |
| 23:41.24 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 23:41.24 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:48.36 | philipp64 | noooo! |
| 23:49.05 | philipp64 | tilghman: put it back into 'open' or 'feedback' state. |
| 23:49.19 | philipp64 | or maybe 'fixed' (but not confirmed). |