| 00:43.51 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:43.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:48.19 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:48.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:52.18 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:52.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:12.50 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 05:18.39 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-81-197.ctcweb.net) |
| 09:28.05 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 09:28.53 | *** part/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 09:42.05 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-81-197.ctcweb.net) |
| 10:57.19 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 11:59.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:59.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:11.50 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 12:13.08 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:79ae:ff7f:deff:bfef) |
| 12:13.18 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hxznchboyexcarhs) |
| 12:13.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:21.46 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 12:55.14 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:55.14 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 13:10.41 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 14:01.34 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 14:01.34 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 14:08.10 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 14:28.14 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:28.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:38.37 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:38.37 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 15:49.30 | opticron | this discussion makes me wonder what it would take to create a wrapper app that could arbitrarily put a DTMF-capturing layer in front of any application |
| 15:49.52 | opticron | it would probably be gross |
| 15:50.49 | opticron | or maybe doable with dial and a local channel |
| 15:53.04 | kpfleming | a frame hook would make that quite easy |
| 16:15.40 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:24.03 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 16:29.06 | elguero | I have a simple one-liner here, https://issues.asterisk.org/jira/browse/ASTERISK-19759, is it okay to commit without need for review or maybe someone take a quick here when they have a chance? |
| 16:33.46 | Qwell | Officially, all patches should be reviewed by someone other than the author. There are cases though (such as this one), where it's super obvious that the code is right. |
| 16:35.57 | elguero | ya, that is what I figured but wanted to make sure... sounds like a good to go then; thanks for the quick confirmation... |
| 16:37.00 | Qwell | It's hard to draw a clear line. It would be silly to say that a review would need be needed to fix a typo, for instance. |
| 16:37.43 | Qwell | (unless the typo was the word "colour", heh) |
| 16:37.57 | elguero | right... that would be silly |
| 16:38.13 | elguero | hey, colour should be color :) |
| 16:38.18 | Qwell | exactly :) |
| 16:38.20 | Kobaz | looks like a simple enough change |
| 16:38.32 | Kobaz | but then again it's the simple changes that go and break everything and make the world end |
| 16:41.59 | seanbright | pabelanger: nice. if you're just doing english, it would be pretty easy i think. |
| 16:57.01 | pabelanger | seanbright: so if i understand correctly, there is no ability to transfer or dial an extension from within externalivr. |
| 16:57.07 | pabelanger | That would be handled via the dial plan |
| 17:13.09 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:13.24 | seanbright | pabelanger: correct |
| 17:13.41 | seanbright | you could set a variable from externalivr and then return to dialplan |
| 17:13.46 | seanbright | V,whatever=hi |
| 17:14.43 | sruffell | seanbright: thanks again for testing the codec_dahdi patch. I appreciate it. |
| 17:22.01 | seanbright | sruffell: k |
| 17:35.29 | seanbright | sruffell: err, no problem |
| 17:36.54 | sruffell | :) |
| 18:13.09 | *** join/#asterisk-dev Victor_Yure (~IceChat77@unaffiliated/victoryure/x-837844) |
| 18:56.52 | opticron | anyone feel like reviewing the code for a replacement for SIP_CAUSE? https://reviewboard.asterisk.org/r/1822/ |
| 19:27.51 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 19:28.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:39.08 | Kobaz | i'm having nasty nasty problems with too many open file handles |
| 19:39.08 | Kobaz | looks like media udp sockets are not getting cleaned up |
| 19:39.12 | Kobaz | asterisk 25638 pbx 583u IPv4 67525770 0t0 UDP *:16797 |
| 19:39.12 | Kobaz | asterisk 25638 pbx 584u IPv4 66802478 0t0 UDP *:16739 |
| 19:39.22 | Kobaz | bajillion open handles that look like that from lsof |
| 19:43.36 | Kobaz | no deadlocks, which is good |
| 19:43.42 | Kobaz | some sort of leak in chan_sip |
| 19:56.49 | opticron | I'm looking at an issue like that right now, actually, but I've been unable to reproduce it |
| 19:56.55 | opticron | happens in transfer situations? |
| 19:58.02 | Kobaz | probably |
| 19:58.09 | Kobaz | this system has lots of transfers |
| 19:58.31 | Kobaz | i've only had one other system that this happened |
| 19:58.45 | Kobaz | but it wasn't the same problem i'm pretty sure |
| 19:58.49 | opticron | could be the same thing I'm seeing in https://issues.asterisk.org/jira/browse/ASTERISK-19579 |
| 19:59.21 | Kobaz | the other problematic box was running 1.6.0.26 which had some problems with leaks and memory corrution with moh |
| 19:59.27 | opticron | though that issue provides me a debug log and seemingly unrelated output from "sip show channels" |
| 20:00.29 | opticron | s/seemingly/completely/ (it looks like it might be from a different box entirely) |
| 20:01.55 | Kobaz | this may be a hint i don't know |
| 20:01.56 | Kobaz | but |
| 20:02.06 | Kobaz | on this same box i had problems with sip channels not going away when they should have |
| 20:02.25 | Kobaz | like there's a sip to sip call, polycom to sip link to pstn |
| 20:02.41 | Kobaz | and then the polycom hangs up but there's still a sip channel talking to the pstn sip channel |
| 20:02.50 | Kobaz | sending one-way audio |
| 20:03.03 | Kobaz | i turned on rtptimeout, it'll be a while before i know if it helps |
| 20:06.43 | Kobaz | maybe the call hung up while it was on hold and was sending hold audio |
| 20:57.33 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:57.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:07.39 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:07.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:20.14 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 21:21.18 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 21:24.53 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:24.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:31.30 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hxznchboyexcarhs) |