| 00:01.47 | Qwell | just...FRACK |
| 00:02.16 | mvanbaak | ah |
| 00:02.16 | Corydon76-lap | mvanbaak: It's a way of saying "fuck" without using a 4-letter word |
| 00:02.37 | mvanbaak | got a bunch of those again while replacing my switch |
| 00:03.07 | Corydon76-lap | Only developers see the warning |
| 00:03.20 | Corydon76-lap | Typical cause is a scheduling problem |
| 00:03.23 | mvanbaak | one for every peer + one |
| 00:04.03 | mvanbaak | Corydon76-lap: I replaced my switch. took out the old one, and 30 seconds later the new one was working |
| 00:04.19 | mvanbaak | so my asterisk box was isolated for 35 seconds |
| 00:04.23 | Corydon76-lap | Usually it means that you hold a lock that a scheduled item needs to complete, and you're holding the lock because you're trying to delete the scheduled item |
| 00:04.37 | mvanbaak | ah |
| 00:04.39 | codefreeze-lap | Qwell: Actually, no, that note is something I think anybody with that particular prob should be able to read... why do you ask? Am I missing something? |
| 00:05.07 | mvanbaak | makes sense with peers that have 'qualify=yes' on a system that gets booted of the network then |
| 00:05.59 | Corydon76-lap | mvanbaak: never seen it on anything other than IAX peers |
| 00:06.15 | mvanbaak | Corydon76-lap: me neither |
| 00:06.35 | Corydon76-lap | mvanbaak: should be fixed in trunk and 1.6.1 branch, though |
| 00:06.48 | mvanbaak | I'm running latest trunk |
| 00:07.47 | Corydon76-lap | Maybe it got re-broken |
| 00:09.52 | mvanbaak | I got to get a storm of those messages on network trouble, but now I only get it once for every peer + one |
| 00:10.36 | mvanbaak | well, zzzzzzzzzzzz time |
| 00:11.05 | Corydon76-lap | Oh, well, that's fixed, then |
| 00:12.34 | Qwell | codefreeze-lap: It is private for some reason. |
| 00:13.18 | codefreeze-lap | Qwell: duh! thanks. I'll unmark that. Boy, am I blind. |
| 00:13.53 | codefreeze-lap | maybe its just palsy or something... ugh. |
| 00:14.07 | lmadsen | codefreeze-lap: welcome to the club... I couldn't see the unsubscribe button on an email from Roger's today and I even called to complain until I finally saw it |
| 00:17.52 | *** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-5d265ee7041eddd5) |
| 00:29.05 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 08:25.08 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 08:54.29 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 11:13.33 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:43.00 | *** join/#asterisk-bugs seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:43.00 | *** mode/#asterisk-bugs [+o seanbright] by ChanServ |
| 12:17.44 | *** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum) |
| 12:20.04 | *** join/#asterisk-bugs gaetronik (n=gaetan@200.111.138.170) |
| 12:21.04 | gaetronik | Hi! |
| 12:21.10 | gaetronik | i want to talk about http://bugs.digium.com/view.php?id=11373 |
| 12:31.40 | *** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum) |
| 13:45.11 | jsmith | gaetronik: Many of the -devs are still asleep... can you ask again in a couple of hours? |
| 13:45.23 | gaetronik | ok |
| 13:45.39 | gaetronik | thanks |
| 13:56.27 | *** join/#asterisk-bugs shido6 (n=shido6@209.114.208.111) |
| 14:00.05 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:00.05 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 14:39.45 | *** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40) |
| 15:21.15 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:32.27 | *** join/#asterisk-bugs MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 15:36.06 | lmadsen | M13468 |
| 15:36.08 | MuffinMan | [feedback] [Asterisk] Channels/chan_iax2 0013468: IAX Transfer/releasing between 3 asterisk's are not working. reported by nicox (Karma: -1.75) http://bugs.digium.com/view.php?id=13468 |
| 15:37.59 | *** join/#asterisk-bugs nicox (n=nicox@dsl-82-106.utaonline.at) |
| 15:38.41 | nicox | Hi |
| 15:38.58 | nicox | is there a chance to get help on the bug: 0013468 ? |
| 15:40.22 | Corydon76-dig | nicox: please try the current SVN 1.6.0 |
| 15:40.45 | Corydon76-dig | the fix in 13645 may have fixed the transfers, too |
| 15:41.11 | seanbright | svn co http://svn.digium.com/svn/asterisk/branches/1.6.0 |
| 15:51.51 | *** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-5d265ee7041eddd5) |
| 15:51.51 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 16:19.27 | *** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-d91de4d1a36c624c) |
| 16:19.27 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:20.58 | shazaum | putnopvut yo |
| 16:21.05 | putnopvut | shazaum: how are you doing? |
| 16:21.47 | shazaum | putnopvut, fine, and u? |
| 16:21.57 | putnopvut | I'm doing good today. |
| 16:22.05 | shazaum | :) |
| 16:22.28 | shazaum | putnopvut, I did a test with its patch but appeared not effect (#13538) |
| 16:22.51 | putnopvut | M13538 |
| 16:22.53 | MuffinMan | [ready for testing] [Asterisk] Applications/app_mixmonitor 0013538: Recording stops after Transfer reported by mbit (Karma: neutral) http://bugs.digium.com/view.php?id=13538 |
| 16:22.56 | putnopvut | :( |
| 16:23.16 | shazaum | yrp |
| 16:23.19 | shazaum | yep |
| 16:23.25 | shazaum | putnopvut, pastebin your dialplan Test |
| 16:23.37 | putnopvut | shazaum: sure thing. Give me a minute. |
| 16:23.41 | shazaum | ok |
| 16:26.12 | putnopvut | http://pastebin.ca/1260485 |
| 16:26.25 | putnopvut | I'm going to try another test where I remove the Answer from extension 123. |
| 16:32.23 | shazaum | ok |
| 16:32.33 | shazaum | putnopvut, see my dialplan http://pastebin.ca/1260491 |
| 16:33.38 | putnopvut | shazaum: I don't know if you did it on purpose, but you commented out the MixMonitor line in the transferencias context. |
| 16:35.12 | shazaum | yep, this was my last test |
| 16:35.38 | shazaum | because the parameters used "ab" |
| 16:35.55 | putnopvut | has forgotten what the 'a' option for MixMonitor does. |
| 16:36.12 | putnopvut | Ah, append to a file instead of overwriting it. |
| 16:36.53 | putnopvut | shazaum: With your current dialplan, I would expect call recording to end after the transfer since the second extension does not use MixMonitor. |
| 16:38.13 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 16:38.14 | putnopvut | oh crap, I just added the 'a' options to my MixMonitor calls and now Asterisk crashed. |
| 16:38.56 | putnopvut | Oh, nevermind, I know what the problem is. |
| 16:48.01 | guax | atxfer problem? |
| 16:49.39 | putnopvut | guax: yeah, specifically, I was testing the patch on issue 13538, and Asterisk crashed at the end of the attended transfer. The crash is one for which I have written a fix though, but which I have not received final approval for committing. |
| 16:50.04 | nicox | Corydon76-dig: thanks, i will try this night! |
| 16:50.09 | guax | humm |
| 16:50.35 | guax | putnopvut: this problem with mixmonitor and transfer is very, very anoying. |
| 16:50.54 | putnopvut | guax: have you tried the patch I uploaded on that issue? |
| 16:51.05 | putnopvut | I think I'm the only person for whom the patch is working, so far. |
| 16:51.13 | *** part/#asterisk-bugs nicox (n=nicox@dsl-82-106.utaonline.at) |
| 16:51.25 | guax | yes, i did receive the email, patch seem doesnt change much |
| 16:52.14 | putnopvut | crap. There's obviously something that I don't understand about the issue here, then. |
| 16:52.35 | guax | same issue but mixmonitor now stops when the transfeer is bridged |
| 16:53.02 | putnopvut | guax: can you pastebin a dialplan sample that I can use for testing? |
| 16:53.36 | guax | exact the same dialplan that shazaum is using |
| 16:55.57 | putnopvut | okay, well, here's the thing. If the second extension doesn't use MixMonitor (shazaum's call to MixMonitor is commented out in the second extension), then the recording is supposed to stop after the call is transferred. |
| 16:57.30 | guax | well, in my understanding mixmonitor (or monitor) should record the current channel (the one who starts the dialplan request etc..) so, everything that happens after a answer should be recorded until a complete hangup, be that a transfer or a music on hold, etc. |
| 16:59.31 | putnopvut | The problem with that is one of "security." The idea is that if you use MixMonitor, then you are giving authority to record the call between person A and person B. If the call then makes it to person C, then we cannot just assume that we have the authority to record that person's conversation, too. |
| 17:00.07 | putnopvut | But, if person C's extension in the dialplan, also contains a call to MixMonitor, then it is clear that it is intended for his conversation to be recorded. |
| 17:00.25 | guax | well. shouldnt that be and option instead? |
| 17:01.06 | guax | well if mixmonitor stops after a transfer i can run it again in the "new" channel and then just append this new recording to the end of the previously recorded file |
| 17:01.26 | guax | but that's not working at all =P |
| 17:02.28 | putnopvut | I see what you're saying. It won't work to continue recording at the end of the previous recording. |
| 17:03.48 | guax | putnopvut: well, i think that if the recording cant be maded in the second channel by legal reasons or security, it should be specified to do not work in another way, like a recording-proof channel or options in the transfer app |
| 17:03.50 | putnopvut | Okay, so my quick fix patch *is* based on a misunderstanding of the problem, and perhaps before throwing something together, I should appeal to the asterisk-dev mailing list and propose some solutions and get feedback from some others. |
| 17:04.22 | putnopvut | Right, this definitely requires more thought than I had previously given it. |
| 17:05.03 | file | putnopvut: it wouldddd be possible to add an option to audiohooks to allow/disallow them to transition between channels during a masquerade |
| 17:05.04 | guax | but, we need to record, thats a fact, lets try to append the second recording or create a new one whatever. |
| 17:05.17 | file | and then expose that |
| 17:06.10 | putnopvut | file: yeah, my first patch was *kind of* like that. |
| 17:06.42 | putnopvut | but like guax said, there needs to be a way that even that option can be overridden, depending on who you are transferring to. |
| 17:07.12 | file | the only thing you'd have a hope of using would be dialplan variables for that |
| 17:07.30 | putnopvut | Actually, there is a stupid way around it. |
| 17:07.47 | putnopvut | Just always call StopMixMonitor before dialing someone if they aren't supposed to have their calls recorded. |
| 17:08.09 | putnopvut | Actually, that won't work, nevermind. |
| 17:08.10 | shazaum | im back |
| 17:09.02 | file | putnopvut: there is a really really really evil way |
| 17:09.15 | putnopvut | I'm open to evil suggestions. |
| 17:09.30 | file | inheritable datastores |
| 17:09.52 | putnopvut | the datastore idea had crossed my mind, actually.... |
| 17:10.43 | file | dialplan functions to enable inheriting of audiohooks and disable it (usable on the channel they would be coming from, and channel they would be going to) |
| 17:10.59 | putnopvut | Okay, now it sounds much more evil than before. |
| 17:11.04 | file | and then it couldddddd do the moving of the audiohooks themselves as well |
| 17:11.46 | file | know what I mean? |
| 17:11.55 | putnopvut | sort of. |
| 17:12.22 | putnopvut | you're saying that on the final leg of the transfer, they can call some dialplan option to inherit the audiohooks from the previous transfer leg? Something like that? |
| 17:12.39 | putnopvut | is probably not understanding your idea correctly. |
| 17:13.01 | file | I'm saying after they call MixMonitor in the dialplan they do something like Set(MOVABLE_AUDIOHOOKS()=MixMonitor) |
| 17:13.16 | file | that creates an inheritable datastore that knows it should move audiohooks of "MixMonitor" when masqueraded |
| 17:13.52 | file | then on the other leg if they want to disable it something like Set(DISABLE_MOVABLE_AUDIOHOOKS()=yes) |
| 17:14.26 | file | so when the masquerade happens the MOVABLE_AUDIOHOOKS() datastore goes over... and as part of the process it checks if a datastore exists that disables moving audiohooks |
| 17:14.37 | file | if not it then looks for audiohooks with the given name on the channel and moves them over |
| 17:15.48 | putnopvut | Sounds good, except that I would suggest that the DISABLE_MOVABLE_AUDIOHOOKS function takes the name of the audiohook to be disabled. |
| 17:15.55 | file | sure |
| 17:15.58 | file | I just randomly chose those :D |
| 17:16.01 | putnopvut | heh |
| 17:16.01 | guax | alternative solution detected :P |
| 17:16.27 | Corydon76-dig | putnopvut: Actually, I'd suggest that you use MOVABLE_AUDIOHOOKS, with the special value "disable" |
| 17:16.46 | file | that would give exactly the control people want |
| 17:17.09 | file | and it is possible to make it a self contained module, so easy for those who need it in older versions to backport |
| 17:17.19 | putnopvut | Okay, I guess my mind is off thinking that there could be multiple types of audiohooks on a channel and that some may want to be preserved across a masquerade while others may not. |
| 17:17.28 | putnopvut | But that could still be done. |
| 17:17.39 | Corydon76-dig | and probably also use any value in ast_false, as well, to disable |
| 17:17.42 | putnopvut | You could disable everything and then re-enable certain audiohooks as movable. |
| 17:17.43 | shazaum | dreams of many workaround |
| 17:18.49 | putnopvut | But here's the problem with all of this. It couldn't be officially supported in 1.4 since it is adding new dialplan functions and such. I could make an unsupported 1.4 version of the patch, though. |
| 17:19.41 | file | that's a problem with anything you go with to try to solve this |
| 17:19.41 | Corydon76-dig | putnopvut: is this functionality that a user could reasonably expect should work in 1.4? |
| 17:19.56 | putnopvut | Corydon76-dig: that is such a loaded question :) |
| 17:20.01 | Corydon76-dig | putnopvut: if that's the case, you can sneak it in under that exception |
| 17:20.10 | guax | i think we can unofficialy use it until a definitive solution comes. |
| 17:20.19 | Corydon76-dig | but generally, I clear those things through Russell, first |
| 17:20.31 | file | if you make it a module we can easily throw it up on community |
| 17:20.32 | putnopvut | Yeah, I'll ask russell what he thinks about it. |
| 17:20.39 | putnopvut | He appears to not be on IRC right now... |
| 17:21.10 | file | trying to concentrate |
| 17:21.12 | file | on evil stuff. |
| 17:21.18 | file | like I should be! |
| 17:22.21 | putnopvut | Yes, he is indeed busy with evil stuff. |
| 17:22.28 | putnopvut | I'll send him an e-mail, though. |
| 17:23.12 | file | that was my fun solving of an issue thing for this week |
| 17:59.12 | lmadsen | putnopvut: ok, about to continue testing that bug you mentioned yesterday |
| 17:59.32 | putnopvut | lmadsen: heh, we've been discussing that one here pretty heavily, actually. |
| 17:59.42 | lmadsen | I was kinda wondering if that's what you were talking about |
| 17:59.54 | lmadsen | is there any point in continuing to test that patch at the current time? |
| 17:59.54 | putnopvut | It probably is not worth your time to test that patch since it doesn't accomplish what people want it to. |
| 18:00.30 | lmadsen | gotcha |
| 18:00.34 | lmadsen | ok... moving on! |
| 18:04.49 | lmadsen | putnopvut: reading above a little bit sure sounds like the same recording issue I described in a recent email |
| 18:06.49 | putnopvut | lmadsen: it is similar, except that in the e-mail that you describe, Monitor was in use instead of MixMonitor, meaning that there aren't any audiohooks involved, which means that it would have to be handled somewhat differently. |
| 18:07.13 | lmadsen | putnopvut: or I could just use MixMonitor() :) |
| 18:07.18 | putnopvut | Mainly due to the fact that there are no audiohooks involved, plus currently, a monitor is automatically inherited by the other channel of a Masquerade. |
| 18:07.36 | lmadsen | sounds like the issue I'm running into, heh |
| 18:08.01 | lmadsen | think if I had switched it to MixMonitor(), then for channels I wanted recorded beyond the transfer, I'd have had the inverse problem |
| 18:09.08 | lmadsen | oh today is payday! |
| 18:09.08 | lmadsen | w00t |
| 18:09.18 | lmadsen | although this entire paycheque is for mortgage and maintenance... burn |
| 18:35.43 | lmadsen | M13923 |
| 18:35.45 | MuffinMan | [new] [Asterisk] Applications/app_parkandannounce 0013923: External calls can initiate blind transfer using feature keys after call is parked reported by dhartman (Karma: neutral) http://bugs.digium.com/view.php?id=13923 |
| 18:41.34 | codefreeze-lap | now that's a juicy looking bug |
| 18:42.05 | codefreeze-lap | that might arise from "role" reversal... maybe... |
| 18:50.15 | lmadsen | mvanbaak: umm... what did we change 'reload' to in trunk? (has that stuff been committed yet?) |
| 18:50.24 | lmadsen | 'core reload' does not exist.. and either does 'reload' |
| 18:52.11 | jsmith | lmadsen: module reload? |
| 18:52.17 | jsmith | throws out random ideas |
| 18:52.39 | jsmith | "All in favor of changing every possible CLI command and doing it now, say aye!" |
| 18:52.46 | lmadsen | aye! |
| 18:52.51 | lmadsen | jsmith: that's what aliases are for :) |
| 18:53.01 | lmadsen | module reload seems to have been it |
| 18:53.36 | codefreeze-lap | "stop now" is now "core stop now".... ehhhhhhhhh |
| 18:54.02 | lmadsen | ya I knew those ones :) |
| 18:54.25 | lmadsen | of all the people who should know... I'm one of them :) |
| 18:54.33 | lmadsen | confuses himself |
| 18:55.39 | jsmith | lmadsen: See the can of worms you opened? |
| 18:55.58 | lmadsen | jsmith: luckily file made an aliases file so if I had installed that I'd not have needed to use the new format :) |
| 18:56.06 | lmadsen | I just feel like being a masochist today |
| 18:56.13 | file | mvanbaak did it! wasn't me... |
| 18:56.22 | lmadsen | file: you started it :) |
| 18:56.26 | jsmith | ~blame file |
| 18:56.27 | infobot | ACTION blames file (and Canada) for all the evil in the world |
| 18:56.30 | lmadsen | we just kinda... finished it |
| 18:56.37 | file | putnopvut: I might poke at that audiohooks thingy tonight... |
| 18:56.47 | file | lmadsen: took it to the extreme! |
| 18:56.55 | lmadsen | that's what I do |
| 18:57.44 | shazaum_away | M13538 |
| 18:57.46 | MuffinMan | [acknowledged] [Asterisk] Applications/app_mixmonitor 0013538: [patch] Recording stops after Transfer when using MixMonitor() reported by mbit (Karma: neutral) http://bugs.digium.com/view.php?id=13538 |
| 18:57.56 | file | I need to code something fun before I go NUTS |
| 18:58.22 | file | bearded_blitz: eep |
| 19:02.42 | bearded_blitz | Corydon76-dig: ping |
| 19:05.48 | bearded_blitz | Syntax: REALTIME_FIELD(family,fieldmatch,value,fieldname) |
| 19:05.59 | bearded_blitz | anyone else know what those fields are referring to? |
| 19:06.26 | jsmith | Sure... the family is things like sip, etc. |
| 19:06.36 | bearded_blitz | like sippeer ya... that's the only one I know |
| 19:06.51 | bearded_blitz | I'd guess the family name in extconfig.conf |
| 19:06.52 | jsmith | The fieldmatch is which field in the table we're going to match on |
| 19:07.26 | jsmith | So if you had "fieldmatch" = 'host' and "value" = '192.168.123.222' |
| 19:07.43 | bearded_blitz | and then fieldname is the value to return from some other column |
| 19:07.46 | jsmith | Then it would give you the value of the "fieldname" field for the matching record |
| 19:07.49 | bearded_blitz | ok... thats starting to make a bit more sense then |
| 19:07.51 | jsmith | Bingo! |
| 19:07.53 | jsmith | You've got it! |
| 19:07.57 | bearded_blitz | ok, let me test |
| 19:08.01 | bearded_blitz | thanks for the example |
| 19:08.10 | bearded_blitz | obviously needs to modify this patch to add some docs |
| 19:16.20 | bearded_blitz | jsmith: have a quick second to do a sanity check here? |
| 19:16.21 | bearded_blitz | http://bugs.digium.com/view.php?id=13651#94996 |
| 19:16.38 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 19:17.08 | *** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-547c915ba480e7ce) |
| 19:17.08 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 19:18.40 | jsmith | bearded_blitz: According to my limited understanding, you've done the right thing. |
| 19:18.45 | bearded_blitz | ok thanks |
| 19:19.00 | bearded_blitz | just wanted to see if you happened to see something obviously wrong |
| 19:19.56 | jsmith | Nothing jumps out at me, no |
| 19:20.11 | jsmith | That being said, it's been at least two years since I touched realtime |
| 19:27.38 | bearded_blitz | jsmith-food: no problem... was just looking for a quick sanity check |
| 19:27.51 | bearded_blitz | Corydon76-dig: don't think I'll be able to test 13136 |
| 19:28.16 | Corydon76-dig | bearded_blitz: why not? |
| 19:28.29 | bearded_blitz | does polycom phones support SIP TCP? |
| 19:28.33 | bearded_blitz | (that's the issue right?) |
| 19:29.21 | Corydon76-dig | I think they do |
| 19:30.20 | bearded_blitz | ok, let me try to enable TCP for this phone then |
| 19:30.51 | Corydon76-dig | We generally just turn it off by default, though |
| 19:31.44 | bearded_blitz | and this is only happening on 1.6.0 ? |
| 19:32.35 | Corydon76-dig | 1.4 doesn't have TCP support |
| 19:32.52 | bearded_blitz | I meant this isn't an issue beyond 1.6.0? (that's what the thread says) |
| 19:33.22 | Corydon76-dig | I suspect it is an issue, and something else is masking it |
| 19:33.46 | bearded_blitz | ok, well I'll try to reproduce on 1.6.0 in order to avoid the masking |
| 19:34.23 | bearded_blitz | basically i was asking what version to try reproducing on |
| 19:37.02 | Qwell | M13577 |
| 19:37.04 | MuffinMan | [new] [Asterisk] Channels/chan_iax2 0013577: [feature request] Reporter would like an option to ignore src ports in iax2 reported by ffadaie (Karma: +0.50) http://bugs.digium.com/view.php?id=13577 |
| 19:37.04 | Qwell | Can we close that again? |
| 19:39.43 | bearded_blitz | Ummm... sure :) |
| 19:48.29 | mvanbaak | bearded_blitz: reload has been deprecated for some time |
| 19:48.36 | mvanbaak | bearded_blitz: it's 'module reload' |
| 19:48.55 | bearded_blitz | mvanbaak: ya, I hadn't programmed that one into my brain yet :) |
| 19:49.11 | mvanbaak | no problem :) |
| 19:49.22 | mvanbaak | <--- just got home and saw your line in my awaylog |
| 19:49.40 | mvanbaak | and not feeling into reading logfiles so just replied ;) |
| 19:49.58 | bearded_blitz | heh |
| 19:54.15 | bearded_blitz | wonders how the heck he didn't have gdb installed on his development system |
| 19:55.22 | jsmith | bearded_blitz: Some developer you are! |
| 19:55.24 | jsmith | ducks and hides |
| 19:55.27 | bearded_blitz | :) |
| 19:55.32 | bearded_blitz | throws a snowball at jsmith |
| 19:58.16 | bearded_blitz | putnopvut: hrmmm... I'm running your command of gdb /usr/sbin/asterisk `pidof asterisk` from the 13136 bug, but it doesn't seem to be doing anything? (no error... ?) |
| 19:58.35 | putnopvut | M13136 |
| 19:58.37 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/General 0013136: [patch] sip peer qualified failed, asterisk lock. reported by pabelanger (Karma: +33.50) http://bugs.digium.com/view.php?id=13136 |
| 19:58.57 | putnopvut | bearded_blitz: I'm trying to get caught up on what the issue was |
| 19:59.14 | bearded_blitz | the tcp locking issue basically |
| 20:00.15 | putnopvut | Okay, so from a command line you did that gdb command, right? |
| 20:00.22 | bearded_blitz | yes |
| 20:00.29 | putnopvut | That will just attach gdb to the running Asterisk process. |
| 20:00.42 | bearded_blitz | slaps forehead |
| 20:00.44 | bearded_blitz | thx |
| 20:00.47 | putnopvut | From there, you need to issue the "thread apply all bt full" command to get the backtrace of all the threads. |
| 20:01.22 | putnopvut | but, actually bearded_blitz, it looks like you may not need to do that. |
| 20:01.27 | bearded_blitz | I see |
| 20:01.32 | putnopvut | Because pabelanger already gave a backtrace, which I looked at. |
| 20:01.44 | Corydon76-dig | Usually, I just do: gdb -p `pidof asterisk` |
| 20:02.21 | bearded_blitz | oh wait.. that lock output is just from DEBUG_THREADS right? |
| 20:02.23 | jsmith | Yeah... the -p is important |
| 20:02.36 | bearded_blitz | or is it DEBUG_CHANNEL_LOCKS? |
| 20:02.45 | putnopvut | DEBUG_THREADS |
| 20:02.52 | bearded_blitz | okie |
| 20:03.12 | putnopvut | is of the opinion that DEBUG_CHANNEL_LOCKS is useless and should be removed...but that may just be him, though. |
| 20:03.27 | bearded_blitz | also confusing to people who are trying to debug locks :) |
| 20:03.36 | putnopvut | yes, agreed. |
| 20:04.06 | bearded_blitz | compiles! |
| 20:19.42 | Corydon76-dig | putnopvut: I think I agree |
| 20:22.40 | bearded_blitz | Corydon76-dig: so this should lock should the phone become unavailable for the qualify? |
| 20:23.34 | Corydon76-dig | bearded_blitz: It should hang for 3 minutes or so |
| 20:23.43 | bearded_blitz | when? |
| 20:23.44 | Corydon76-dig | and process no further SIP messages |
| 20:23.55 | bearded_blitz | when qualify is unanswered? |
| 20:24.26 | Corydon76-dig | Without the patch, if the connect hangs, then the SIP monitor thread will also hang |
| 20:24.45 | bearded_blitz | ok... new approach: how do I reproduce this issue? |
| 20:25.46 | Corydon76-dig | I believe the approach was to use a firewall that dropped all packets on port 5060 |
| 20:26.27 | Corydon76-dig | and then you're stuck waiting on a connection that will never succeed |
| 20:26.39 | *** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum) |
| 20:27.08 | bearded_blitz | ok.. so if I setup the firewall on this VM and block 5060 from the phone connecting it should reproduce, or does the FW need to be in front of the phone? |
| 20:36.51 | bearded_blitz | aha! |
| 20:36.56 | bearded_blitz | I think I reproduced it |
| 20:37.08 | bearded_blitz | yep! |
| 20:37.09 | bearded_blitz | w00t |
| 20:37.11 | Corydon76-dig | bearded_blitz: woot |
| 20:37.25 | bearded_blitz | Thread ID: 1079638336 (do_monitor started at [19062] chan_sip.c restart_monitor()) |
| 20:37.35 | bearded_blitz | ---> Lock #0 (chan_sip.c): MUTEX 19032 do_monitor &monlock 0x2aaac5cbf900 (1) |
| 20:37.56 | Corydon76-dig | Okay, good, then you can apply the patch and see if it fixes the issue |
| 20:38.05 | bearded_blitz | aye |
| 20:38.42 | putnopvut | M13496 |
| 20:38.44 | MuffinMan | [ready for testing] [Asterisk] Resources/res_musiconhold 0013496: Crash in res_musiconhold reported by fst-onge (Karma: neutral) http://bugs.digium.com/view.php?id=13496 |
| 20:39.30 | putnopvut | I'm about 97% certain that the patch I uploaded there is right and will fix the issue. I base this on the fact that I was able to capture the memory corruption with valgrind, and when I applied this patch, the memory access issues were gone. |
| 20:39.51 | putnopvut | The trouble is that it's not something I can easily ask someone to reproduce. |
| 20:40.10 | putnopvut | eh, and it's only been six days since I uploaded the patch. |
| 20:40.19 | putnopvut | Nevermind, I'll give the reporter longer to give feedback. |
| 20:40.24 | putnopvut | ignore me |
| 20:40.49 | Corydon76-dig | ignores putnopvut |
| 20:41.12 | putnopvut | by doing what I said to do, you are not ignoring me. Ha! It was a trick! |
| 20:41.45 | Corydon76-dig | gives putnopvut a cookie |
| 20:41.52 | putnopvut | thank you kindly |
| 20:42.03 | Corydon76-dig | It's a rocket ship. ;-) |
| 20:42.28 | Corydon76-dig | Ask Matt, Jeff, or Dwayne about that cookie |
| 20:43.47 | putnopvut | I get the Death to Smoochy reference. |
| 20:45.01 | Corydon76-dig | Deeewayne: ping |
| 20:46.28 | Deeewayne | cookies ? |
| 20:46.59 | Deeewayne | putnopvut: did you have a ginger cookie ? |
| 20:47.15 | putnopvut | I did not. |
| 20:47.40 | Deeewayne | You missed out. |
| 20:47.42 | putnopvut | Corydon76-dig: did you happen to leave any of these unique cookies in your office? |
| 20:55.49 | Corydon76-dig | putnopvut: sorry, no |
| 20:56.06 | Corydon76-dig | putnopvut: I took them home and ate them |
| 20:56.14 | putnopvut | Good plan |
| 20:56.22 | Corydon76-dig | I can make more for next week, if you like, though |
| 20:56.49 | *** join/#asterisk-bugs mnicholson (n=mnichols@nat/digium/x-be808b8e97f46420) |
| 21:13.17 | putnopvut | Corydon76-dig: don't go to the effort just for me. |
| 21:13.52 | Corydon76-dig | putnopvut: Well, if more people want cookies, I can just make smaller ones |
| 21:14.07 | Corydon76-dig | I have the cookie cutters |
| 21:16.36 | Corydon76-dig | I just wish the other Mark were there, so I could share some with him |
| 21:16.49 | putnopvut | lollerskates |
| 21:20.07 | Deeewayne | Corydon76-dig: I saw him yesterday |
| 21:22.43 | Corydon76-dig | Deeewayne: aww, shucks |
| 21:31.50 | Deeewayne | I was going to send him to get a cookie too. :-( I guess I should have |
| 22:28.00 | *** join/#asterisk-bugs jsmith (n=jsmith@72.21.36.138) |
| 22:28.00 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 23:21.27 | *** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-547c915ba480e7ce) |