| 02:38.08 | *** join/#asterisk-bugs mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 03:34.36 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:34.36 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 04:07.54 | *** join/#asterisk-bugs putnopvu1 (n=putnopvu@216.207.245.1) |
| 05:04.39 | *** join/#asterisk-bugs implicit (i=implicit@gateway/tor/x-40c41249edd52d64) |
| 05:04.39 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 07:19.57 | *** join/#asterisk-bugs implicit (i=implicit@gateway/tor/x-2f2804fba5bdab03) |
| 07:19.57 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 07:57.06 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 12:13.19 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 12:13.19 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 12:23.55 | *** join/#asterisk-bugs flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 12:40.22 | flujan | putnopvu1: ping :) |
| 13:03.19 | file | he is not awake yet. |
| 13:07.28 | mvanbaak | sleepy head |
| 13:07.43 | flujan | :D |
| 13:39.01 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 13:47.21 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:47.21 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 14:13.55 | *** join/#asterisk-bugs mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 14:19.34 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:19.34 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 14:23.13 | *** join/#asterisk-bugs d2mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 14:23.47 | d2mas | file: morning :) I have something for you :) - 11873 |
| 14:24.09 | file | I saw. |
| 14:24.38 | d2mas | heh |
| 14:26.49 | d2mas | initially I added one more option for ast_setoption / ast_queryoption - it was controlling whether channel driver should automatically accept T38 offered by the remote peer. But I removed that piece from the patch because I doubt it has any use right now. And after all it is better to make changes in baby-steps :) |
| 14:37.54 | lmadsen | putnopvu1: ping! |
| 14:44.43 | putnopvu1 | lmadsen: pong...damn this putnopvu1 crap |
| 14:44.49 | lmadsen | heh :) |
| 14:44.55 | lmadsen | putnopvu1: mind calling me at 6105 for 2 mins? |
| 14:45.04 | putnopvu1 | lmadsen: no prob |
| 14:45.08 | lmadsen | coolio |
| 14:45.20 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:45.22 | file | it's a trap! |
| 14:52.21 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:57.22 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 14:57.22 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:57.32 | putnopvut | flujan: pong |
| 15:04.09 | putnopvut | flujan: I don't know if you saw it or not, but you were right about the memory leak in the realtime queue code. I fixed it in SVN revision 101035. |
| 15:05.48 | d1mas | downgraded :) |
| 15:06.37 | flujan | putnopvut: wonderful. :D |
| 15:06.40 | flujan | where it was? |
| 15:07.17 | putnopvut | It was in the update_realtime_members function. The ast_config that was loaded was not being freed. |
| 15:07.47 | flujan | putnopvut: cool. |
| 15:09.26 | flujan | I also checked your patch to issue 11862. You said there is a problem with the lock order on the remove_from_interfaces |
| 15:09.35 | flujan | but this function is only used for realtime queues? |
| 15:10.38 | flujan | I checked the app_queue.c code and saw it being used on a couple of functions... free_members, find_queue_by_name_rt,reload_queues and remove_from_queue. |
| 15:11.15 | flujan | are this functions only used on realtime queues? |
| 15:14.21 | putnopvut | No, remove_from_interfaces is used in non-realtime queues as well. |
| 15:16.07 | flujan | so ... that is the point... :) |
| 15:16.26 | flujan | why the locks are just happening on the realtime queues? |
| 15:16.41 | flujan | I am running the static queues well since yesterday... |
| 15:16.44 | flujan | :D |
| 15:16.59 | putnopvut | The reason it happens more on realtime queues is because if you're not using realtime queues, the only time that remove_from_interfaces might be called is during a reload. |
| 15:17.06 | putnopvut | So it is much less likely to cause a deadlock. |
| 15:17.17 | flujan | humm... good... |
| 15:17.21 | flujan | thanks for the tip. :D |
| 15:17.31 | flujan | I am starting to understand the app_queue.c code. :D |
| 15:17.40 | putnopvut | Cool! |
| 15:17.51 | flujan | putnopvut: yeap Very cool. :D |
| 15:18.37 | flujan | putnopvut: I will see with my boss where I can stop the server and test the patch. :D |
| 15:19.03 | flujan | putnopvut: He just hate the production server stoping randomly. :D |
| 15:19.56 | Juggie | flujan, you would be one of the few who does understand it then :) |
| 15:20.17 | putnopvut | flujan: I understand. There's no rush on getting it tested. |
| 15:21.07 | flujan | Juggie: well, I already look at it... specifically the try_calling function in the past... Queues just takes a long time to deliver calls to my agents... I solved it putting a call-limit=1 on then. |
| 15:21.32 | flujan | but I also feel that there is another bug that I will report... Just making sure... |
| 15:21.59 | flujan | it is related to the busy-level and call-limit on the sip.conf. |
| 15:22.18 | flujan | I will do additional tests and then I post it on mantis. |
| 15:45.45 | file | M11861 |
| 15:45.46 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_sip/Interoperability 0011861: "auth" doesn't work inside a [peer] reported by ibc http://bugs.digium.com/view.php?id=11861 |
| 15:46.05 | file | oej: I was following the code for that... and i can't actually see where the auth in the peer entry is used (looks like it isn't)... 'nor where that code came from |
| 15:52.17 | oej | I will take that |
| 15:52.32 | oej | I made the code ages ago, and it surely worked then |
| 15:52.44 | oej | (wouldn't have gotten paid otherwise) |
| 15:53.13 | file | non-peer works, just the peer part |
| 15:53.26 | oej | Yes, it was a bit complicated |
| 15:56.07 | oej | And now it's gone |
| 15:56.26 | oej | I think it should be in build_reply_digest |
| 15:57.10 | file | we can certainly go back and see how it was, I just couldn't find a revision that gave me what I wanted (all the ones that came up were doxygen/doc changes) |
| 15:57.33 | oej | Hmm. I can check if I still have the patch around... Wait |
| 15:57.36 | oej | You are on hold |
| 15:57.51 | file | ABBA hold music? |
| 15:58.41 | *** join/#asterisk-bugs seanbright (n=elixer@65.207.74.18) |
| 15:58.57 | seanbright | M11541 |
| 15:58.57 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/CodecHandling 0011541: SIP Redirect causes Asked to transmit frame type 64, while native formats is 0x4 (ulaw) reported by norman http://bugs.digium.com/view.php?id=11541 |
| 15:59.10 | seanbright | i can confirm that happens with 1.4.18 rc2 |
| 15:59.13 | oej | File: can't find it, but I might have an easy fix. |
| 15:59.16 | seanbright | should i change the status in mantis? |
| 16:13.55 | *** join/#asterisk-bugs monkeytype (n=Bill@216.207.245.1) |
| 16:13.56 | oej | file: patch uploaded. |
| 16:19.53 | *** part/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 16:20.27 | file | seanbright: I do believe I see the reason. |
| 16:21.57 | file | it's being put on hold before it thinks it's answers... which probably forces the format on the channel into signed linear |
| 16:22.01 | file | and when it does get answered it's all confused |
| 16:22.21 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 16:22.21 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:22.42 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:22.43 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:35.02 | file | I can probably fudge the code... |
| 16:35.09 | file | make it do it... |
| 16:35.22 | seanbright | file: so its a client problem? |
| 16:35.32 | file | well, not exactly |
| 16:35.49 | file | it's a slightly odd scenario, but Asterisk is the issue |
| 16:36.09 | seanbright | well the word "fudge" is troubling :) |
| 16:36.33 | file | oh I don't mean to fix the issue, I mean to make it happen... |
| 16:36.39 | file | it's not something I can make my phones do :) |
| 16:36.42 | seanbright | ohhh |
| 16:36.44 | seanbright | gotcha |
| 16:38.11 | seanbright | chan_sip scares me, otherwise i'd have tried to come up with a patch |
| 16:38.32 | seanbright | well, chan_* scare me |
| 16:38.35 | russellb | heh |
| 16:38.46 | russellb | all of the channel drivers are very fragile |
| 16:38.48 | seanbright | followed by *.c |
| 16:38.50 | seanbright | heh |
| 16:38.51 | russellb | you have to careful with them |
| 16:39.07 | file | chan_russellb is an exception, never touch that... |
| 16:39.08 | russellb | changing whitespace has been known to break everything |
| 16:39.17 | seanbright | russellb: heh |
| 16:40.30 | seanbright | wasn't trying to imply anything, just find the channel drivers intimidating. |
| 16:43.01 | file | ohhhhhhh |
| 16:43.53 | oej | I guess I just broke rtp.c then, by changing 8x<space> to tabs |
| 16:44.21 | file | seanbright: I was slightly off, I see what it is doing... |
| 16:44.53 | seanbright | file: super. whats that? |
| 16:45.35 | file | stuff. |
| 16:45.41 | seanbright | file: i know it |
| 16:45.43 | seanbright | err |
| 16:45.47 | seanbright | s/know/knew/ |
| 16:46.06 | seanbright | file: i have a patch for that too. - stuff \n + stuff |
| 16:51.11 | file | this is sort of complicated |
| 16:51.48 | seanbright | heh |
| 16:51.53 | seanbright | well thankfully you're a smart guy |
| 16:52.05 | file | Phone 1 calls Phone 2, Phone 1 puts Phone 2 on hold before it has answered... the write format gets changed to signed linear and musiconhold is started... |
| 16:52.29 | file | then once Phone 2 actually answers the formats get reset (because the answer had codec information), which changes that write format and native formats |
| 16:52.38 | file | well... actually changes the write format and destroys the translator |
| 16:53.04 | file | frames then pass directly through the core from musiconhold and end up in chan_sip where they get discarded |
| 16:53.15 | seanbright | well i could have told you that... |
| 16:53.26 | seanbright | (heh) |
| 16:54.53 | file | although if the other side hasn't answered yet how can you play moh to them |
| 16:56.07 | file | seanbright: can you try a patch right now? |
| 16:56.31 | seanbright | i can |
| 16:57.02 | file | (this will at least solve your issue, dunno about reporter) |
| 16:57.08 | seanbright | alrighty. |
| 16:57.19 | seanbright | i can test his scenario as well with the patch |
| 16:57.41 | file | attached |
| 17:00.48 | seanbright | well, it doesn't spew all warnings anymore |
| 17:01.32 | seanbright | strangely, the first time i try it after bringing up asterisk and the soft phone, it works and i hear MOH |
| 17:01.43 | seanbright | every time after, i don't get the warnings, but i don't hear MOH |
| 17:02.05 | file | uh ... huh |
| 17:02.44 | seanbright | heh |
| 17:03.07 | seanbright | well its a weird scenario anyway |
| 17:03.11 | seanbright | same client and all |
| 17:03.16 | seanbright | so i'm effectively talking to myself |
| 17:03.21 | seanbright | ... story of my life. |
| 17:07.05 | seanbright | alright, just tried something else... separate clients on different machines. A calls B, before B answers, A puts B on hold. B answers, hear's dead air (i.e. no MOH) |
| 17:08.13 | file | making MOH work in that scenario is... |
| 17:08.14 | file | not easy. |
| 17:08.21 | seanbright | right |
| 17:08.42 | seanbright | i'm not really concerned about the MOH, that's an edge case anyway |
| 17:09.11 | seanbright | now i want to test the OP's problem, let me figure this out |
| 17:11.32 | seanbright | ah. taking out your patch, the warnings show up when placing calls machine to machine. again assuming the call is put on hold before its answered. |
| 17:13.47 | seanbright | how would i dupe the OP's report? is there an easy way to force a 302? |
| 17:14.16 | putnopvut | seanbright: call-forwarding typically results in a 302. |
| 17:14.43 | file | the Transfer application will cause Asterisk to perform a 302, and call forwarding will cause a device to perform a 302 |
| 17:14.49 | putnopvut | (disclaimer: I have no idea what bug you're talking about or anything) |
| 17:14.58 | seanbright | ok |
| 17:15.23 | file | putnopvut knows things! |
| 17:15.34 | putnopvut | Only sometimes! |
| 17:22.16 | seanbright | so his situation is A calls B, A transfers B to C, but C redirects back to A |
| 17:23.03 | seanbright | 9999 => { Transfer(SIP/1000); } |
| 17:23.23 | seanbright | 1000 calls 2000, then blind transfers 2000 to 9999 |
| 17:23.33 | seanbright | that should do it, yeah? |
| 17:26.09 | seanbright | never seeing the 302 in sip debug. this sucks. |
| 17:26.44 | putnopvut | seanbright: how are you executing the transfer? |
| 17:27.00 | seanbright | the original blind xfer? #9999 |
| 17:27.04 | putnopvut | Oh, I see... |
| 17:27.17 | putnopvut | Hmm...file? |
| 17:27.57 | file | yes? |
| 17:30.51 | d1mas | russellb: hello. Update regarding your yesterday question. Now I would consider 11796 as "tested" :) |
| 17:31.02 | *** join/#asterisk-bugs agx (n=badpengu@81-174-9-79.dynamic.ngi.it) |
| 17:31.11 | file | he is off to a meeting |
| 17:31.36 | Qwell | hmm, there were questions about 11796? |
| 17:32.38 | file | M11796 |
| 17:32.39 | MuffinMan | [new] [Asterisk] PBX/General 0011796: [patch] refactoring of fax tone detection in DSP reported by dimas http://bugs.digium.com/view.php?id=11796 |
| 17:33.20 | Qwell | my scrollback doesn't go back that far... silly xchat |
| 17:33.57 | d1mas | file: thanks again :) |
| 17:33.58 | seanbright | file: ok, i duplicated the OP's situation (including the 302) and don't see the warnings, and this is _without_ your patch :-/ |
| 17:34.23 | d1mas | qwell: Russell asked if he can assume I tested 11796 |
| 17:34.36 | d1mas | qwell: t was yesterday :) |
| 17:34.45 | Qwell | oh |
| 19:19.35 | russellb | nah |
| 19:19.37 | russellb | oops |
| 19:28.04 | *** part/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 19:49.54 | d1mas | file: so, how much time you think you will need to take a look at 11873 and have some decision? |
| 19:50.27 | Qwell | M11873 |
| 19:50.28 | MuffinMan | [new] [Asterisk] Channels/chan_sip/T.38 0011873: [patch] minimal API to control SIP T38 from application reported by dimas http://bugs.digium.com/view.php?id=11873 |
| 19:50.47 | file | a bit. |
| 19:52.05 | d1mas | file: will catch you tomorrow then :) Have a nice day |
| 19:52.20 | file | complicated it is, oh yes |
| 19:53.00 | d1mas | file: er... what complicated? patch? |
| 19:53.37 | file | not exactly. |
| 19:53.54 | d1mas | approach ? |
| 19:54.17 | file | I will look at the T38 stuff soon. |
| 19:54.29 | d1mas | ok. have to go now |
| 20:20.39 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:38.45 | *** join/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 21:13.47 | russellb | file: ping |
| 21:14.24 | russellb | re: chanspy stuff |
| 21:16.14 | file | pong |
| 21:17.10 | russellb | so i talked to kevin about it |
| 21:17.34 | russellb | he said that the problem had been addressed before, and maybe got lost in a re-write at some point |
| 21:17.47 | file | not that issue |
| 21:18.05 | russellb | the trick was to use a channel datastore ... |
| 21:18.14 | russellb | on the peer channel, and only store a pointer to that |
| 21:18.24 | russellb | and have the datastore keep a pointer to the channel itself |
| 21:18.26 | file | that we had not discussed. |
| 21:18.53 | russellb | and if the channel goes away, have the channel datastore destructor NULL out the pointer in the datastore but _not_ free it |
| 21:19.22 | russellb | so by using that, and a lock in the datastore to sync access to the channel pointer, you can know whether it has gone away or not |
| 21:21.53 | *** part/#asterisk-bugs flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 21:26.55 | putnopvut | Jeez...channel refcounting will be a godsend. |
| 21:27.11 | file | I think... I see. |
| 21:27.12 | Corydon76-dig | Who's doing that? |
| 21:27.23 | file | Corydon76-dig: it's already done. |
| 21:27.28 | file | (hopefully) |
| 21:27.32 | Corydon76-dig | but not merged? |
| 21:27.33 | russellb | Corydon76-dig: team/russell/chan_refcount |
| 21:27.38 | Corydon76-dig | Ah |
| 21:27.40 | file | it's also on the reviewboard |
| 21:27.44 | russellb | right ... pending testing, review, and such .. |
| 21:30.29 | russellb | so file ... |
| 21:30.32 | russellb | did that ... make any sense? |
| 21:30.47 | file | yes, I think I see how |
| 21:31.21 | russellb | ok ... |
| 21:31.31 | file | make the headache go away! |
| 21:31.31 | russellb | do you want to try to implement it, or would you like me to? |
| 21:31.41 | russellb | either way, i'd like you to review it, or i'd like to review it if you write it |
| 21:31.45 | russellb | because it's going to be tricky |
| 21:32.03 | file | you can go for it, you haven't done anything tricky in awhile >:D |
| 21:32.30 | russellb | oic |
| 21:42.35 | putnopvut | I was looking at that chanspy stuff. I felt dirty thinking about the locking necessary to keep the peer channel alive... |
| 21:43.02 | file | yeah. |
| 21:46.52 | russellb | earlier we decided you could have a deadlock or a segfault |
| 21:46.57 | russellb | we could make it a configurable option i guess. |
| 21:56.02 | putnopvut | M11880 |
| 21:56.03 | MuffinMan | [new] [Asterisk] Core-General 0011880: SIP username -> defaultuser confuses realtime system(s) reported by cabal95 http://bugs.digium.com/view.php?id=11880 |
| 21:56.18 | putnopvut | Why was "username" changed to "defaultuser" in 1.6? |
| 22:27.36 | Corydon76-dig | An excellent question, since if there was to be a transition, it should have been deprecated first |
| 22:28.16 | putnopvut | Well, it was deprecated to some degree. |
| 22:28.42 | putnopvut | It's deprecated in the sense that UPGRADE.txt warns of its deprecation, and it's still allowable via static sip.conf |
| 22:29.21 | putnopvut | But there are calls to realtime functions which try to get the "defaultuser" and do not provide the concession of allowing "username" instead. |
| 22:29.43 | putnopvut | Or even worse, try to set the "defaultuser" |
| 22:31.18 | Corydon76-dig | Two guesses who made the change |
| 22:31.46 | putnopvut | I'm pretty sure I know who it was. |
| 22:31.58 | *** join/#asterisk-bugs agx (n=badpengu@81-174-9-79.dynamic.ngi.it) |
| 22:31.59 | putnopvut | But I'm not worried about that, really. I just want to get it fixed. |
| 22:32.01 | Corydon76-dig | I'm pretty sure you know, too |
| 22:33.31 | Corydon76-dig | A91152 |
| 22:33.33 | MuffinMan | [91152] Committed by oej on 2007-12-05 09:09:47: Rename "username" to "defaultuser" to match with "defaultip". |
| 22:39.06 | putnopvut | Wow, and it was very recent too. |
| 22:39.21 | putnopvut | It's fine to deprecate it, but it wasn't done with realtime in mind, unfortunately. |
| 22:41.23 | putnopvut | Oh, awesome. The configuration option is called defaultuser, but the struct's string is still called username... |
| 22:42.34 | *** part/#asterisk-bugs agx (n=badpengu@81-174-9-79.dynamic.ngi.it) |
| 22:47.06 | russellb | putnopvut: was UPGRADE.txt updated for that? |
| 22:47.36 | putnopvut | Yes. |
| 22:47.49 | putnopvut | It's just the deprecation wasn't seen through to completion. |
| 22:48.24 | putnopvut | i.e. configuration was parsed correctly, but realtime updates did not take into consideration the fact that the old "username" setting might have been used. |
| 22:48.47 | putnopvut | I've uploaded a patch there to fix it. Just waiting on testing. |
| 23:39.29 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.20.97.211) |