| 00:50.50 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 01:32.13 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:32.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:12.55 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:34.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 04:34.01 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 04:36.28 | *** join/#asterisk-dev ccesario_ (~ccesario@187.17.166.162) |
| 06:09.30 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:12.38 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 07:17.04 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:17.06 | schmidts | good morning |
| 08:14.14 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4dca:32db:2926:5b83) |
| 08:43.31 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:43.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:49.06 | wdoekes2 | good morning |
| 08:50.27 | wdoekes2 | so.. I have never looked at one of those 'core show locks' before. if there are three threads "Waiting for Lock..MUTEX 123", then there should be one additional thread holding MUTEX 123, right? |
| 08:51.02 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-pufkipbecjzdlzdz) |
| 08:51.41 | wdoekes2 | oh.. that's linenum |
| 08:51.46 | wdoekes2 | haha |
| 09:11.04 | schmidts | haha ;) |
| 09:20.29 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 09:20.29 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 09:20.47 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-adfohnlfniqhhpot) |
| 09:20.57 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 09:21.29 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-gdhpysnbsuokpvne) |
| 10:15.19 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 10:57.51 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 10:59.44 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-stgugkaaqijdvejk) |
| 11:08.12 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-prqibxlywrcshpty) |
| 11:44.51 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-gewbjfddzqiqfgxu) |
| 11:45.23 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-zsgkqfcxkvqzhzxp) |
| 12:04.55 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 12:25.58 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-onnfsbxabxrmgcij) |
| 12:31.00 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-jkkwqbavetkgdwwz) |
| 12:34.30 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 12:48.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:48.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:02.14 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.153.86) |
| 13:30.29 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4dca:32db:2926:5b83) |
| 13:59.24 | *** join/#asterisk-dev anny__ (~chatzilla@77.42.241.114) |
| 14:05.45 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-otgsssaljduffhem) |
| 14:06.10 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:06.10 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:21.51 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 14:29.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:29.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:32.04 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mnfpllaavqidvtym) |
| 14:32.04 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:44.43 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:44.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:02.08 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:02.08 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:08.55 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:08.55 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:23.39 | anny__ | how can i install theora codec to asterisk? |
| 15:23.40 | seanbright | sruffell: appears to be working just fine |
| 15:24.18 | sruffell | seanbright: hmm…ok, thanks for testing. What was the original problem? Were your users complaining of audio problems? |
| 15:24.30 | sruffell | or was it just something odd you noticed while looking at something else? |
| 15:25.51 | seanbright | we're chasing down various audio issues, and that is what we noticed while debugging |
| 15:25.59 | sruffell | mjordan: can you make it so I can change the reporter on an ASTERISK jira issue? I would like to open an issue against codec_dahdi but make seanbright the reporter. |
| 15:26.10 | sruffell | do you know if that helped with the audio issues? |
| 15:26.19 | seanbright | it appears to have helped, yes. |
| 15:26.28 | seanbright | there is a (i believe) separate issue that we are working on now |
| 15:26.30 | sruffell | ok….and sorry about that then. |
| 15:26.35 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-xgkpinjfvevmzzsi) |
| 15:26.52 | kpfleming | anny__: i have never seen a theora codec module/patch for asterisk |
| 15:26.52 | seanbright | no need to apologize |
| 15:27.12 | seanbright | the latest issue is that calls break up when they are being chanspy'd on, but not when they are not |
| 15:27.16 | seanbright | which is odd |
| 15:28.11 | anny__ | kpfleming: there are some posts on the net that claim to have made iaxclient which only supports theora as a video codec work with asterisk |
| 15:28.50 | WIMPy | From what I see, a switch statement is used on every priority, not just to find a mathing extension. Is that a bug or a feature? |
| 15:28.59 | seanbright | [Box A] <-> IAX2 (g729) <-> [Box B] <-> SIP (g729) <-> ["The Cloud (tm)"] |
| 15:29.19 | anny__ | kpflemming: i installed the latest stable release of asterisk 1.8 and when i issued the command core show codecs, no theora is listed |
| 15:29.31 | seanbright | doing a ChanSpy against Box B causes the calls to IAX2 leg to break up a bit |
| 15:30.02 | seanbright | trunking is turned on so i suspect something timing related |
| 15:30.03 | kpfleming | anny__: then you need to talk to the people who made those posts about how they added theora support |
| 15:30.24 | kpfleming | WIMPy: the dialplan does the full matching process for every priority. that's how it works. |
| 15:30.37 | kpfleming | it's not a 'find a matching extension, stick with it' process |
| 15:30.46 | mjordan | sruffell: I'm not sure I can, but I can try - which issue? |
| 15:30.56 | kpfleming | anny__: that's why i told you there is no theora support... there isn't any |
| 15:31.20 | seanbright | sruffell: this might be a really stupid question, but - is there a way to make dahdi use kernel timing even if there is an card installed that provides timing? |
| 15:31.37 | WIMPy | Wouldn't it make sense to restrict that to only priority 1? I see a lot of dundi queries while the priorities are traversed. That doesn't seem to make sense. |
| 15:31.51 | anny__ | kpfleming: it seems so, are you aware of any iax phone that supports video |
| 15:32.42 | WIMPy | Is there any use for that? |
| 15:34.35 | kpfleming | anny__: i am not |
| 15:35.17 | anny__ | kpfleming: ok thx |
| 15:35.26 | kpfleming | WIMPy: there are many types of dialplan constructions that use different patterns for the same extension at different priorities. they might use specific numbers for priority 1, for example, but then a wildcard pattern for priorities 2 and later |
| 15:35.51 | WIMPy | Sure. I do that sometimes. |
| 15:36.11 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:36.11 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 15:36.20 | WIMPy | But that is clearly beyound any switch statement. |
| 15:36.59 | kpfleming | well, it's not. a switch statement is just a way of deferring the extension/priority lookup to some other system/process. |
| 15:37.06 | kpfleming | it doesn't change the way the dialplan lookup operates. |
| 15:37.14 | kpfleming | you might want it to be that way, but it doesn't :-) |
| 15:37.47 | WIMPy | It slows things down considerably. |
| 15:38.22 | sruffell | seanbright: it will…..by default now |
| 15:38.39 | sruffell | core timer is used whenever a card is not providing timing, and it will switch back and forth as necessary. |
| 15:38.51 | sruffell | when switching from card timing to core timing, there will be audio loss, but not the other way. |
| 15:41.03 | WIMPy | That reminds me that I'd like some more documentation on dahdi timing. Esp. the question wether timing is always per card? |
| 15:41.33 | sruffell | nods |
| 15:41.47 | sruffell | I think rmeyerriecks was working on something like that for the wiki. |
| 15:42.01 | seanbright | sruffell: so if you have a FXS/FXO card installed, and you're on a SIP to SIP call, core timing will be used? |
| 15:42.23 | seanbright | meaning the call that you are on is not TDM |
| 15:42.40 | sruffell | seanbright: no, if there is a card in the system calling dahdi_receive…it will be used. If that card "stops working" for whatever reason, the core of dahdi will notice and switch to kernel timers. |
| 15:43.01 | seanbright | gotcha |
| 15:43.22 | file | so you think |
| 15:43.35 | seanbright | so if the card is in the machine and working - card timing. otherwise core. |
| 15:44.13 | sruffell | yes…currently. There are ideas floating around about exposing timing domains but that's still a ways off…. |
| 15:44.50 | seanbright | k |
| 16:02.04 | WIMPy | BTW: When i unload pbx_dundi, I get a lot of locking errors. Is that of interest to someone? http://wimpy.yeti.dk/pastebin |
| 16:02.40 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 16:11.17 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:11.18 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:13.16 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 16:20.02 | WIMPy | If someoene remembers my issue with disappering digits while dialling, I found the cause. |
| 16:20.58 | WIMPy | The issue came with the combination of a loopback lswitch and a dundi switch when overlap dialling. |
| 16:21.31 | WIMPy | When replacing the lswitch by an eswitch the issue went away, but processing tooke excessive amounts of time. |
| 16:22.31 | WIMPy | I still don't understand the difference here. Even less now that I know the cause: It was a broken key for one dundi peer. |
| 16:28.42 | leifmadsen | people still use "switch" ? |
| 16:29.10 | WIMPy | If you want match-as-you-go, there's no way around it. |
| 16:31.15 | WIMPy | For me that's a requirement for user friendlyness. |
| 16:33.26 | *** part/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 16:34.00 | WIMPy | But there seems to be an issue with the pattern matchin in the loopback anyway. I saw a lot of queries for numbers that didn't match the given pattern. |
| 16:36.40 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 16:38.00 | WIMPy | Oh, and that's the reason I can't use E.164 since the switch was removed. :-( |
| 17:04.06 | seanbright | russellb: quick question about a commit you made 4 years ago... |
| 17:04.17 | seanbright | :D |
| 17:05.10 | seanbright | actually, it wasn't yours... i retract |
| 17:05.37 | *** join/#asterisk-dev ccesario_ (~ccesario@177.35.100.170) |
| 17:11.42 | anonymouz666 | I think devs these days does not remember a commit made 4 minutes ago :D |
| 17:14.37 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 17:16.15 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 17:18.50 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:30.12 | seanbright | could knowing that a remote asterisk had LOW_MEMORY defined in any way compromise security? |
| 17:30.23 | seanbright | make it vulnerable in any way? |
| 17:37.30 | elred_ | why ? |
| 17:42.18 | seanbright | why what? |
| 17:44.20 | file | it shouldn't make it vulnerable, but as always DoS through resource exhaustion is probably possible some way |
| 17:45.26 | seanbright | sure |
| 17:45.35 | seanbright | thanks |
| 17:46.37 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 18:25.09 | seanbright | russellb: any reason not to just remove IAX_OLD_FIND completely at this point? |
| 18:25.34 | russellb | not IMO |
| 18:26.19 | seanbright | alrighty |
| 19:04.53 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 19:17.20 | seanbright | so if you have trunk frames coming through where some of the the samples are 20ms and others are 40ms |
| 19:17.35 | seanbright | would it make sense to change trunkfreq to 40ms? |
| 19:22.29 | russellb | i'm not sure it matters much ... it may end up having to be more frequent anyway to keep the packet sizes small enough |
| 19:22.36 | russellb | depending on how many concurrent calls yo uhave |
| 19:24.24 | seanbright | right |
| 19:24.29 | seanbright | that makes sense |
| 19:30.08 | seanbright | send_a_pathetic_reply |
| 19:30.11 | seanbright | that would be funnier |
| 19:35.07 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 19:44.10 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 19:44.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:58.20 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 19:58.21 | Qwell | seanbright: I laughed. Out loud. |
| 20:01.59 | file | Qwell, *you* laughed? |
| 20:03.18 | *** join/#asterisk-dev Jamuel (~Adium@207.86.77.166) |
| 20:07.46 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 21:28.07 | seanbright | so what exactly does internal_timing do? |
| 21:32.01 | seanbright | nevermind - i can read |
| 22:16.01 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 22:16.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:24.33 | russellb | seanbright: is that still an option? |
| 22:24.50 | russellb | IMO it shouldn't be optional, should just be the default behavior as long as some timing source is availble |
| 22:34.02 | seanbright | it is the default behavior, yes. |
| 22:34.19 | seanbright | i've just never entirely understood it's purpose, although now i do |
| 22:50.39 | russellb | seanbright: and knowing is half the battle? |
| 22:50.48 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 22:50.52 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 22:50.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:37.54 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mnfpllaavqidvtym) |