| 00:12.50 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:16.31 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 01:23.35 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 01:36.32 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 01:58.06 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 02:27.56 | *** join/#asterisk-dev putnopvut (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 02:27.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 03:22.25 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583156.dsl.bell.ca) |
| 05:52.02 | moy | anybody still around? gotta question about ast_queue_hangup |
| 05:55.30 | JerJer | ask it |
| 05:58.42 | moy | well, I was just wondering when one should choose ast_queue_hangup over directly using p->owner->_softhangup |= AST_SOFTHANGUP_DEV ... I even see some cases in chan_zap where both are used even tho ast_queue_hangup already does that |
| 06:00.09 | moy | the obvious reason that comes to my mind is when you need a *reason*, but even ast_queue_hangup seems to handle no-reason conditions |
| 06:03.32 | moy | probably ast_queue_hangup should replace direct manipulations of _softhangup member? but just has not been coded |
| 06:06.20 | mvanbaak | ast_queue_hangup will be reverted to 1 argument again soon |
| 06:06.47 | mvanbaak | and a new function: ast_queue_hangup_with_cause will be introduced |
| 06:07.51 | moy | mvanbaak: so, am I correct in that _softhangup should not be modified directly anymore and use ast_queue_hangup or ast_queue_hangup_with_cause? |
| 06:10.23 | mvanbaak | I think so. |
| 06:11.34 | mvanbaak | there are more places where _softhangup is directly modified |
| 06:12.04 | mvanbaak | h323, mgcp, iax, sip and zap |
| 06:12.34 | mvanbaak | ast_queue_hangup_with_cause <--- only present in my local tree |
| 06:12.39 | mvanbaak | not yet in trunk |
| 06:15.01 | moy | yeah, as I said, even there are places in chan_zap where both _softhangup and ast_queue_hangup are being used one after the other, useless indeed |
| 06:15.27 | moy | well, 1 place |
| 06:27.55 | mvanbaak | hhmm |
| 06:54.29 | jmls | morning people ;) |
| 07:57.55 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 08:08.07 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 08:24.21 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 08:24.21 | *** mode/#asterisk-dev [+o tzafrir_home] by ChanServ |
| 08:28.41 | *** join/#asterisk-dev jeremy_g (n=jerms@static-213-115-44-90.sme.bredbandsbolaget.se) |
| 08:32.34 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 08:39.06 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:47.19 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 09:15.29 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-68-53-81-14.hsd1.ky.comcast.net) |
| 09:16.48 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 09:18.17 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:35.14 | *** part/#asterisk-dev bkw_ (n=brian@adsl-70-234-182-53.dsl.tul2ok.sbcglobal.net) |
| 10:03.08 | *** join/#asterisk-dev eurodrew555 (n=andrews@83-244-164-142.cust-83.exponential-e.net) |
| 10:04.04 | eurodrew555 | is anyone free to look at an ISDN disconnect issue (we are hanging up, getting a disconnect notification but Asterisk is not hanging up) ? |
| 10:04.06 | eurodrew555 | http://pastebin.com/d7a4d53a |
| 10:04.20 | eurodrew555 | that is the output from the pri debug |
| 10:05.00 | eurodrew555 | trying to get to the bottom as to why Asterisk isn't hanging up the channel |
| 10:33.05 | tzafrir_home | eurodrew555, IIRC the disconnect is not the final message. There's still a RELEASE to follow |
| 10:33.31 | eurodrew555 | Hi tzafrir |
| 10:34.11 | eurodrew555 | thats all I'm getting back from our telco |
| 10:34.38 | eurodrew555 | I dial in, testing, I hang up, we get the disconnect but nothing else, then get a carrier message played 'The other person has hung up' |
| 10:35.03 | eurodrew555 | I have upgraded Zaptel a number of times recently |
| 10:35.41 | eurodrew555 | might rollback to a previous version, but then everything else is working perfectly |
| 10:36.01 | eurodrew555 | opened a ticket with our telco, but they think the problem is on our side |
| 10:39.17 | tzafrir_home | With higher-level PRI issues, Zaptel doesn't have that much of a role to play |
| 10:39.24 | tzafrir_home | that's libpri and Asterisk |
| 10:43.25 | eurodrew555 | running through some changes on zapata.conf |
| 10:46.25 | *** join/#asterisk-dev RoyK (n=roy@213.160.242.90) |
| 10:58.35 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:08.49 | eurodrew555 | hi tzafrir, I've run through all possible changes to zapata.conf I can think of, if I'm only getting a disconnect without release.. then the fault is with the telco right? |
| 11:08.55 | eurodrew555 | possibly? |
| 11:29.04 | *** join/#asterisk-dev seanbright (n=sean@c-69-251-175-43.hsd1.md.comcast.net) |
| 12:03.38 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 12:20.50 | *** join/#asterisk-dev jeffg (i=oLCMUYva@pdpc/supporter/active/jeffg) |
| 12:43.43 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 13:26.55 | tzanger | woot |
| 13:30.59 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 13:30.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:48.21 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:48.21 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:48.26 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:56.23 | *** join/#asterisk-dev jeffspeff (n=jeff@c-68-53-81-14.hsd1.ky.comcast.net) |
| 13:57.26 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 13:57.26 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:00.33 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:00.33 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:03.09 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.205.41) |
| 14:03.36 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583659.dsl.bell.ca) |
| 14:09.34 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:13.28 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 14:13.28 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 14:13.41 | file | hugs Cresl1n |
| 14:27.08 | ctooley | russellb, Corydon76-dig If there is a circumstance in Asterisk 1.4 where ExternalIVR can get hung due to a file descriptor going away and the channel never moves on (it just hangs trying to read the fd), would the patch to resolve it be a bug fix for 1.4 or code for new code for 1.6? |
| 14:28.05 | ctooley | Because I'm running the 1.6 version of EIVR() in asterisk 1.4 (slightly modified to run in 1.4) and I've fixed it, but if it's not going to be able to go into 1.4 I'm not going to spend the time to come up with a patch for that version too. |
| 14:28.53 | russellb | sounds like a bug, so yeah, fine for 1.4 |
| 14:29.56 | ctooley | ok, I'll submit a patch for both. |
| 14:33.18 | russellb | thanks! |
| 14:39.09 | ctooley | It's a lot less likely to occur in 1.4 because there's no tcp socket support there, but it is actually a possibility |
| 14:39.28 | ctooley | do you want this for 1.6.0 or for trunk? |
| 14:40.05 | russellb | trunk is fine |
| 14:40.12 | ctooley | ok |
| 14:47.32 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 14:49.23 | russellb | mvanbaak: ping |
| 14:58.31 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 14:59.28 | JunK-Y | i will publish a patch to automatiquely switch from spying to whispering when pressing dtmf |
| 14:59.49 | JunK-Y | but i found theres no option to spy to an active conversation |
| 15:00.00 | JunK-Y | not spy, whisper sorry |
| 15:00.16 | JunK-Y | so both can hear like the manager |
| 15:01.02 | tzanger | help me |
| 15:01.05 | tzanger | I'm drowning in paperwork |
| 15:08.35 | ctooley | pasting patches now. |
| 15:08.39 | ctooley | err posting |
| 15:14.24 | russellb | thanks |
| 15:14.43 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:19.47 | *** join/#asterisk-dev snuff-home (i=snuff@C-59-101-239-68.bur.connect.net.au) |
| 15:37.44 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 15:37.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:05.28 | *** join/#asterisk-dev RoyK (n=roy@cnbokcafe.uio.no) |
| 16:15.27 | *** join/#asterisk-dev xrg_ (n=panos@cpe026032.netone.gr) |
| 16:22.52 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 16:32.12 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.110.169) |
| 16:43.21 | jmls | putnopvut: ping |
| 16:43.28 | putnopvut | jmls: pong |
| 16:43.36 | putnopvut | Did it happen? |
| 16:43.40 | jmls | could ctooley's problem be related to mine ? |
| 16:43.46 | jmls | (no, it hasn't) |
| 16:43.59 | putnopvut | jmls: not sure, but if I were to go with my gut, I'd say no. |
| 16:44.05 | jmls | sighs |
| 16:44.06 | putnopvut | So probably yes :) |
| 16:44.11 | jmls | heh |
| 16:44.13 | ctooley | jmls, I'm trying to remember what your problem was. :) |
| 16:44.27 | ctooley | has a lot of problems, some of them are even asterisk related. |
| 16:45.03 | jmls | ctooley: putnopvut knows a lot more about my problem than I do :) |
| 16:45.33 | ctooley | jmls, yeah, but what was the initial issue? |
| 16:45.49 | putnopvut | ctooley: jmls was experiencing a problem where the ARRAY function was getting stuck. Since it was in a MacroExclusive, it meant no other calls could enter that Macro. |
| 16:46.01 | ctooley | ah |
| 16:46.11 | ctooley | I don't think I'm experiencing anything like that. |
| 16:46.13 | putnopvut | By "getting stuck" I mean that it was hanging, apparently due to autoservice being stopped on the channel. |
| 16:46.43 | ctooley | what "problem" of mine were you referencing that could be related? |
| 16:47.05 | ctooley | I bug I just filed today? |
| 16:47.18 | ctooley | Because that was causing hung channels, but due to a very specific issue. |
| 16:47.34 | *** join/#asterisk-dev ssokol (n=ssokol@ip68-0-127-59.tu.ok.cox.net) |
| 16:47.35 | ctooley | which is "fixed" in the patch I submitted. |
| 16:47.52 | ctooley | It's actually a detection of the issue and moving on more than anything. |
| 16:48.12 | putnopvut | ctooley: was your issue app_externalivr-specific? |
| 16:48.47 | ctooley | "I have file descriptor", "I read from file descriptor", "I copy file descriptor...", "crap, copy didn't work", "oh well, guess it's gone", "exit -1" |
| 16:48.51 | ctooley | putnopvut, yes |
| 16:49.19 | putnopvut | Okay, that's what I thought. |
| 16:49.34 | putnopvut | On a completely unrelated note: |
| 16:49.40 | ctooley | putnopvut, and it is "possible" in the 1.4 version of app_externalivr, but very unlikely. I submitted a patch for it anyway. But, it's more likely in the trunk version when using tcp sockets. |
| 16:50.22 | putnopvut | ctooley: Ah, yeah because of "half-open" sockets? |
| 16:50.31 | ctooley | putnopvut, sort of... |
| 16:50.33 | putnopvut | s/sockets/connections/ |
| 16:51.14 | ctooley | It appears that if the system is under enough load, asterisk won't read from the socket until after the other end has closed the connection and linux was just tearing down both ends. |
| 16:52.33 | ctooley | In app_externalivr there's nothing on the asterisk side that responds to an "exit". In the 99.9% case, that's not an issue, in our case we were starting up and shutting down a large number of connections very quickly. The other end sends "E,TIMESTAMP" and then closes the connection. |
| 16:53.20 | ctooley | Since the remote end is consuming 3 of the 4 CPUs and MySQL is consuming a large number of cpu time asterisk has to compete for compute cycles and it's not getting the data off the socket fast enough. |
| 16:53.59 | putnopvut | ctooley: okay, thanks for explaining. |
| 16:55.02 | ctooley | In general though... we're pretty happy with the performance we're getting out of chan_sip and app_externalivr, considering the challenges in them both. |
| 16:55.24 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:55.38 | putnopvut | I've got an svn question for any who may be interested. |
| 16:55.46 | Qwell | putnopvut: shoot |
| 16:55.54 | putnopvut | I'm trying to merge the urgent message support branch to trunk. |
| 16:56.07 | putnopvut | For some reason, svn wants to delete the doc/janitorprojects.txt file. |
| 16:56.21 | Qwell | is the branch up to date? |
| 16:56.23 | putnopvut | I want to somehow remove that from its ... "agenda" |
| 16:56.29 | putnopvut | Qwell: yep, just updated it. |
| 16:56.38 | putnopvut | For sanity's sake, I'll do it again. |
| 16:56.40 | ctooley | putnopvut, does doc/janitorprojects.txt exist in the branch? |
| 16:56.57 | Qwell | if automerge was doing it's job, it should |
| 16:57.00 | putnopvut | ctooley: I would assume not, but I'll check. |
| 16:57.12 | putnopvut | Qwell: automerge has not been doing its job :( |
| 16:57.15 | Qwell | putnopvut: you could just revert that file though |
| 16:57.27 | putnopvut | Qwell: oh, duh... |
| 16:57.40 | putnopvut | Sometimes I can be a bit dense. |
| 16:57.56 | putnopvut | But the file does exist in the developer branch. |
| 16:58.00 | putnopvut | Which is a tad weird. |
| 16:58.04 | Qwell | is it deleting then re-adding it? |
| 16:58.14 | Qwell | show me the line from svn st after you merge |
| 16:58.16 | putnopvut | I'll double-check, but I think not. |
| 16:58.47 | putnopvut | Qwell: re-doing the merge now... |
| 16:59.15 | Qwell | if it's an R rather than a D, you're probably okay |
| 16:59.21 | putnopvut | It was a D |
| 16:59.26 | putnopvut | Before anyway. |
| 16:59.28 | Qwell | D +? |
| 16:59.39 | Qwell | err, wait, no |
| 17:00.11 | putnopvut | standby |
| 17:00.27 | putnopvut | D doc/janitor-projects.txt |
| 17:00.35 | Qwell | that's funky |
| 17:00.43 | putnopvut | yep. |
| 17:00.47 | putnopvut | I'll just revert it. |
| 17:10.53 | jpeeler | is there a direct replacement for ast_restrdupa from 1.4? |
| 17:12.04 | putnopvut | jpeeler: not sure about that. |
| 17:12.18 | putnopvut | I can't say I've ever actually used ast_restrdupa. |
| 17:12.40 | jpeeler | it was never used |
| 17:15.33 | Corydon76-dig | No, there's no replacement, because it's not a really good idea |
| 17:20.18 | jpeeler | how about ast_channel_whisper_start, feed, stop |
| 17:20.37 | putnopvut | jpeeler: I think that stuff is replaced by audiohooks API. |
| 17:20.49 | jpeeler | like ast_audiohook_init |
| 17:21.01 | file | nods |
| 17:21.06 | file | replaceddddd |
| 17:22.39 | *** join/#asterisk-dev RoyK (n=roy@cnbokcafe.uio.no) |
| 17:46.37 | jpeeler | so is ast_channel_whisper_stop replaced by ast_audio_hook_lock,detach,unlock,destroy? |
| 17:47.48 | file | nods |
| 17:48.26 | jpeeler | and ast_audiohook_init handles both ast_channel_whisper_start and feed? |
| 17:49.53 | file | ast_audiohook_init initializes the audiohook, you have to call ast_audiohook_write_frame to feed in audio |
| 17:50.10 | *** join/#asterisk-dev hugorebelo (n=hugorebe@c90695e3.static.spo.virtua.com.br) |
| 18:02.09 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:31.53 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:40.12 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 18:53.40 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 18:55.34 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:18.24 | jpeeler | file: thanks, what benefit does the audiohooks system provide? |
| 19:18.54 | russellb | hotness |
| 19:19.06 | jpeeler | can i write that in the doc? |
| 19:19.11 | jpeeler | ha |
| 19:19.18 | file | contemplates |
| 19:19.21 | russellb | http://www.russellbryant.net/blog/index.php/2007/09/05/new-asterisk-api-audiohooks/ |
| 19:19.32 | file | yesssssss |
| 19:21.25 | jsmith-teaching | Yay for audio hooks! |
| 19:22.26 | jpeeler | so "intercepting" the audio was not possible in 1.4? |
| 19:23.12 | file | it was using the old chanspy architecture, but it had issues |
| 19:24.08 | jsmith-teaching | russellb: Are you serious about wanting application ideas for audiohooks? |
| 19:24.10 | jpeeler | like bugs or implementation issues |
| 19:24.16 | jsmith-teaching | jpeeler: Like crash bugs ;-) |
| 19:24.28 | jpeeler | i'm just trying to find an explanation for the API change |
| 19:24.37 | file | crash and implementation issues |
| 19:24.55 | jsmith-teaching | jpeeler: How 'bout "It was easier to rip out the code and do it right than continue to band-aid the old code" |
| 19:25.08 | file | you could listen to the audio, you could maybe whisper audio, but you couldn't modify things... that is another reason |
| 19:25.32 | jpeeler | ok |
| 19:25.34 | putnopvut | Also, the audiohooks API allows for more features to be easily written to manipulate audio streams. |
| 19:26.06 | file | jsmith-teaching: what did you have in mind... |
| 19:27.07 | jsmith-teaching | file: My first suggestion would be "periodic beep"... add an option to beep every X seconds (on either one or more of the channels) while the call is being monitored or recorded by ChanSpy/ExtenSpy/Monitor/MixMonitor |
| 19:27.22 | file | ah |
| 19:32.17 | jsmith-teaching | file: After that, CNG would be the next item on my wish-list, followed by app_parrot ;-) |
| 19:33.15 | putnopvut | what is app_parrot? |
| 19:33.26 | file | putnopvut: ribbit. |
| 19:34.24 | putnopvut | I don't follow. |
| 19:34.46 | russellb | quacks |
| 19:34.58 | Corydon76-dig | oink |
| 19:37.22 | putnopvut | omg, I am so glad that I'm doing some testing before just merging the urgent message support. |
| 19:37.32 | putnopvut | I b0rked it bad in one of my merges. |
| 19:37.43 | putnopvut | Okay, not bad, but there are some kinks. |
| 19:39.01 | file | the kinks! |
| 19:42.04 | russellb | well that really puts a kink in things. |
| 19:42.30 | russellb | but it's not necessarily kinky. |
| 19:42.36 | *** join/#asterisk-dev RoyK (n=roy@cnbokcafe.uio.no) |
| 19:43.47 | ctooley | ponders the implications of making a features.conf contextual and stored in a realtime database. |
| 19:47.00 | *** join/#asterisk-dev PTorres (n=PTorres@200.68.87.146) |
| 19:53.50 | PTorres | hi |
| 19:54.18 | russellb | hi |
| 19:54.21 | file | hi |
| 19:56.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:56.37 | PTorres | I have an issue on * box , it seems that the device state change thread gets locked for exactly 20 seconds ( 1.4.18 ) |
| 19:57.18 | russellb | that's quite odd. |
| 19:57.36 | PTorres | it handles a couple of devices and gets locked again for 20 secs |
| 19:57.55 | PTorres | we can't reproduce that on another server |
| 19:57.56 | russellb | build with DEBUG_THREADS, and grab core show locks output when that happens |
| 19:58.08 | russellb | also, a gdb backtrace of all threads might be useful, too ... |
| 19:58.29 | russellb | just have to figure out what the heck it's waiting on |
| 19:58.35 | PTorres | it didnt crash :D |
| 19:58.47 | russellb | you can attach to the process with gdb |
| 19:58.58 | russellb | sudo gdb /usr/sbin/asterisk `pidof asterisk` |
| 19:59.03 | russellb | thread apply all bt |
| 19:59.13 | russellb | thread apply all bt full |
| 19:59.44 | PTorres | yeah, I forgot, but at this time we downgraded to 1.4.12 |
| 20:24.34 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 20:42.08 | Qwell | mvanbaak: ping |
| 20:42.21 | Qwell | my 7970 that has been reboot cycling for a month just randomly registered to my box :p |
| 20:43.16 | jmls | it's tired and lonely and wants a place it can call home .... |
| 20:55.50 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:08.18 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-7540.bb.online.no) |
| 21:25.37 | *** part/#asterisk-dev PTorres (n=PTorres@200.68.87.146) |
| 21:38.30 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-7540.bb.online.no) |
| 21:45.10 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:58.41 | *** part/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 22:11.51 | *** join/#asterisk-dev RoyK (n=roy@ip-42-56-149-91.dialup.ice.no) |
| 22:28.22 | *** part/#asterisk-dev RoyK (n=roy@ip-42-56-149-91.dialup.ice.no) |
| 22:56.52 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583659.dsl.bell.ca) |
| 23:36.37 | *** join/#asterisk-dev seanbright (n=sean@c-69-251-175-43.hsd1.md.comcast.net) |
| 23:55.24 | snuff-home | M12101 |
| 23:55.26 | MuffinMan | [confirmed] [Asterisk] Channels/chan_sip/General 0012101: SIP channel hung due to CANCEL ReliableXmit (ReTX) reported by MVF (Karma: neutral) http://bugs.digium.com/view.php?id=12101 |
| 23:56.37 | snuff-home | 2 ppl have confirmed patch works.. but would it not be required for neutrino88 to sumbit the patch as code (aka license agreement) before it will be put in? |