| 00:10.17 | Corydon76-dig | interop > compliance |
| 00:29.58 | gitguy | yeah, who cares as long as it works |
| 00:31.47 | gitguy | "RFC Compliant" just sounds "safe" for some reason |
| 00:41.24 | *** join/#asterisk-dev shido6 (n=shido6@74-130-51-159.dhcp.insightbb.com) |
| 00:45.08 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582051.dsl.bell.ca) |
| 00:52.35 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-187-7.hsd1.wa.comcast.net) |
| 01:02.22 | *** part/#asterisk-dev shido6 (n=shido6@74-130-51-159.dhcp.insightbb.com) |
| 01:22.05 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:22.05 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:27.18 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 01:47.06 | *** join/#asterisk-dev jeffspeff (n=jeff@c-68-53-81-14.hsd1.ky.comcast.net) |
| 01:59.24 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 02:04.19 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 03:33.46 | *** join/#asterisk-dev gitguy (n=diego@adsl-134-171.click.com.py) |
| 04:13.28 | *** part/#asterisk-dev gitguy (n=diego@adsl-134-171.click.com.py) |
| 04:46.42 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 04:47.37 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 04:49.43 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 05:38.47 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 06:02.53 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 06:09.20 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:20.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:20.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:26.37 | oej | Morning |
| 07:41.55 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.193) |
| 07:48.48 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 09:40.01 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:40.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:56.27 | *** join/#asterisk-dev RoyK (n=roy@ip-177-22-149-91.dialup.ice.no) |
| 10:06.33 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 10:22.28 | jmls_home | I still have my problem with inbound zap channels not hanging up properly. I need to be able to tell my telco (BT) that it's their problem. |
| 10:22.52 | jmls_home | could someone help me with the debug info ? |
| 11:03.19 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:03.19 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 11:15.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:15.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:24.16 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:15.28 | snuff-home | wonders what to do.. |
| 12:28.00 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:30.20 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:48.15 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:58.50 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:01.07 | *** join/#asterisk-dev jeffg (i=RJwX0aLw@pdpc/supporter/active/jeffg) |
| 13:07.21 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:09.12 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.205.41) |
| 13:11.22 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:27.48 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:30.47 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:33.28 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:35.57 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-e3beafe682635463) |
| 13:44.02 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 13:44.02 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 13:46.56 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:46.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:47.17 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:58.52 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 13:59.54 | puzzled | hi |
| 14:02.56 | awk | putnopvut: hi any chance you got 1 sec to look at this: http://bugs.digium.com/view.php?id=12584 ? |
| 14:02.59 | awk | thank you |
| 14:03.06 | file | M12584 |
| 14:03.09 | MuffinMan | [new] [Asterisk] Channels/chan_local 0012584: Lock errors on the CLI reported by DougUDI (Karma: neutral) http://bugs.digium.com/view.php?id=12584 |
| 14:03.43 | snuff-home | disappears and counts sheep jumping over a fence |
| 14:03.52 | putnopvut | awk: I haven't looked at that one too deeply yet. Perhaps I can get around to that one a bit later today. |
| 14:05.18 | puzzled | any chance the check if [ `id -u` = 0 ]; then can be added to the zaptel and libpri Makefile before issuing an /sbin/restorecon when selinux is enabled? |
| 14:05.47 | puzzled | that would make it much easier for packagers that do not build as root. don't have to patch the Makefile to disable that |
| 14:06.17 | awk | putnopvut: I would very much appreciate that.. |
| 14:12.41 | *** join/#asterisk-dev hugorebelo (n=hugorebe@c90695e3.static.spo.virtua.com.br) |
| 14:29.28 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:29.28 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:34.09 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 14:34.09 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 14:48.10 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 14:50.52 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.110.169) |
| 14:51.12 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 14:57.46 | puzzled | tzafrir: ping |
| 15:16.49 | *** join/#asterisk-dev RoyK (n=roy@062249179121.customer.alfanett.no) |
| 15:16.55 | *** join/#asterisk-dev zdevra (n=zdevra@nat-88-212-20-119.antik.sk) |
| 15:25.52 | *** join/#asterisk-dev eurodrew555 (n=andrews@83-244-164-142.cust-83.exponential-e.net) |
| 15:26.23 | eurodrew555 | any libpri experts here ? |
| 15:27.01 | eurodrew555 | I have a q931 question - CELL PHONE <--> TELCO <--> ASTERISK |
| 15:27.31 | eurodrew555 | Cell phone dials in, Asterisk answers OK, Cell phone then hangs up, Telco sends Asterisk a q931 DISCONNECT INDICATION |
| 15:27.55 | eurodrew555 | my question is, should Asterisk then send a RELEASE back to the telco and destroy the channel, or should the telco send the RELEASE back to Asterisk |
| 15:28.16 | eurodrew555 | who is responsible for sending the RELEASE after the DISCONNECT INDICATION ? |
| 15:29.45 | eurodrew555 | I have tried every combination of zapata.conf, but still facing this issue - I feel the telco is at fault they think not |
| 15:31.41 | *** join/#asterisk-dev Laureano (n=Laureano@OL93-199.fibertel.com.ar) |
| 15:35.58 | *** join/#asterisk-dev PTorres (n=PTorres@200.68.87.146) |
| 15:41.34 | PTorres | hello |
| 15:42.59 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:42.59 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:44.13 | Cresl1n | We send a RELEASE in response to a DISCONNECT (IIRC) |
| 15:45.17 | eurodrew555 | Hi Creslin, right so therefore the issue is on my side |
| 15:45.30 | eurodrew555 | as I am getting the DISCONNECT message |
| 15:45.37 | Cresl1n | What's the problem? |
| 15:45.58 | eurodrew555 | I did a major roll back over the weekend though, went back months where we definitely didn't have the issue, and the problem still exists |
| 15:46.19 | eurodrew555 | then went through every change of zapata.conf I could think of, with full reboots after every change, still have the prob |
| 15:46.19 | oej | Cresl1n! |
| 15:46.30 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:46.30 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:46.32 | Cresl1n | Hey oej :-) |
| 15:46.49 | eurodrew555 | instead of the call getting disconnected cleanly, our telco hangs on and plays a message 'The other party has hung up' |
| 15:46.54 | eurodrew555 | its a BT (UK) message |
| 15:47.03 | PTorres | anyone remember that issue with the device state thread locked/waiting for 20 seconds ? I got a bit of info during the weekend :D |
| 15:47.15 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:47.34 | eurodrew555 | they send the DISCONNECT, then we get the message for about 20 secs, then the channel is RELEASED (by the telco) |
| 15:47.42 | eurodrew555 | we never release the channel ourselves |
| 15:47.54 | eurodrew555 | thought it might of been an upgrade, but I rolled back everything...... |
| 15:48.17 | eurodrew555 | so have to admit a bit stumped at what has caused it, the telco say it's us..... |
| 15:48.42 | Cresl1n | well, we should be sending DISCONNECT |
| 15:48.59 | Cresl1n | Is this on an E1 PRI? |
| 16:00.12 | jmls_home | eurodrew555: I have exactly the same problem on one of my PRI lines |
| 16:00.16 | jmls_home | Cresl1n: E1 as well |
| 16:00.27 | eurodrew555 | yes it is an E1 line (euroisdn) |
| 16:00.28 | jpeeler | Corydon76-lap: what is the 1.4 version of ast_str_alloca? |
| 16:01.02 | Corydon76-lap | I don't believe there was one |
| 16:01.16 | eurodrew555 | problem started a few weeks ago |
| 16:01.34 | jmls_home | eurodrew555: yup ;) |
| 16:01.34 | Cresl1n | If you can find out what changed, that would help a lot |
| 16:01.39 | Cresl1n | can you softhangup the channel? |
| 16:02.13 | eurodrew555 | I have a h extension set, but it doesn't drop to it until the telco finally does it's release |
| 16:02.26 | jmls_home | Cresl1n: yes |
| 16:02.30 | jpeeler | Corydon76-lap: then I won't include that in the doc |
| 16:03.11 | Corydon76-lap | jpeeler: you're just documenting incompatible changes? |
| 16:03.22 | jpeeler | Corydon76-lap: yes |
| 16:03.43 | jpeeler | in some ways i wish i were just documenting the full 1.6 API |
| 16:04.00 | jmls_home | eurodrew555: you do seem to be having exactly the same problems as I. Are you in the UK ? |
| 16:04.15 | Corydon76-lap | jpeeler: nobody would blame you too badly if you did that, too |
| 16:04.43 | eurodrew555 | jmls_home: yes - carrier is BT |
| 16:04.52 | jmls_home | *snap* |
| 16:05.11 | jpeeler | Corydon76-lap: perhaps i'll bring it up today |
| 16:05.44 | eurodrew555 | <PROTECTED> |
| 16:05.55 | eurodrew555 | jmls_home: and we definitely did not have the issue back then |
| 16:06.02 | jmls_home | no, we didn't either |
| 16:06.07 | Cresl1n | that doesn't make sense though that we're not sending back the release though |
| 16:06.18 | Cresl1n | can you post a pri debug trace of this when it happens? |
| 16:06.27 | jmls_home | Cresl1n: just posting an example now ... |
| 16:07.51 | eurodrew555 | my pri debug is here - http://pastebin.com/d7da793c1 |
| 16:08.21 | jmls_home | heh. |
| 16:08.26 | jmls_home | mine is http://www.pastebin.ca/1015884 |
| 16:08.51 | jmls_home | I've also included a snippet of the dialplan that answers, plays a file, waits for a second and then loops |
| 16:09.12 | jmls_home | you see the initial portion of the hangup, but then it waits for nearly 30s before actually hanging up |
| 16:10.37 | Cresl1n | that's really odd |
| 16:10.55 | Cresl1n | Oh wait! |
| 16:10.55 | Cresl1n | crap! |
| 16:11.15 | Cresl1n | what versions of libpri have you tried? |
| 16:11.38 | file | uh oh... |
| 16:11.44 | file | Cresl1n: epiphany? |
| 16:11.53 | Cresl1n | yeah, somebody committed a patch they shouldn't have I think.... |
| 16:12.11 | file | to libpri? |
| 16:12.14 | Cresl1n | yes |
| 16:12.17 | file | ut roh |
| 16:13.10 | Cresl1n | There was a patch on the bug tracker that leaves the channel open so that you can hear the disconnect audio, and I wasn't going to commit it until I had time to make that feature optional instead of mandatory |
| 16:13.33 | file | I remember that one vaguely |
| 16:13.39 | Cresl1n | I think someone else committed it |
| 16:13.51 | Cresl1n | but I can't remember who |
| 16:14.09 | Juggie | blame file |
| 16:14.11 | Cresl1n | I've been working on all the BRI stuff and haven't taken a lot of time to work on it |
| 16:14.38 | jmls_home | heh |
| 16:14.46 | file | it was me! |
| 16:14.47 | Qwell | commit libpri 528 |
| 16:14.47 | Qwell | :P |
| 16:14.49 | MuffinMan | [528] Committed by file on 2008-02-21T16:38:11.925342Z: If inband audio is being provided with a disconnect message let the audio be heard before releasing the channel. |
| 16:14.50 | MuffinMan | ..(closes issue #10552) |
| 16:14.50 | MuffinMan | ..Reported by: paravoid |
| 16:14.50 | MuffinMan | ..Patches: |
| 16:14.50 | MuffinMan | .. disconnect-audio.diff uploaded by paravoid (license 200) |
| 16:14.59 | Cresl1n | yeah, that was it |
| 16:15.08 | file | hugs Cresl1n |
| 16:15.11 | file | Cresl1n: I'm sowwy |
| 16:15.27 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:15.29 | jmls_home | feels vindicated. |
| 16:15.39 | jmls_home | at least I don't feel stupid anymore |
| 16:15.42 | Cresl1n | jmls_home: everything works ok though, right? |
| 16:15.47 | jmls_home | <PROTECTED> |
| 16:15.52 | jmls_home | Cresl1n: yeah |
| 16:15.59 | Cresl1n | it should just take longer to release the channel |
| 16:16.04 | jmls_home | in that it hangs up 30s+ later ;) |
| 16:16.15 | Cresl1n | and you get the added benefit of inband audio from your telco |
| 16:16.57 | Qwell | tzafrir_home: I could've sworn I fixed that src thing |
| 16:17.29 | Cresl1n | Qwell: the HPEC problem? |
| 16:17.33 | Qwell | yeah |
| 16:17.41 | Qwell | M12623 |
| 16:17.43 | MuffinMan | [new] [Zaptel] General 0012623: Unable to build Hpec on Zaptel 1.4.10.1 reported by ricvil (Karma: neutral) http://bugs.digium.com/view.php?id=12623 |
| 16:17.46 | Cresl1n | yeah, we're going to add it to the Zaptel regression test |
| 16:17.57 | Cresl1n | so we don't make another release that it broken for that reason |
| 16:18.37 | Cresl1n | *is broken |
| 16:19.11 | PTorres | can you guys take a look at this pls ? core show locks : http://pastebin.com/d3f4461f0 , gdb thread apply all bt : http://pastebin.com/d582c2012 |
| 16:19.46 | jmls_home | eurodrew555: are you celebrating yet ? |
| 16:19.52 | PTorres | the device_state_change thread gets locked (or waits?) for 20 seconds exactly |
| 16:20.12 | russellb | bug tracker please .. |
| 16:20.29 | PTorres | k, I will submit |
| 16:20.42 | jmls_home | it's not that often we get to find something wrong with libpri .. |
| 16:21.02 | Cresl1n | I'll take that as a compliment :-) |
| 16:21.27 | file | hugs Cresl1n |
| 16:21.29 | file | Cresl1n: you r0x0rz |
| 16:21.39 | Cresl1n | no file, you r0x0rz :-) |
| 16:22.03 | jmls_home | as it was intended |
| 16:22.05 | codefreeze | PTorres: You have DETECT_DEADLOCKS set? |
| 16:23.12 | jmls_home | hands Cresl1n a "Smallest Number Of Unexpected Features Found" award. |
| 16:23.14 | Corydon76-lap | Welcome to the Monday morning cuddle party |
| 16:23.22 | jmls_home | or, SNUFF for short |
| 16:23.30 | PTorres | I think it was enabled for that |
| 16:25.42 | russellb | Corydon76-dig, lol .. |
| 16:26.26 | Corydon76-lap | russellb: I saw a link for that somewhere over the weekend |
| 16:27.10 | Corydon76-lap | Surprisingly, www.cuddleparty.com SFW |
| 16:27.35 | russellb | heh |
| 16:28.22 | russellb | saw this image on digg this weekend, http://i31.tinypic.com/wvrex2.jpg |
| 16:28.23 | jmls_home | Cresl1n: should I raise a bug, or don't you need a reminder ? |
| 16:28.27 | russellb | i was quite amused |
| 16:28.37 | jmls_home | lol |
| 16:28.44 | Corydon76-lap | Heh |
| 16:29.16 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:29.16 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:30.50 | codefreeze | PTorres: I suspect, if you disable DETECT_DEADLOCKS in the menuselect stuff, the 20 second locks will turn into a single, infinitely long lock. |
| 16:31.58 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 16:33.10 | eurodrew555 | hey guys, sorry got called away |
| 16:33.48 | eurodrew555 | jmls_home: sounds like good news |
| 16:34.50 | PTorres | mmm... not actually... we detected the 20 seconds wait without DETECT_DEADLOCKS , last friday, and I cant recall but someone suggested to post a core show locks and a gdb |
| 16:35.37 | PTorres | with DETECT_DEADLOCKS on, it seemed to work a bit better but still too slow to have the status up to time |
| 16:37.33 | PTorres | I mean it only processes a couple of state changes but the list had many more insertions |
| 16:43.15 | *** part/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 16:44.37 | PTorres | codefreeze : its 1.4.18 (1.4.19 had the same problem and crashes too much) |
| 16:45.55 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 16:49.22 | *** part/#asterisk-dev eurodrew555 (n=andrews@83-244-164-142.cust-83.exponential-e.net) |
| 16:54.10 | codefreeze | PTorres: Hmmm. OK. Well, posting the "core show locks" and a gdb trace of any crashes will hopefully allow us to zero in on the bugs and get them fixed...! |
| 16:55.31 | PTorres | ok, I am submitting all the info I have atm on the bugtracker |
| 16:55.48 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:02.42 | jpeeler | Corydon76-lap: individual RTP statistics were previously available in a string, it just had to be parsed? (ast_rtp_get_quality) |
| 17:07.47 | Corydon76-lap | jpeeler: correct |
| 17:07.56 | PTorres | k, posted M12627 |
| 17:08.12 | PTorres | M12627 |
| 17:08.13 | MuffinMan | [new] [Asterisk] Core/General 0012627: The device state change thread gets locked (or waits) for 20 seconds reported by PTorres (Karma: neutral) http://bugs.digium.com/view.php?id=12627 |
| 17:08.17 | PTorres | hehe :P |
| 17:09.49 | file | we know, every time an issue is submitted it gets output in #asterisk-commits immediately |
| 17:10.58 | PTorres | oh , sorry then |
| 17:11.17 | file | it doesn't matter, just saying |
| 17:11.33 | PTorres | I know jk |
| 17:15.11 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 17:15.11 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 17:16.43 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.142) |
| 17:24.25 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:24.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:25.33 | jpeeler | Corydon76-lap: is using ast_variable_delete really faster with the line number specified? it increments the line one by one from zero |
| 17:25.55 | Corydon76-lap | jpeeler: yes, it is |
| 17:26.32 | Corydon76-lap | integer comparisons versus a ton of string comparisons |
| 17:26.41 | jpeeler | oh... |
| 17:27.31 | jpeeler | but still, it seems that the string comparisons are run each time the line number has not been reached yet |
| 17:28.06 | Corydon76-lap | There are admittedly a few cases that might be faster, if the context was one of the first and the variable was one of the first within a context, but even so, the fact that it has to compare against the value slows it down a lot |
| 17:28.22 | Corydon76-lap | jpeeler: that might be a bug, then |
| 17:28.46 | Corydon76-lap | or maybe just an optimization that wasn't done |
| 17:29.05 | Corydon76-lap | Okay, not faster, but has the potential to be faster |
| 17:29.25 | Corydon76-lap | We really should fix that in 1.6.1 |
| 17:30.19 | jpeeler | looks like it needs some attention then |
| 17:30.47 | Corydon76-lap | Could confirm that with Pari... |
| 17:46.46 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 17:48.07 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 17:48.07 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 17:55.11 | *** join/#asterisk-dev gitguy (n=diego@adsl-134-171.click.com.py) |
| 17:56.01 | gitguy | hi, i'm having some problems with DTMF, i think is due to my network connection, i read the DTMF and i print them again with NoOp() but sometimes i don't get all the digits |
| 17:56.37 | gitguy | is that caused due to packet loss or does asterisk doesn't accept broken DTMF? |
| 17:57.04 | file | if packets are being dropped like a madman there is only so much we can do |
| 17:57.12 | file | to compensate |
| 17:57.36 | file | but I would suggest filing an issue report with complete dtmf logging and rtp debug if RFC2833 is involved |
| 17:58.02 | gitguy | in #freeswitch they told me they can handle that... i don't know how though |
| 17:58.40 | file | okay. |
| 17:59.43 | file | unless you file an issue report nobody will probably remember, and it won't get looked at... so I would suggest filing one |
| 17:59.53 | gitguy | typed "123456789" => -- Executing [123@default:2] NoOp("SIP/diego.viola-10aadc00", "12389") in new stack |
| 18:00.03 | file | runs off to a meeting |
| 18:00.19 | gitguy | where do i fill |
| 18:00.33 | file | http://bugs.digium.com/ |
| 18:00.40 | gitguy | ok thx |
| 18:00.45 | file | read the details before you file... provide as much information as possible |
| 18:00.55 | gitguy | alright thanks |
| 18:06.31 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:13.33 | gitguy | what category for dtmf? |
| 18:17.41 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 18:24.31 | gitguy | sumitted |
| 18:26.01 | ctooley | gitguy, with "complete dtmf logging and rtp debug if RFC2833"? |
| 18:26.59 | gitguy | oops, no, let me attach those files |
| 18:27.51 | gitguy | how do i enable the logging of those in the cli? |
| 18:28.25 | gitguy | RTP Debugging Enabled |
| 18:30.50 | ctooley | oej, ping |
| 18:34.50 | oej | pong |
| 18:37.17 | gitguy | ctooley: http://pastebin.com/m2ea14a21 |
| 18:37.25 | gitguy | file: http://pastebin.com/m2ea14a21 |
| 18:38.16 | ctooley | oej, Does your version of the patch for bug 11816 return the same call id data as the one I submitted, or does it return some other unique identifier? |
| 18:40.00 | oej | Which patch is this? |
| 18:40.46 | ctooley | You decided to implement that a different way (rev99644 it appears) than the way I implemented it in the patch I submitted. |
| 18:40.53 | ctooley | I was wanting to verify it returned the same data. |
| 18:41.27 | oej | Well, there's only one set of SIP call ID's to report, right |
| 18:41.28 | ctooley | Well, I wanted to verify that BRIDGEPVTCALLID is set to the same data. |
| 18:42.15 | oej | Should be |
| 18:42.19 | ctooley | oej, should be, but this: "bridged call PVT unique id string" is ambiguous as to whether it's a unique call id or if it's some other identifier. |
| 18:42.48 | ctooley | ok, good. Then all I'll need to do for 1.6 is update 70 or 80 servers with the new channel variable and we should be good. |
| 18:43.00 | oej | Well, it is multiprotocol. So if someone implements it for another channel, you will get that channel's ID, like Google Talk ID or IAX2 call number. |
| 18:44.32 | ctooley | right, but, I've built billing records based on that data being there and I wanted to verify that it's not changing which data actually gets stored in the variable, only the variable name. |
| 18:44.37 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:45.23 | file | gitguy: add it to the issue. |
| 18:46.31 | gitguy | file: i just added it |
| 18:46.40 | file | both dtmf logging and rtp debug? |
| 18:46.53 | gitguy | yes |
| 18:47.26 | file | I only see dtmf logging, no rtp debug |
| 18:47.51 | file | runs back to meeting |
| 18:48.16 | gitguy | i'm sure i did "rtp debug" |
| 18:48.46 | file | try rtp set debug on |
| 18:48.48 | gitguy | ok here i got more output |
| 18:51.55 | gitguy | http://pastebin.com/m57923229 |
| 18:52.04 | gitguy | added the file already |
| 18:52.53 | gitguy | it's dtmf_with_rtp_and_dtmf_in_console_line(2).txt |
| 18:52.55 | file | k, then someone will look at it... |
| 18:53.00 | gitguy | thanks |
| 18:54.54 | gitguy | can i ask for features? i could tell my boss to pay for them |
| 18:55.20 | file | you can submit a bounty or find someone to write something... but Mantis is not the place for that |
| 18:55.58 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:56.57 | gitguy | ok |
| 18:57.18 | gitguy | what is mantis? |
| 18:57.39 | file | the issue tracker you submitted your issue on. |
| 18:58.15 | seanbright | issue tracker? |
| 19:20.32 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-7540.bb.online.no) |
| 19:36.14 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 19:37.14 | tzafrir | Cresl1n, the API change of IRQ_SHARED is in vanilla 2.6.18 or in some distro 2.6.18? |
| 19:38.00 | Cresl1n | It looks like it was in vanilla 2.6.18 |
| 19:38.24 | Cresl1n | I was looking at diffs online |
| 19:38.25 | tzafrir | ok |
| 19:38.46 | Cresl1n | I'm surprised it would have taken so long for this bug to have surfaced though |
| 19:54.44 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-7540.bb.online.no) |
| 19:56.33 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:03.21 | paravoid | Cresl1n: yeah, I've agreed that it would be better to make it configurable |
| 20:03.23 | paravoid | the inband audio thing |
| 20:03.43 | paravoid | I think I was the one to note the potential problem |
| 20:03.49 | paravoid | sorry for not mentioning in the bug report :( |
| 20:03.54 | jmls_home | yeah, thanks ;) |
| 20:04.14 | jmls_home | is joking |
| 20:04.27 | paravoid | it's not very bad behavior though, unless you run a *very* busy pbx |
| 20:04.49 | jmls_home | or unless you have a limited number of channels on the E1 |
| 20:04.52 | jmls_home | like 10 |
| 20:05.12 | paravoid | even in that case |
| 20:05.33 | paravoid | your users must be very stupid to keep the channel ope after they hear the message :) |
| 20:05.44 | jmls_home | welllll, we ran into it pretty damned fast |
| 20:06.11 | jmls_home | and if the inbound is into a menu system for automated ordering ... |
| 20:06.52 | jmls_home | so there are no users on the other end of the inbound, so no-one hears the message :p |
| 20:08.07 | jmls_home | a configurable option would be great: HangupAfterNumSecs |
| 20:08.20 | jmls_home | 0 = default, hangs up straight away |
| 20:08.39 | jmls_home | n = number of seconds you want to listen to the inband thing |
| 20:12.13 | paravoid | nope |
| 20:12.29 | paravoid | the spec explicitely states that you can wait indefinitely |
| 20:12.40 | paravoid | because the other end will spawn a timer that will close the channel |
| 20:12.53 | paravoid | so, for example, the local telco plays the message 3 times before it hangs up |
| 20:12.58 | *** join/#asterisk-dev ariel_ (n=ariel_@74.8.35.6) |
| 20:13.06 | paravoid | so you could wait from 15 to 35 seconds, depending on the message |
| 20:13.20 | paravoid | ("temporary technical failure" is longer than "number does not exist") |
| 20:14.37 | jmls_home | oohh, ok |
| 20:14.48 | jmls_home | does not know the first thing about PRI |
| 20:14.54 | jmls_home | does it show ? ;) |
| 20:29.04 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.80.140) |
| 20:30.02 | anonymouz666 | russellb: the first two files from 9096 were removed? |
| 20:30.21 | anonymouz666 | I need to download the wctdm_v3_trunk_nopolarity.diff |
| 20:36.58 | paravoid | jmls_home: that's not PRI, that's ISDN (Q.931) -- i.e. applies to BRI too. |
| 20:37.20 | jmls_home | lol. See. told you :) |
| 20:37.49 | jmls_home | that's perhaps why I missed the commit. I saw BRI, and promptly ignored it ... |
| 20:37.50 | paravoid | basically there's a setting that can be overloaded |
| 20:37.53 | paravoid | priindication= |
| 20:39.28 | paravoid | oh and btw the previous behavior was a problem as well |
| 20:39.36 | paravoid | it was prompt to races |
| 20:39.45 | paravoid | in my setup I was hearing the telco's message for 2-3 seconds |
| 20:39.55 | paravoid | "the numbe -click" |
| 20:42.35 | jmls_home | gotta get some sleep. thanks all |
| 20:42.38 | jmls_home | nght |
| 20:42.41 | jmls_home | heh |
| 20:42.42 | jmls_home | night |
| 20:56.13 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:00.35 | jpeeler | so => is considered "an object" |
| 21:00.54 | putnopvut | jpeeler: I ran into that myself. |
| 21:01.01 | putnopvut | jpeeler: yes, but...it still means nothing. |
| 21:01.05 | jpeeler | that just seems like a very bad word choice |
| 21:01.15 | putnopvut | => and = are equivalent in Asterisk configurations. |
| 21:01.32 | jpeeler | but why would => be called an object, or flagged as such |
| 21:01.33 | putnopvut | jpeeler: I agree about the bad word choice. |
| 21:01.39 | jpeeler | wow |
| 21:01.52 | putnopvut | jpeeler: I asked the same thing when I first found that... |
| 21:02.24 | jpeeler | putnopvut: did you get an answer? |
| 21:02.34 | putnopvut | jpeeler: nope :) |
| 21:04.14 | jpeeler | what would the term be for that anyway, config file equivalence operator? |
| 21:04.40 | putnopvut | assignment seems more appropriate than equivalence. |
| 21:07.05 | jpeeler | yeah, that's what i meant actually |
| 21:10.45 | *** join/#asterisk-dev RoyK (n=roy@ip-177-22-149-91.dialup.ice.no) |
| 21:46.45 | *** part/#asterisk-dev PTorres (n=PTorres@200.68.87.146) |
| 21:49.17 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 21:56.12 | *** part/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 21:56.39 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 22:04.36 | jpeeler | russellb: i see what you mean about the zap issues being hard to test |
| 22:04.40 | jpeeler | russellb: what about 10731? |
| 22:04.55 | russellb | M10731 |
| 22:04.57 | MuffinMan | [new] [Asterisk] Applications/app_disa 0010731: DISA prevents DTMF detection w/ FXO port on TDM400 reported by devnullzero (Karma: neutral) http://bugs.digium.com/view.php?id=10731 |
| 22:05.15 | russellb | hm, well, i pointed bbryant to that one earlier .. |
| 22:05.19 | *** join/#asterisk-dev jets (n=brian@pdpc/supporter/active/jets) |
| 22:05.37 | russellb | bbryant: if you're going to work on it, assign it to yourself so others don't look at it |
| 22:05.57 | bbryant | done |
| 22:06.16 | jpeeler | continues to look |
| 22:08.59 | russellb | you could try to reproduce 11189 perhaps ... |
| 22:09.16 | russellb | or 11594 |
| 22:09.24 | russellb | or 11017 ... |
| 22:09.33 | russellb | those are all near the top |
| 22:15.10 | jpeeler | all of those seem to require some hardware that probably isn't available |
| 22:15.19 | jpeeler | try without the hardware? |
| 22:15.19 | russellb | yeah :-/ |
| 22:15.24 | russellb | depends |
| 22:15.31 | russellb | what hardware? |
| 22:15.35 | russellb | you certainly have access to E1 cards |
| 22:16.02 | jpeeler | oh really |
| 22:16.11 | jpeeler | well then perhaps 11189 will work |
| 22:16.17 | *** join/#asterisk-dev RoyK (n=roy@ip-7-17-149-91.dialup.ice.no) |
| 22:16.25 | russellb | our T1 cards can be E1, as well |
| 22:17.15 | jpeeler | the other problem is the hardware probably needs to be used |
| 22:17.26 | jpeeler | although he says "I have tested the hardware with the help of digium support and have eliminated the hardware as an issue." |
| 22:18.51 | *** join/#asterisk-dev anthm (n=anthm@mb10736d0.tmodns.net) |
| 22:23.08 | russellb | so, I was getting ready to push out the releases, and then i noticed this ... |
| 22:23.10 | russellb | M12603 |
| 22:23.12 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/General 0012603: Asterisk locks up and cannot process incoming SIP messages on 1.4.20-rc1 reported by jyap (Karma: neutral) http://bugs.digium.com/view.php?id=12603 |
| 22:23.19 | russellb | it's not clear whether this is actually a new issue or not ... |
| 22:23.35 | russellb | shall we hold off on the release while we follow up on that? |
| 22:25.11 | russellb | is thinking yes, unless someone things we should release anyway for some good reason... |
| 22:25.53 | file | I think we can afford to wait a bit longer |
| 22:27.19 | russellb | file: thanks for the input |
| 22:27.59 | gitguy | asterisk 1.4 works really buggy for me |
| 22:28.20 | gitguy | s/works/is |
| 22:29.21 | russellb | gitguy: thanks for the helpful input? |
| 22:30.09 | jpeeler | russellb: i didn't think there was ever any pressure to release |
| 22:30.27 | gitguy | does 1.6 fixed most of the bug already? |
| 22:30.32 | gitguy | am i better using/trying 1.6? |
| 22:30.35 | gitguy | than staying with 1.4? |
| 22:30.56 | gitguy | i have 33+ users using it and they attack me all the time because things "don't work" |
| 22:30.59 | gitguy | i'm getting sick of it |
| 22:31.29 | russellb | http://bugs.digium.com/ |
| 22:32.04 | gitguy | yeah i know... i submitted one today |
| 22:32.16 | russellb | ok, thanks |
| 22:32.17 | gitguy | http://pastie.caboo.se/193839 <-- that's my config btw |
| 22:32.32 | gitguy | a bit outdated tho |
| 22:40.28 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 22:46.44 | gitguy | as a suggestion (and with the best intentions) i think you guys should fix bugs instead of adding features |
| 22:46.47 | gitguy | for the next "big release" |
| 22:46.51 | gitguy | 1.6 |
| 22:47.47 | russellb | ugh. |
| 22:48.11 | russellb | if you had any idea of what type of work we do, you would see that we spend about 95% of our time doing just that |
| 22:48.23 | russellb | so thanks again for some more "useful input" |
| 22:48.42 | gitguy | ah, i didn't know that |
| 22:48.55 | gitguy | sorry |
| 22:50.06 | Corydon76-lap | Unfortunately, we get people insulting us like that all the time. :-( |
| 22:50.32 | russellb | and all it does is piss me off and ruin my day |
| 22:50.39 | gitguy | sorry |
| 22:51.10 | Corydon76-lap | and most of the "features" that we put into new releases are things that people tell us "I really need this and I consider it a bug that you don't have it." |
| 22:51.41 | Corydon76-lap | even though it's technically a new feature, which is why it goes into a new branch, not the existing branch |
| 22:51.47 | gitguy | i see |
| 22:52.19 | gitguy | i didn't really meant to insult, i think your work is great |
| 22:52.41 | Corydon76-lap | If you have issues, then by all means, file a bug report. |
| 22:52.53 | gitguy | ok |
| 22:53.33 | russellb | gitguy: how could you possibly think that telling people they should try to fix more bugs in their buggy software is constructive criticism? |
| 22:53.35 | Corydon76-lap | I think the 15% rule applies... everybody uses exactly 15% of the features that Asterisk offers and they consider the other 85% useless features. |
| 22:53.37 | russellb | it's just plain trolling |
| 22:53.53 | Corydon76-lap | What that 15% is happens to differ for everybody |
| 22:54.41 | gitguy | russellb: yeah, i'm sorry |
| 22:54.53 | outtolunc | uses 18% because i never follow the rules |
| 22:55.19 | *** part/#asterisk-dev RoyK (n=roy@ip-7-17-149-91.dialup.ice.no) |
| 22:55.39 | Corydon76-lap | and then they wonder why we spend time working on that 85% and never see the work on the 15%... |
| 22:55.51 | gitguy | russellb: i just wish things could work better for me |
| 22:55.59 | russellb | I do, too |
| 22:56.08 | russellb | and you've done what you can, by filing a bug report |
| 22:56.12 | russellb | so thanks for doing that. |
| 22:56.12 | Corydon76-lap | This is open source. If you have an itch, you scratch it. |
| 22:56.18 | russellb | hopefully we can get it fixed ... |
| 22:56.20 | gitguy | russellb: anytime |
| 22:56.33 | gitguy | is not a big deal i guess |
| 22:57.14 | gitguy | best of luck ;) |
| 22:57.17 | gitguy | i think asterisk is great |
| 22:57.25 | russellb | thanks :) |
| 22:58.49 | russellb | believe me, i know asterisk has problems |
| 22:58.52 | russellb | plenty of them ... |
| 22:59.00 | russellb | i don't need any reminders :) |
| 22:59.11 | gitguy | heh, nothing is perfect |
| 22:59.33 | Corydon76-lap | starts up a daily reminder script |
| 22:59.59 | russellb | but we really do work hard to make it better ... |
| 23:00.10 | russellb | we have about a dozen people doing so full-time at Digium, alone ... |
| 23:00.17 | gitguy | something i really like as a user is the simplicify of configuration, i haven't found anything else so simple as asterisk to configure and use |
| 23:00.45 | gitguy | i think when some bugs gets sorted out it will rock even more |
| 23:00.56 | Corydon76-lap | You must be using trixbox |
| 23:00.59 | russellb | ha |
| 23:01.02 | gitguy | no |
| 23:01.04 | gitguy | plain asterisk |
| 23:01.08 | russellb | glad you think it's simple |
| 23:01.11 | gitguy | err, i read wrong |
| 23:01.15 | russellb | i've never heard that compliment before :) |
| 23:01.25 | gitguy | it's simple |
| 23:01.27 | Corydon76-lap | I've heard a lot of things, but I've never heard the configuration called simple before |
| 23:01.30 | gitguy | better than editing xml imho |
| 23:01.32 | russellb | Corydon76-dig: yeah, ha |
| 23:02.04 | Corydon76-lap | gitguy: we have resisted several attempts of people wanting us to adopt xml for configuration files. |
| 23:02.40 | russellb | hey guys, xml makes everything better |
| 23:03.02 | gitguy | :S |
| 23:03.28 | gitguy | well in some way is simple |
| 23:03.28 | Corydon76-lap | Yeah, I remember Walmart.com version 1.0, where our vendor files (in xml, to their specification) caused their parser to blow up |
| 23:03.41 | gitguy | but i think plain text is better for doing things fast |
| 23:04.00 | gitguy | 19:00 <@Corydon76-lap> You must be using trixbox |
| 23:04.03 | gitguy | why is that btw? |
| 23:04.12 | russellb | since you called it easy ... |
| 23:04.15 | Corydon76-lap | and what was great was that it didn't blow up immediately. The parser sat there grinding away at the hard disk for 20 minutes before it finally blew up |
| 23:04.20 | gitguy | cli ftw |
| 23:12.03 | gitguy | simplicity of configuration is why i stick with asterisk |
| 23:12.34 | gitguy | and it has the applications i want, etc |
| 23:14.39 | gitguy | yaml is better than xml imho |
| 23:14.41 | gitguy | more simple |
| 23:15.07 | gitguy | but still, plain text beats it for simplicity imho |
| 23:35.22 | gitguy | 123,1,Application() is simple than adding a bunch of XML |
| 23:35.31 | gitguy | same with foo=bar |
| 23:35.53 | gitguy | that's why i love linux/unix "keep it simple" |
| 23:36.16 | gitguy | well, one of the reasons of why i love ;) |
| 23:37.43 | gitguy | simplicity but by not sacrificing flexibility... |
| 23:37.53 | gitguy | (a la GNOME) :P |
| 23:39.02 | gitguy | but i guess that's too offtopic |
| 23:40.13 | gitguy | anyways, keep up the great work |
| 23:40.14 | gitguy | ;) |
| 23:56.22 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 23:57.56 | gitguy | should i use latest 1.6 for production? |
