| 00:03.23 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 00:03.23 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 00:04.46 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 00:04.46 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 03:18.44 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 03:18.44 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 04:41.05 | *** join/#asterisk-dev irroot (~irroot@197.169.85.18) |
| 05:47.18 | BlackBishop | yawns |
| 05:50.52 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-147-133.bvtn.or.frontiernet.net) |
| 06:10.18 | *** join/#asterisk-dev oej (~olle@132.177.252.99) |
| 06:10.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.12 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:06.37 | jmls | interesting. Can anyone help debugging ami events ? |
| 07:06.52 | jmls | 1) what's the point in sending a newaccountcode event when the old and new are the same ? |
| 07:08.13 | snuff-work | we can? we dont check events we generate? |
| 07:10.51 | jmls | just see no point in generating and publishing data when there is nothing to do. I suppose the real question is why asterisk thinks that the accountcode has changed when it hasn't |
| 07:23.45 | snuff-work | ;) |
| 07:24.18 | snuff-work | heads home |
| 07:35.18 | irroot | snuff-work have good one |
| 07:35.24 | irroot | i just got to work :P |
| 07:36.52 | BlackBishop | too |
| 07:37.01 | BlackBishop | milk & cookies time. |
| 07:37.15 | *** join/#asterisk-dev oej_ (~olle@132.177.252.9) |
| 07:37.15 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 07:37.27 | jmls | milk and cookies are for bed time. |
| 07:37.29 | jmls | wait. |
| 07:37.37 | jmls | no. red wine is for bedtime ;) |
| 07:46.00 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 07:46.47 | jmls | scenario: 3cx calls xlite. xlite parks call. xlite dials 701 to pickup call |
| 07:46.49 | jmls | http://pastebin.com/VQHqaeSF |
| 07:47.05 | jmls | look at lines 17-27 : why so many link/unlink events ? |
| 07:47.53 | jmls | is that expected ? |
| 08:07.19 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:07.19 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:21.52 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 08:21.54 | schmidts | good morning |
| 08:25.14 | jmls | urgh. another inconsistency. If a call is parked, and someone picks up, the unparkedcall event is generated. If, however, the parked call times out and redials the origin, UnParkedCall is not generated |
| 08:26.29 | jmls | is that an oversight, bug or feature ? ;) |
| 08:31.23 | irroot | well a feature is normally a bug someone finds useful or uses by accidnet |
| 08:31.42 | schmidts | irroot +1 :D |
| 08:31.43 | irroot | windows of cause is rich in features and bug free :P |
| 08:41.22 | jmls | hhe |
| 08:41.51 | jmls | however, should the unparked event be generated ? I think that it should |
| 09:03.42 | irroot | if a event happens and there is a AMI event matching it should be fired jmls |
| 09:04.12 | irroot | even if the event is a bug/fault to begin with either fix it or mark it as feature/quirk |
| 09:11.10 | jmls | wait |
| 09:12.12 | jmls | "ParkedCallTimeOut" |
| 09:13.14 | jmls | it would be better with an event "UnparkedCall" , reason: [pickup|timeout] |
| 09:13.30 | jmls | but I can live with it now that I've found it ;) |
| 09:23.52 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.37.149) |
| 09:31.38 | jmls | mmmm. maybe CEL is the answer |
| 09:33.16 | irroot | indeed that makes some sence |
| 09:33.28 | irroot | ok LIKE is not SQL portable is it ? |
| 09:35.09 | wdoekes2 | yes it is |
| 09:35.25 | irroot | ok cool |
| 09:35.43 | wdoekes2 | the problem is just that some realtime backends aren't sql (e.g. res_curl) |
| 09:36.08 | irroot | ok so LIKE is not RT portable |
| 09:36.36 | irroot | and to do a search "LIKE" , "%" is a bad thing to do |
| 09:36.51 | irroot | rather check for null in the code |
| 09:43.35 | wdoekes2 | well.. it should be RT portable.. LIKE is already used by some modules. see http://lists.digium.com/pipermail/asterisk-dev/2011-October/051793.html |
| 09:46.06 | wdoekes2 | jmls: poke! we're you going to comment on that thread that you weren't using res_config_curl anymore? ;) |
| 09:46.16 | wdoekes2 | *were, ouch |
| 09:51.55 | irroot | wdoekes2 indeed that thread is what i recalled thx |
| 10:43.37 | irroot | cool got dynamic and realtime queue members playing nice together |
| 11:06.25 | *** join/#asterisk-dev oej_ (~olle@132.177.252.9) |
| 11:06.25 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 11:14.15 | *** join/#asterisk-dev oej_ (~olle@2620:0:2ef0:710:75a4:949:2ce4:dc63) |
| 11:14.15 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:00.30 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:17.20 | *** join/#asterisk-dev kpfleming (kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:17.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:19.06 | irroot | i guess its a bad thing to have a module unload crash asterisk |
| 13:20.44 | Kobaz | probably |
| 13:21.46 | irroot | ast_taskprocessor_unreference <- always deref before calling this |
| 13:41.21 | schmidts | irroot i just added some load to the 1.8 server and i hope it will still works fine :D |
| 13:41.48 | irroot | cool should do with what you been running so far |
| 13:41.49 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 13:42.00 | schmidts | around 1200 more peers and around 1400 subscriptions |
| 13:42.04 | schmidts | i really hope so |
| 14:17.05 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:17.05 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.42 | schmidts | irroot still locking good, now i have moved every of my 750 virtuals pbxs to the 1.8 server 3400 sip subscriptions 90 concurrent calls and a load of around 1,1 \o/ |
| 14:46.15 | tzanger | *coughs* you admin 750 PBXes? |
| 14:47.43 | irroot | schmidts awesome thx for the info |
| 14:48.39 | schmidts | tzanger virtual hosted pbxes, yes ;) |
| 14:48.52 | tzanger | schmidts: wow |
| 14:51.08 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-147-133.bvtn.or.frontiernet.net) |
| 15:04.15 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 15:04.15 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:35.32 | *** join/#asterisk-dev mpe (~mpe@31.25.23.177) |
| 15:44.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 16:07.33 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 16:07.33 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Astricon 2011 in Denver, Colorado: AstriDevCon on October 24. Be there! |
| 16:56.28 | *** join/#asterisk-dev mjordan (mjordan@conference/astricon/x-reldxsxpwgkjesqf) |
| 16:56.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:00.20 | Corydon76-home | jsmith: I missed that we define __Darwin__ in our Makefile. |
| 17:00.46 | jsmith | Corydon76-home: Ah, gotcha... that makes more sense |
| 17:13.02 | *** join/#asterisk-dev irroot (~irroot@41.52.220.160) |
| 17:27.14 | irroot | evening folks |
| 17:31.18 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 17:31.19 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 17:31.54 | irroot | lo there file |
| 17:43.22 | *** join/#asterisk-dev kpfleming (kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:43.22 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:44.50 | *** join/#asterisk-dev sruffell (Adium@asterisk/the-kernel-guy/sruffell) |
| 17:44.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:57.27 | *** join/#asterisk-dev Micc (~Micc@c-24-17-253-27.hsd1.wa.comcast.net) |
| 18:02.34 | *** join/#asterisk-dev mjordan (mjordan@conference/astricon/x-mysfjivvjtsxuves) |
| 18:02.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:03.22 | Micc | if I have two asterisk boxes and one taking the call forwarding to another that has sip phones connected to it and the bye packet was dropped on its way back to the first box, would that disrupt the call flow enough to make the phones on the second box continue to ring forever? |
| 18:04.54 | Micc | the phones are aastra phones, which used to have a problem in previous versions of asterisk, unless the bug was reintroduced in 1.6.2.20. Which I know is unsupported, but I'd just like to know if my theory is plausable. |
| 18:07.28 | kpfleming | that's really a confusing question |
| 18:07.46 | Corydon76-home | Micc: phones should never ring forever. The typical longest timeout for a lack of response is 32 seconds |
| 18:07.46 | kpfleming | what generate a BYE request? |
| 18:07.49 | kpfleming | s/generate/generated/ |
| 18:07.54 | Corydon76-home | (64 * T1) |
| 18:08.19 | kpfleming | Corydon76-home: we should change it to 64*E1 for users in Europe |
| 18:08.35 | Corydon76-home | Heh |
| 18:09.07 | kpfleming | tzanger: were you ever able to test that 401 response thing with alwaysauthreject turned off? |
| 18:21.28 | *** part/#asterisk-dev mjordan (mjordan@conference/astricon/x-mysfjivvjtsxuves) |
| 18:26.00 | tzanger | kpfleming: I haven't yet. let me check that shortly. thanks for reminding me |
| 18:29.44 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 18:42.22 | Micc | kpfleming, the actual call went like this. call came into a1 then dialed a2 which went into a queue ringing about 10 phones at once. Call was answered by one of the phones but continued to ring on all the others. |
| 18:42.54 | Micc | This same call flow works fine most of the time, but they say 2-3 times a week it continues to ring all the phones forever. |
| 18:43.48 | Micc | My other customers that used to have this problem before the patch to asterisk say it hasn't come back, so I think I can rule out a regression. |
| 18:45.22 | Micc | They said it happened twice this morning though. The only other thing I can think of is network interruption. |
| 18:45.38 | Micc | but its not bad enough to drop a call. |
| 18:46.26 | Micc | server a1 is on a microwave link, so I its possible some packets don't get through sometimes. |
| 18:47.18 | Corydon76-home | Micc: In a small environment, you could probably drop T1 to 100ms (from 500ms) and the longest phones would ring in that situation would be only about 6 seconds. |
| 18:47.31 | Micc | So thats why I would wonder what would a2 do if it didn't know a1 had received a packet. But the call did complete fine and they were able to transfer the call to another phone too. |
| 18:48.24 | Micc | These phones would ring for days if not answered. |
| 18:48.46 | Corydon76-home | Then that's a serious firmware bug that needs to be addressed with the mfg |
| 18:48.55 | Micc | which leads me to think the bug is in the phone firmware. |
| 18:49.00 | Micc | right. |
| 18:49.17 | Micc | but in the past the same thing was fixed by a patch to asterisk. |
| 18:49.36 | Corydon76-home | At best, that's a workaround. |
| 18:49.51 | Micc | probably. |
| 18:50.04 | Micc | I'll compare firmware versions with customers that are working fine. |
| 18:51.00 | irroot | Micc what patch ?? |
| 18:53.02 | Micc | I don't remember but it was on the review board for a while and finally made it into the main branch. |
| 18:53.17 | Micc | probably a year or more ago. |
| 18:53.47 | irroot | then it should still be arround in there unless removed this is possible |
| 18:54.08 | Micc | It was some kind of race condition made worse by the aastra's responding to packet slower than other phones. |
| 18:54.39 | Micc | I'll have to dig through my email to find it I think. |
| 18:54.56 | Micc | because there are a ton of unrelated but similar problems. |
| 18:56.40 | Micc | I think I'm seeing a patern here with the phones. |
| 18:56.57 | Micc | seems to be only aastra 55i's still having the problem. |
| 19:09.23 | *** join/#asterisk-dev kpfleming (kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:09.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:17.05 | *** join/#asterisk-dev mjordan (mjordan@conference/astricon/x-djwrcxizcodqhzet) |
| 19:17.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:19.02 | *** join/#asterisk-dev bklang (bklang@conference/astricon/x-vzyeeihtpgfnhlpu) |
| 19:26.42 | Micc | I've got a consistent repro case with one of them. |
| 19:27.05 | Micc | but its a bit convoluted with local channels and stuff. |
| 19:27.57 | Micc | If upgrading the phone firmware doesn't fix it, I'll try 1.8.8 and file a bug if its still there. |
| 19:28.02 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 19:46.05 | tzafrir_laptop | Is sruffel around? |
| 19:50.25 | Micc | It appears to be fixed by a firmware upgrade to the phones. |
| 19:54.52 | irroot | Micc cool |
| 19:54.57 | irroot | at least we know |
| 19:58.15 | Micc | yeah I assumed that the same version would have the same fixes in it for all the models in the 67xx series phones, but apparently not. |
| 20:00.19 | *** join/#asterisk-dev mjordan (mjordan@conference/astricon/x-dvnzcidczwijjfff) |
| 20:00.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:25.15 | *** join/#asterisk-dev sruffell (Adium@asterisk/the-kernel-guy/sruffell) |
| 20:25.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:27.34 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 20:31.03 | *** join/#asterisk-dev sruffell (Adium@asterisk/the-kernel-guy/sruffell) |
| 20:31.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:57.06 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 20:57.14 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:07.22 | *** join/#asterisk-dev michael-i (~anonymous@204.11.230.58.static.etheric.net) |
| 21:12.08 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:12.11 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:54.27 | jmls | ok. another weird one |
| 21:54.55 | jmls | in manager.conf |
| 21:54.56 | jmls | read = reporting,command,system |
| 21:55.07 | jsmith | jmls: Like you ever show up with anything that's not weird :-p |
| 21:55.17 | jmls | oooooo. |
| 21:55.20 | jmls | :( |
| 21:55.23 | jmls | however, manager show user nodejs |
| 21:55.31 | jmls | read perm: system,command,reporting,all |
| 21:55.41 | jmls | ,all ?? |
| 21:55.47 | jmls | where does that come from ? |
| 21:56.54 | jmls | and how do I only get notification of CEL events ? |
| 21:59.36 | jsmith | Yeah, if you're getting an "all" and aren't specifying it, that's bad |
| 21:59.46 | jsmith | has no clue about the CEL question |
| 22:01.46 | pabelanger | jmls: weird? |
| 22:02.56 | jmls | yes! |
| 22:03.48 | jmls | definately borked |
| 22:03.56 | jmls | read = user |
| 22:03.56 | jmls | write = user |
| 22:04.06 | jmls | read perm: user,all |
| 22:04.06 | jmls | write perm: user,all |
| 22:04.28 | jmls | it's always adding ",all" to the end of the permission |
| 22:04.47 | jmls | heh |
| 22:04.54 | jmls | read = all |
| 22:05.01 | jmls | read perm: system,call,log,verbose,command,agent,user,config,dtmf,reporting,cdr,dialplan,originate,agi,cc,aoc,test,all |
| 22:05.13 | jmls | begone foul all. |
| 22:05.49 | pabelanger | I don't think CEL events on manager can be filtered using read / write |
| 22:05.55 | pabelanger | you'd have to whitelist them |
| 22:06.26 | jmls | pabelanger: crap - so I have to parse all events looking for CEL ? |
| 22:06.30 | michael-i | can I jump in with a question: any thought given to filtering originate events' write-ability to specific contexts per user? |
| 22:06.36 | jmls | no |
| 22:06.37 | jmls | ;) |
| 22:06.51 | pabelanger | jmls: I believe so |
| 22:07.00 | jmls | that ... sucks ... melons |
| 22:07.04 | pabelanger | yar |
| 22:07.14 | michael-i | it's something I'm going to need to implementâ¦just wondering if it was ever discussed (AMI context level permissions in general) |
| 22:07.21 | pabelanger | IIRC, CEL is more for database then manager |
| 22:08.13 | jmls | it's incredibly powerful if you are using the manager events to send on to a jms messaging system ... ;) |
| 22:08.29 | jmls | you can then hook in any number of database or listeners without any impact on * |
| 22:08.35 | pabelanger | ya, I don't see a reason not to add it to manager |
| 22:08.51 | jmls | it is already a separate event : CEL |
| 22:09.04 | jmls | you just can't "perm" it |
| 22:09.28 | pabelanger | right, you need to enable it in cel.conf to log to manager, but default it is disabled |
| 22:09.36 | jmls | did that ;) |
| 22:09.44 | pabelanger | likely the reason it is missing from manager.conf |
| 22:10.39 | jmls | the real problem at the moment is that manager.conf ignores your filters perms and just goes ahead and adds a bloody "all" "without a bye your leave" (*) |
| 22:12.07 | jmls | * I was hopping along, minding my own business. All of a sudden, up he comes. Cures me. One minute I'm a leper with a trade, next minute my livelihood's gone. Not so much as a by your leave. 'You're cured mate.' Bloody do-gooder. |
| 23:04.56 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 23:13.19 | tzafrir_laptop | oron_laptop, did you send that mail? I don't see it on asterisk-dev |
| 23:13.46 | oron_laptop | I just found out I copied the address of asteriskteam, resending... |
| 23:22.17 | oron_laptop | tzafrir_laptop: it's finaly there: http://lists.digium.com/pipermail/asterisk-dev/2011-October/051954.html |