| 00:13.35 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-1b2834353ab9eed7) |
| 01:56.29 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 01:56.29 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:16.02 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 02:31.30 | *** join/#asterisk-dev mosty (n=mosty@eth1426.vic.adsl.internode.on.net) |
| 02:35.55 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 03:39.27 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 03:42.12 | JunK-Y | russellb: off-topic question |
| 03:42.12 | JunK-Y | ==4262== Invalid read of size 4 |
| 03:42.12 | JunK-Y | ==4262== at 0x8994E6: __pthread_mutex_unlock_usercnt (in /lib/libpthread-2.5.so) |
| 03:42.15 | JunK-Y | ==4262== by 0x89987F: pthread_mutex_unlock (in /lib/libpthread-2.5.so) |
| 03:42.20 | JunK-Y | what that means, this mutex is invalid? |
| 03:42.59 | russellb | potentially, yes |
| 03:54.35 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 03:54.35 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 03:54.37 | JunK-Y | and do you have an advice on how to remove those valgrind warnings? |
| 03:56.17 | russellb | fix the code? :) |
| 03:56.54 | JunK-Y | hahah, but how? |
| 04:00.35 | file | that question can't be answered... you have to narrow down where the issue is, look at the code, and figure out the problem |
| 04:01.16 | russellb | the output you have provided so far makes it impossible for me to say anything more than "fix it" |
| 04:07.45 | Juggie | did not realize the mailing list was a popularity contest :) |
| 04:40.30 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 04:40.30 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:08.51 | *** join/#asterisk-dev murdock_ut (n=chatzill@c-98-202-154-226.hsd1.ut.comcast.net) |
| 06:06.05 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 07:07.33 | jmls | mrning all |
| 07:07.37 | jmls | gah |
| 07:07.46 | jmls | morning all |
| 07:07.52 | jmls | neeed coffee ;) |
| 08:14.06 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) [NETSPLIT VICTIM] |
| 08:14.06 | *** join/#asterisk-dev CtRiX (n=CtRiX@aretha.navynet.it) [NETSPLIT VICTIM] |
| 08:14.06 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) [NETSPLIT VICTIM] |
| 08:33.51 | *** join/#asterisk-dev mvanbaak (i=mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:33.51 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 08:38.55 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 09:28.22 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 09:36.31 | *** join/#asterisk-dev qdk (n=qdk@79.138.230.26.bredband.3.dk) |
| 09:48.52 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 10:38.50 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 10:49.48 | freddyk | morning all |
| 10:54.31 | shazaum | morn |
| 11:12.53 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:48.27 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 12:11.04 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.201.161) |
| 12:46.52 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:46.52 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:51.08 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:51.08 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:52.26 | lmadsen | morning! |
| 12:55.24 | jmls | morning ! |
| 12:58.29 | lmadsen | how goes jmls? |
| 12:58.38 | jmls | just peachy, thanks |
| 12:58.54 | lmadsen | nice to hear! |
| 12:59.25 | jmls | I have a nice home, a lovely wife, great kids and a secure job. I couldn't ask for any more |
| 13:00.03 | jmls | well, perhaps, except, um, for codefreeze-lap to fix my missing "h" (H) |
| 13:00.18 | lmadsen | lol |
| 13:00.23 | lmadsen | <G> |
| 13:00.56 | Rico29 | hi |
| 13:00.58 | jmls | do you think that he will now take pity on me ? |
| 13:01.06 | jmls | wow! Rico's back |
| 13:01.14 | jmls | you survived the lightning bolt, then ? |
| 13:01.19 | Rico29 | iep |
| 13:01.20 | Rico29 | :) |
| 13:03.58 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:04.43 | Rico29 | i'm trying to fix my issue about DTMF on an IAX2 trunk, and saw this : http://bugs.digium.com/view.php?id=2283 |
| 13:05.00 | Rico29 | can anyone of you tell me more about that ? is if "fixed" ? |
| 13:05.50 | Rico29 | *if |
| 13:06.25 | lmadsen | the fact you had to bring up a bug that old seems to me there is probably most likely a configuration problem, and not a bug in asterisk... |
| 13:06.35 | *** join/#asterisk-dev imchandave (n=chandave@ip155.bb203.pacific.net.hk) |
| 13:06.37 | Rico29 | ok |
| 13:06.39 | lmadsen | plus that bug references a configuration issue on the far end |
| 13:06.53 | Rico29 | I didn't saw the date |
| 13:07.59 | *** join/#asterisk-dev sasargen (n=chatzill@174-152-106-175.pools.spcsdns.net) |
| 13:16.33 | *** join/#asterisk-dev stevie[xxx] (n=stevie@85.183.21.87) |
| 13:17.10 | stevie[xxx] | http://bugs.digium.com/view.php?id=13958 , is this patch added to 1.6.0.3 ? because i dont find this in the source |
| 13:24.24 | stevie[xxx] | i got a "warning: suggest parentheses around assignment used as truth value" channels/chan_iax2.c line 7088 , if (p = find_peer(peer_name, 1)) is this correct? or shoudl it be p == find... |
| 13:36.55 | lmadsen | stevie[xxx]: I don't think so, although I'm not positive. Check the 1.6.0 branch really, as 1.6.0.3 is just 1.6.0.3-rc1 with the security patch. |
| 13:37.04 | lmadsen | so most likely in 1.6.0.4 |
| 13:37.17 | lmadsen | oh wait no, it won't be |
| 13:37.24 | lmadsen | this is new functionality -- it will be in 1.6.2 |
| 13:37.52 | lmadsen | you would have to run trunk at this point to get that functionality. New functionality is not added to branches. |
| 13:42.41 | *** join/#asterisk-dev gambler1 (n=mene_sun@dragan.eunet.yu) |
| 13:55.32 | *** join/#asterisk-dev elfguy516 (n=elfguy51@ool-18bf6026.dyn.optonline.net) |
| 13:55.54 | ccesario | hello... in any sporadic moments in axfer (sip peer to queues or queues to queues or queues to sip peer) my asterisk die.. |
| 13:56.20 | ccesario | the gdb bt say me this .. http://pastebin.com/m3f333314 |
| 14:01.32 | lmadsen | ccesario: first, you need to enable DONT_OPTIMIZE in the Compiler Flags section of menuselect. Second, is this a vanilla system? (i.e. no external patches?) |
| 14:01.45 | lmadsen | Also what version of Asterisk? |
| 14:02.18 | ccesario | lmadsen, Asterisk SVN-moy-mfcr2-r159896M |
| 14:02.36 | lmadsen | that is an old branch... where did you get it from? |
| 14:02.56 | lmadsen | I assume from some bug somewhere |
| 14:04.36 | ccesario | lmadsen, from here http://svn.digium.com/svn/asterisk/team/moy/mfcr2/ |
| 14:05.13 | ccesario | moises OpenR2 support :) |
| 14:07.30 | lmadsen | what bug number? |
| 14:07.52 | lmadsen | 12509 I presume |
| 14:09.09 | lmadsen | ccesario: is your branch up to date? It could be that the branch is not up to date with trunk too. |
| 14:09.32 | lmadsen | ccesario: if you are having issues with that branch, please report them against bug 12509. Thanks! |
| 14:16.39 | stevie[xxx] | thx lmadsen |
| 14:17.17 | ccesario | lmadsen, tks.. i'll check |
| 14:17.48 | stevie[xxx] | does configure with --enable-dev-mode do the job? |
| 14:20.30 | lmadsen | eh? |
| 14:20.55 | lmadsen | --enable-dev-mode makes warnings act like errors so the dev's can fix warnings if necessary |
| 14:25.12 | lmadsen | eliel: morning! |
| 14:28.23 | stevie[xxx] | but i did this and now the patch seems to be added to the chan_sip.c |
| 14:28.35 | stevie[xxx] | reference http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg35056.html |
| 14:29.50 | lmadsen | just running --enable-dev-mode is not going to make the patch immediately appear... |
| 14:30.34 | stevie[xxx] | yeah im wondering |
| 14:30.54 | stevie[xxx] | but the code is correct |
| 14:31.07 | stevie[xxx] | latest build |
| 14:31.08 | lmadsen | it was committed to trunk, not any of the branches |
| 14:31.21 | lmadsen | it will be in trunk if that's what you're running |
| 14:31.48 | lmadsen | just not the 1.6.0 or 1.6.1 branches |
| 14:32.30 | stevie[xxx] | so there is a diffrence between trunk and the download on the official page? |
| 14:32.40 | stevie[xxx] | except latest changes |
| 14:32.52 | lmadsen | of course |
| 14:32.57 | lmadsen | trunk is the *latest* stuff |
| 14:33.23 | lmadsen | i.e. all new commits go into trunk. If they are a bug fix, they go into 1.6.0, and 1.6.1 branches. Those branches, at periods of time, have 'tags' made from them. Tags are 'releases'. |
| 14:33.32 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-4c5386e56d55316b) |
| 14:33.32 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:33.33 | lmadsen | trunk != 1.6.1 != 1.6.0 |
| 14:33.38 | lmadsen | putnopvut: omghi! |
| 14:33.50 | putnopvut | hello lmadsen |
| 14:33.50 | stevie[xxx] | ok |
| 14:34.04 | putnopvut | Quite a bit of activity on the bugtracker for me to investigate, it seems. |
| 14:34.09 | lmadsen | putnopvut: :) |
| 14:34.11 | lmadsen | true dat |
| 14:34.24 | lmadsen | I was woken by a fire alarm at 7am... and have been working ever since |
| 14:34.33 | stevie[xxx] | http://downloads.digium.com/pub/asterisk/asterisk-1.6-current.tar.gz just to be sure, this is no trunk? |
| 14:34.56 | lmadsen | it is not |
| 14:35.03 | lmadsen | it is 1.6.0.3 |
| 14:35.26 | lmadsen | asterisk-1.6-current.tar.gz is whatever is linked on the main page of asterisk.org, which currently states 1.6.0.3 |
| 14:35.45 | stevie[xxx] | i have to use svn? |
| 14:35.59 | lmadsen | if you want that patch yes -- trunk is not for production |
| 14:36.20 | lmadsen | that patch will be available at a later time when 1.6.2 is branched, and a tag made from that branch |
| 14:36.23 | *** join/#asterisk-dev elfguy516 (n=elfguy51@96.56.103.35) |
| 14:36.37 | lmadsen | should write an article... or at least find one to link to describing all this |
| 14:37.05 | stevie[xxx] | hm but i need this function now |
| 14:37.22 | stevie[xxx] | didnt found a patch for the latest branch |
| 14:37.55 | lmadsen | you can try to backport it, or you can take your chances to run trunk; note the warning when you run trunk that says, "Do not run in production" though. |
| 14:39.12 | stevie[xxx] | perhaps i try to change code by myself |
| 14:39.18 | mvanbaak | I'm running trunk in production without trouble |
| 14:39.32 | stevie[xxx] | to add the patch |
| 14:39.33 | *** join/#asterisk-dev awk_r (n=awk_r@nat/digium/x-d8ed521de8e4f223) |
| 14:39.44 | lmadsen | mvanbaak: you're also slightly more advanced than the average user :) |
| 14:39.55 | lmadsen | but hey... run trunk and report bugs! :) |
| 14:40.21 | mvanbaak | uhhuh |
| 14:40.31 | stevie[xxx] | hehe |
| 14:40.43 | lmadsen | mvanbaak: any time in the near future for looking into a docbook import/export module? :) |
| 14:40.52 | stevie[xxx] | i can do it for me, but not for our customers :) |
| 14:41.43 | mvanbaak | lmadsen: you online this weekend ? |
| 14:42.00 | lmadsen | mvanbaak: ummm... probably a little bit |
| 14:42.05 | lmadsen | I will take my laptop to the g/fs |
| 14:42.13 | lmadsen | sunday most likely I will be around |
| 14:42.22 | mvanbaak | k |
| 14:42.24 | lmadsen | and part of saturday |
| 14:42.31 | mvanbaak | I hope to be online as well |
| 14:42.35 | lmadsen | awesome |
| 14:47.39 | Rico29 | for my DTMF problem, it was coming from my provider |
| 14:47.42 | Rico29 | thanks |
| 14:47.44 | lmadsen | ;) |
| 14:52.30 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 14:52.30 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:58.00 | *** join/#asterisk-dev moy (n=moy@74.12.127.97) |
| 15:00.01 | lmadsen | moy: !!! |
| 15:00.05 | *** part/#asterisk-dev elfguy516 (n=elfguy51@96.56.103.35) |
| 15:01.04 | moy | hey lmadsen, how you doing? |
| 15:02.41 | lmadsen | moy: oh not bad... just workin' away on some bug tracker triage |
| 15:03.45 | jmls | codefreeze-lap: ping |
| 15:03.45 | moy | and probably you just saw my old bug there w/o update :) |
| 15:04.21 | moy | I'm working on that now, should be updated today, just need to test the changes |
| 15:04.34 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:06.18 | lmadsen | moy: sweet! :) |
| 15:06.44 | lmadsen | yes, I added a note to it because someone mentioned a crash when using axfer today, but it looked like it was about 20k rev's behind :) |
| 15:07.01 | moy | yeah :( ... sorry bout that |
| 15:07.28 | lmadsen | np! |
| 15:09.07 | lmadsen | otherwiseguy: could you join -bugs? pretty pls?! |
| 15:30.59 | jmls | I have a zap channel connected to a sip channel, and then I redirect the zap channel to another context/extension/priority |
| 15:31.23 | codefreeze-lap | jmls: here be I |
| 15:31.55 | jmls | codefreeze-lap: yay! |
| 15:31.56 | jmls | <PROTECTED> |
| 15:32.17 | jmls | if I have the above scenario (zap->sip, redirect zap) |
| 15:32.35 | jmls | why is the "before_you_go" running on the zap channel ? |
| 15:34.22 | codefreeze-lap | jmls: get me in the right frame of mind here. Why wouldn't it be? |
| 15:34.56 | jmls | because the zap channel has not been hung up ... the sip channel has |
| 15:35.22 | jmls | zap is redirected to another extension, while the sip is destroyed |
| 15:35.54 | jmls | zap is still alive (it has been redirected to a meetme room) |
| 15:36.46 | codefreeze-lap | jmls: and your point is? (lol) |
| 15:37.28 | jmls | does not know if codefreeze-lap is joking or not |
| 15:38.35 | codefreeze-lap | doesn't know if he's joking or not, either, but he *is* smiling. yes, at the end of a bridge, things can be very different than when the bridge began |
| 15:39.12 | jmls | but this is the problem - the AST_FLAG_BRIDGE_HANGUP_RUN flag has been set on my zap channel, *before* it goes into the meetme, and before it is hung up |
| 15:39.44 | jmls | so when the channel is actually hanged up, the h extension is not run, because the AST_FLAG_BRIDGE_HANGUP_RUN has been set |
| 15:40.02 | jmls | on the zap channel |
| 15:40.30 | codefreeze-lap | Interesting. Is this with one redirect, or the double redirect you were mentioning earlier? |
| 15:40.38 | jmls | single redirect |
| 15:41.05 | jmls | zap calls sip, sip answers. AMI redirect zap to meetme. |
| 15:41.22 | codefreeze-lap | Give me the |
| 15:41.26 | codefreeze-lap | ... |
| 15:41.31 | codefreeze-lap | you just did |
| 15:41.35 | jmls | heh |
| 15:41.54 | codefreeze-lap | What was the AMI command, exactly? |
| 15:42.06 | jmls | Redirect |
| 15:42.08 | jmls | ;) |
| 15:42.20 | codefreeze-lap | lol |
| 15:42.40 | jmls | channel: ZAP1/1 exten: park context: parking priority: 1 |
| 15:43.10 | jmls | in res_features, the code is being run on the zap channel, not the sip channel |
| 15:43.17 | jmls | which doesn't make sense to me |
| 15:43.35 | jmls | but then, nothing much does |
| 15:44.36 | codefreeze-lap | Well, with masquerades, you naturally get reversal of "role", as I call it, channel vs peer. So, I'm not surprised at all about it.... hmmm. |
| 15:44.55 | jmls | then the flag is being set on the wrong channel |
| 15:46.11 | jmls | the code is running the h extension on the zap channel, before it is being redirected to the new extension. |
| 15:46.50 | jmls | therefore, the "h" extension is |
| 15:47.12 | jmls | a) being run in the context of the zap channel *before* it is moved to another context / extension |
| 15:47.30 | jmls | b) being run on a channel that is not hung up |
| 15:48.03 | jmls | c) the flag is then set to prevent the "real" h extension from being run when the zap channel actually hangs up |
| 15:48.28 | codefreeze-lap | yeah, it does. I noted that when I updated the parking code to use masquerades. |
| 15:49.27 | jmls | surely the h extension should be run on the channel that is being hung up (sip in this case) ? |
| 15:49.47 | jmls | uses the word "surely" with a very false sense of certainty ... |
| 15:49.53 | codefreeze-lap | But the solution is more architectural than anything. We've pretty much decided not to solve this problem in 1.4. And, to top it off, we are still scratching our heads about what the solution would be. |
| 15:50.12 | codefreeze-lap | It goes something like this: |
| 15:50.27 | codefreeze-lap | tries to put on thinking cap. |
| 15:50.46 | jmls | yeah, but with all due respect, the h extension must be run on the channel that is being hanged up at the time the channel is being hanged up ;) |
| 15:50.57 | jmls | not on the other channel |
| 15:51.16 | jmls | ducks and runs |
| 15:53.01 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-eedc0101edb4ec75) |
| 15:53.01 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:53.09 | codefreeze-lap | yes, jmls, yes. I agree. Get ready for a wild ride. Imagine this: A calls B; B parks A. At this point, there are several things that can happen. 1. A hangs up. 2. A hangs on, parking expires. B is called, A & B are rejoined. 3. C picks up A from parking. |
| 15:53.33 | jmls | readies himself |
| 15:54.08 | jmls | in (2) isn't A always a valid channel ? |
| 15:54.31 | jmls | and (3) |
| 15:54.34 | codefreeze-lap | jmls: hang on. I'm not done. I'll get to that |
| 15:54.38 | jmls | heh |
| 15:55.54 | codefreeze-lap | jmls: what REALLY happened, is that poor A is being passed from one thread to another. The parking manager thread does its own thing on its own time frame. Rather than just hand poor A over to the dogs, so to speak, and lose him entirely from |
| 15:55.57 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-f33beab5eb424557) |
| 15:55.57 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:56.22 | codefreeze-lap | the bridge, we actually split him into two parts, one mostly alive, and one mostly dead. |
| 15:57.34 | jmls | this is the "zombie" thing ? |
| 15:57.59 | codefreeze-lap | We give the mostly alive half (a new channel created via masquerade, with most of the info swapped into it from the previous channel) to the parking manager. The mostly dead half is kept, but its name is changed by adding the <ZOMBIE>, yes. |
| 15:58.22 | jmls | ok |
| 15:58.34 | jmls | is amazed that he has hung on this far |
| 15:59.38 | codefreeze-lap | The interesting part of the swapping that occurs is with stuff like the CDR, and the PBX pointer. (we need that pbx ptr to run the h-exten) (sort of). |
| 16:00.54 | codefreeze-lap | The CDR is swapped. The new, empty CDR from the new channel is given to the <zombie>. The original channel's CDR ends up on the new, masqueraded copy, and is in the parking lot now. |
| 16:01.13 | lmadsen | M12442 |
| 16:01.15 | MuffinMan | [feedback] [Asterisk] Applications/app_test 0012442: pri loop TestClient/TestServer fails: server SEND DTMF 8 reported by tzafrir (Karma: +119.75) http://bugs.digium.com/view.php?id=12442 |
| 16:01.28 | codefreeze-lap | The PBX pointer, on the other hand, ends up staying with the <ZOMBIE> |
| 16:01.31 | lmadsen | tzafrir_laptop: when you have a chance, can you look at my note? I can't even seem to get as far as you in terms of reproducing the problem :) |
| 16:02.06 | codefreeze-lap | is searching the page of notes he made on masquerading, as to how the flags get handled... darn |
| 16:05.24 | jmls | why do you/we need to create the zombie channel ? Why can't the original channel just be passed to the parking manager ? |
| 16:05.34 | jmls | asks the really dumb questions in this forum |
| 16:05.50 | codefreeze-lap | It looks like two flags are copied to the new channel (but not this one) and the AST_FLAG_ZOMBIE is set on the old chan; and ... more to come, just got your question |
| 16:06.43 | codefreeze-lap | jmls: I am glad you asked that... basically, because the bridge (and other code in other places) is still referencing the old channel. You can't just give it away and still ref it. |
| 16:07.17 | jmls | when you say "old" channel, which one are you meaning ? the sip channel ? |
| 16:07.28 | jmls | or the zombie zap channel ? |
| 16:07.33 | codefreeze-lap | the <ZOMBIE>, as it is now known |
| 16:08.28 | jmls | why, then, is the h extension being run on the "new" channel, not the zombie channel ? |
| 16:08.56 | jmls | in fact, why is it being run at all ? To generate a cdr ? |
| 16:09.05 | stevie[xxx] | i made a patch(IGNORESDPVERSION function) for the latest branch, should i uploud it? |
| 16:09.26 | codefreeze-lap | jmls: keep holding on |
| 16:10.46 | codefreeze-lap | jmls: at the moment A goes into the parking lot, B is hung up... |
| 16:11.35 | lmadsen | stevie[xxx]: no, that patch is already in trunk, and it will not get put into branches because it is a new feature |
| 16:11.58 | lmadsen | you will need to maintain it locally until 1.6.2 |
| 16:12.01 | stevie[xxx] | ok, just wanne help others |
| 16:12.11 | lmadsen | np, but the bug tracker doesn't make sense for that |
| 16:12.25 | lmadsen | you can post a note to asterisk-users if you wish and host the file on your server |
| 16:12.42 | codefreeze-lap | is thinking, remembering... |
| 16:13.39 | codefreeze-lap | jmls: the bridge ends... the bridge CDR is posted. |
| 16:14.40 | jmls | yup .. |
| 16:14.51 | codefreeze-lap | And the h-exten is run there in the bridge code |
| 16:16.07 | jmls | why? The channel is *not* hung up |
| 16:16.53 | codefreeze-lap | probably mistakenly; but in the case of parking, it might be wrong, but in all the cases I saw, it may be the only CDR you'll get for A once it goes to the parking lot, it will never get its h-exten run after that. |
| 16:17.26 | jmls | I'm not parking - just redirecting. It may be the same thing. |
| 16:18.54 | codefreeze-lap | So, it's either then, or you never get any CDR at all. Life with parking. Can you see why? ... (response to comment: Well, I see parking in your AMI command. |
| 16:18.59 | jmls | but A has not hung up - why run the h extension possibly minutes / hours before the call is actually ended ? They may be in my meetme room for 40 minutes |
| 16:20.25 | codefreeze-lap | True. I know. But... once in the parking lot, A is now a peer channel, not a "channel" role any more, with CDR's and pbx pointers. It's a lowly peer. no CDR. no pbx h-exten to run. |
| 16:20.59 | codefreeze-lap | Well, in this case, it does have a CDR, but it'll mostly just get ignored. |
| 16:22.11 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-4e15fe8d01b2f36e) |
| 16:22.11 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:22.28 | codefreeze-lap | Now, the CDR, I might be able to do something about, I'm not entirely sure what yet, but *something* could be done... but the h-exten is trickier. |
| 16:23.06 | codefreeze-lap | jmls: you still hanging on? |
| 16:23.45 | jmls | just about |
| 16:24.44 | jmls | I still can't grasp the concept of the h extension being called on a channel when the call itself has not ended. |
| 16:25.07 | jmls | and, in all fairness, it didn't before this patch |
| 16:26.54 | jmls | I use the h extension to send messages to the backend system to say "this call has ended" |
| 16:27.03 | codefreeze-lap | yes, yes. keep hanging on. OK, let's follow this a little further. We have A still in the parking lot; stripped of its pbx pointer. The 3 options I mentioned... A can hang up. A can wait, and expire, and get rejoined to B. A can get picked up. |
| 16:27.21 | jmls | ok |
| 16:28.22 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:28.29 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 16:28.43 | codefreeze-lap | Normally, if A hangs up, no h-exten. The parking lot manager didn't run an h-exten. Still doesn't. |
| 16:28.46 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 16:29.07 | jmls | really ? wow |
| 16:29.12 | jmls | I would consider that a bug. |
| 16:29.36 | jmls | Surely h must be run whenever a call hangs up. Regardless of where it is in the dialplan |
| 16:29.59 | file | if you park a call it is not in the dialplan any longer |
| 16:31.30 | codefreeze-lap | Well, the change to use masquerading is recent; previously, the channel would end up hanging up, and all referencing to it had to be suppressed in the bridge and anywhere else, because Once it hung up, the channel is destroyed, and all the pointers to it now are invalid. Masquerading lets us retain the <ZOMBIE>, so we can still get a name, etc. |
| 16:31.30 | jmls | ok - I will accept that this is the way "parking" works. |
| 16:31.45 | jmls | understood |
| 16:32.00 | jmls | reminds himself never to use parking |
| 16:32.59 | jmls | so, what would happen in my case if I redirected to another sip extension - are you now saying that once the redirection has happened, the h extension would never get run on the zap channel |
| 16:33.29 | jmls | sorry, I meant to say "I think that once the redirection ..." |
| 16:33.55 | codefreeze-lap | jmls: now, if C picks up the parked channel, that A is in the 'peer' position of the dial and bridge. No h-exten. no cdr expected. |
| 16:34.44 | jmls | yeah. I I understand parking doesn't work the way I thought. I am surprised, but that it the way that it is. |
| 16:34.53 | jmls | however, what I am seeing is nothing to do with parking - I am simply redirecting a call to another extension |
| 16:35.58 | file | codefreeze-lap: all these repercussions are making me quite sad |
| 16:36.17 | lmadsen | plays some percussion |
| 16:36.31 | codefreeze-lap | jmls: I've played with different ideas... for instance, I could play with the CDR in the process of unparking, I could slide some fields into C's CDR and save some of that data... but it would be kinda weird, because the times on C's CDR and A's would collide... |
| 16:38.08 | jmls | codefreeze-lap: as I've mentioned, I am not using parking at all. Just redirecting calls - so at the moment, I would say that running the h extension on the channel is a bug |
| 16:38.28 | jmls | I can understand that parking is some other animal |
| 16:38.49 | jmls | but redirecting a call to another extension keeps it in the dialplan |
| 16:39.07 | file | sort of |
| 16:39.41 | jmls | I really can't be explaining myself properly. |
| 16:39.44 | codefreeze-lap | jmls: and the h-exten is another issue. get ready for this: the <ZOMBIE> has the pbx pointer. The new A in the parking lot does not. If I passed the pbx pointer to the new channel, then the parking lot manager thread could run the h-exten if A hung up, but then the zombie could not... and if C picks it up, we'd have to toss one of the PBX's... it just gets lost in the fog. |
| 16:40.08 | file | jmls: you are explaining yourself fine, just the underlying way this stuff happens isn't what you might think |
| 16:41.58 | file | these changes in behaviour have my... concerned |
| 16:42.07 | codefreeze-lap | jmls: yes, running the h-exten on the <ZOMBIE> is not the right thing to do. And, in general, I could stop it from doing so. But, it's either that, or no h-exten at all for anything related to A. |
| 16:42.09 | file | erm have me |
| 16:46.22 | codefreeze-lap | file: yes, me too. When I started down this path, I didn't guess what I'd run into. The alternative is to completely back out to 1.2, and start over again with a new approach. And, to be truthful, it might work better (the new approach), but it will still be subject to stuff like this. |
| 16:48.28 | jmls | codefreeze-lap: the h extension worked just fine on all calls (redirected or not) until this patch went in |
| 16:48.46 | jmls | so, in trying to fix the cdr problem, this new problem was introduced |
| 16:50.59 | jmls | I know I'm still being dumb, but when a call is "parked" it is in some point in the dialplan, yes ? |
| 16:51.13 | codefreeze-lap | Well, this is probably third-order type stuff then. The question is why... that might lead to a work around. Why did it work in the previous case? Was it because masquerading wasn't previously done? |
| 16:51.24 | file | jmls: no |
| 16:51.56 | jmls | codefreeze-lap: it's worked that way since at least 1.2 ... I rely on h being run when the channel is hung up, and always have done since June 2004 ... |
| 16:52.18 | jmls | codefreeze-lap: remember, I am *not* parking a call |
| 16:52.34 | jmls | file: oh ? |
| 16:53.16 | file | jmls: when you park a call the PBX thread executing the dialplan on it goes away |
| 16:55.14 | jmls | but can't you store the context that the call was in before it was parked in the "new" channel, and then goto the h extension in that context if the call is hung up whilst it is parked ? |
| 16:55.45 | file | it is possible since it is code |
| 16:58.05 | jmls | ast_spawn_extension(chan, chan->contextfromwhenceICame, "h", 1, chan->cid.cid_num) |
| 16:58.14 | jmls | now really runs fast and hides |
| 16:58.27 | file | nope. |
| 16:58.48 | jmls | oh, because it is not a channel ? |
| 16:59.11 | file | you can't do that because the parking thread handles all channels that are parked |
| 16:59.13 | jmls | shouts this from his hiding place. |
| 16:59.23 | jmls | yuck |
| 16:59.58 | jmls | so what is really needed is for parking to be rewritten in order for codefreeze-lap to be able to fix his cdrs ... |
| 17:00.07 | jmls | points at file |
| 17:00.13 | jmls | ~cheer file |
| 17:00.14 | jbot | Three cheers for file! Hip hip Hurray! Hip hip Hurray! Hip hip Hurray! |
| 17:00.22 | file | nope! |
| 17:00.31 | lmadsen | file doesn't do 'real' work anymore |
| 17:00.35 | lmadsen | ducks |
| 17:01.27 | jmls | but in the meantime, can we fix the problem of h not running when my channel hangs up after a redirect ? |
| 17:01.44 | jmls | knows how to comment code out ;) |
| 17:06.01 | file | codefreeze-lap: that means you. |
| 17:08.37 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 17:08.37 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 17:09.02 | riksta | what can cause "-- Got SIP response 513 "Message too big" back from 213.166.5.135" ? |
| 17:09.42 | russellb | if the remote side considers the message it received to be too big ^_^ |
| 17:10.17 | riksta | russellb: hehe :) I am receiving it since i recompiled asterisk tunk last night, I'm unsure how to debug |
| 17:15.34 | putnopvut | riksta: in the CLI you can use the command 'sip set debug on' to see the SIP messages. |
| 17:15.46 | putnopvut | Then you can see the exact message that the other end thinks is too big. |
| 17:16.31 | riksta | putnopvut: yeah i have dumped the sip data with tshark but I don't know what to look for now :P apart from i found this 513 message too big |
| 17:17.16 | putnopvut | In the 513 message, you'll see a CSeq header which you can use to match with the request which caused that response. |
| 17:17.43 | riksta | putnopvut: cool, i'll look |
| 17:18.00 | jmls | codefreeze-lap: hope that I haven't upset you too much with my questions and comments |
| 17:18.07 | jmls | still friends ? |
| 17:18.11 | riksta | putnopvut: just has a "CSeq: 103 BYE" |
| 17:18.14 | jmls | :-| |
| 17:19.15 | putnopvut | riksta: right, now you look for a SIP BYE message which has CSeq 103 and which has the same callid as the 513 response. |
| 17:19.30 | putnopvut | (I should have mentioned the callid earlier, sorry about that) |
| 17:20.30 | riksta | putnopvut: ok found it ? |
| 17:20.44 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 17:20.44 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 17:21.39 | riksta | putnopvut: it looks like this http://pastebin.ca/1304393 |
| 17:22.39 | putnopvut | Hmm, that makes no sense at all. The message is well within the size of a SIP request. |
| 17:22.40 | jmls | file: are there any other apps that behave the same way as park ? |
| 17:23.13 | file | I don't know off the top of my head |
| 17:23.15 | jmls | (i.e. the h is not run on hangup) |
| 17:23.15 | riksta | putnopvut: yes i thought it was >= 2048 |
| 17:23.16 | putnopvut | riksta: does this actually cause any noticeable issues? |
| 17:23.27 | riksta | putnopvut: yes, the call does not go through at all ! |
| 17:23.42 | putnopvut | Are you sure that this 513 is the reason why? |
| 17:23.57 | riksta | putnopvut: i don't know enough, can I put the whole long in pastebin? |
| 17:24.30 | putnopvut | If you want to, you can. |
| 17:24.44 | putnopvut | I can't guarantee I'll see the problem right away, but I'll take a look. |
| 17:24.53 | riksta | putnopvut: i appreciate it, pls hold |
| 17:26.20 | jmls | is there a way of identifying in res_features that it is "park" that is the reason why we are there, and only run the "h" code if the call is being parked ? |
| 17:26.54 | jmls | that way, the default behaviour will return to all other types of apps / commands that use bridging |
| 17:27.54 | riksta | http://pastebin.com/m5c43f95d |
| 17:28.19 | riksta | putnopvut: does that look ok? |
| 17:28.44 | putnopvut | Yeah, there are some odd metacharacters at the beginning of all the SIP messages, but I can read it all right. I'll let you know if I see anything odd. |
| 17:30.34 | putnopvut | riksta: it may be a problem with the far-end. 5XX messages indicate server problems, and I see a 503 in there too (although because of the weird metacharacters I can't tell if Asterisk is sending that or if the far end is) |
| 17:30.49 | putnopvut | oh, wait, I can look at the other headers and tell. |
| 17:31.01 | jmls | erm, if the call is "parked" and it times out, it returns to a specific context, or default, right ? |
| 17:31.30 | jmls | so how does a "parked" call get converted back into a "real" channel in order to continue in the dialplan ? |
| 17:31.30 | riksta | putnopvut: thanks... I believe that I haven't made any changes since this problem occured.... and that it might be with the SIP provider, but they are saying it's not their problem :( |
| 17:31.55 | jmls | and couldn't we use that code to convert it back to a "real" channel in order to run the h extension ? |
| 17:32.41 | putnopvut | riksta: it seems like there is information missing here. I see responses for INVITE requests, but I don't see the INVITEs themselves. |
| 17:33.14 | riksta | putnopvut: can that be caused by me updating from the 1.6.1-beta4 to the trunk last night? |
| 17:33.44 | riksta | putnopvut: what's weird is this: my exten 1000 cannot make the call out... but exten 1002 across the desk can call...but we use the same config and dial line |
| 17:33.46 | putnopvut | It's possible. It's not recommended to use trunk code in production since there could be bugs like this. |
| 17:33.58 | riksta | putnopvut: and they are the same phone |
| 17:34.07 | riksta | putnopvut: yeah i said that last night, but i had no option :) |
| 17:35.10 | *** join/#asterisk-dev DarkRift (n=dark@65.92.170.122) |
| 17:36.20 | riksta | putnopvut: so you are not able to see anything that is causing it that i could investigate? |
| 17:36.31 | putnopvut | I'm still taking a closer look. |
| 17:36.38 | riksta | putnopvut: ok thanks, i appreciate it |
| 17:36.55 | putnopvut | It looks like Asterisk sends an INVITE to SER, and SER responds with a 408. I don't actually see the INVITE in your trace, but I see the 408. |
| 17:37.22 | putnopvut | then, later, it looks like Asterisk sends a 503 to the phone that initially sent the INVITE. |
| 17:37.49 | riksta | putnopvut: my trace was logged by tshark port 5060 -w file.cap is that not sufficient? |
| 17:39.05 | putnopvut | If you use Asterisk's 'sip set debug on' command, it may make things more clear, and it will explicitly tell the direction of the messages being sent and received. |
| 17:39.13 | *** join/#asterisk-dev korihor (n=korihor@201.210.239.172) |
| 17:39.24 | riksta | putnopvut: i shall do that and pastebin it |
| 17:39.44 | putnopvut | Thanks. I have to head out in about 5 minutes for a while, but I can look at it in further detail when I return. |
| 17:41.02 | riksta | putnopvut: http://pastebin.com/d2c9cdc16 |
| 17:41.15 | putnopvut | Ah, now I see the INVITEs :) |
| 17:41.27 | riksta | putnopvut: good :) i appreciate you have to leave |
| 17:41.29 | riksta | i can hang around |
| 17:42.34 | putnopvut | The key to this is figuring out why SER is responding to the INVITE with a 408. |
| 17:44.10 | putnopvut | I'm looking at section 21.4.9 of RFC 3261 to figure out why SER might be sending a 408. |
| 17:44.25 | riksta | putnopvut: cool i will look too (i dont know what a 408 is) |
| 17:44.36 | putnopvut | It's labeled as "response timeout" |
| 17:44.58 | putnopvut | It seems to mean that SER was not able to come up with a suitable response in time. |
| 17:45.56 | riksta | putnopvut: it's odd because another phone in the office can make the calls successfully |
| 17:46.01 | riksta | do u want me to paste you a successful trace? |
| 17:46.07 | putnopvut | Yes please. |
| 17:46.08 | riksta | or will it not help? |
| 17:46.09 | riksta | ok |
| 17:46.14 | putnopvut | Are both phones attempting to dial the same location? |
| 17:46.18 | riksta | yes! |
| 17:47.14 | riksta | http://pastebin.com/d3f3781f9 putnopvut |
| 17:47.52 | putnopvut | I see a difference. |
| 17:48.01 | putnopvut | The To: field of the failed call is missing the first 9 |
| 17:48.29 | riksta | sorry, which line? |
| 17:48.32 | putnopvut | 907971296525 is in the successful call, but 07971296525 is in the failed call. |
| 17:48.37 | putnopvut | let me look at the pastebins... |
| 17:49.02 | riksta | putnopvut: ahh sorry, on that phone u dial 9 as outside line on my phone it's 4, but it does the same thing |
| 17:49.10 | putnopvut | In the failed pastebin, look at line 161. |
| 17:49.42 | putnopvut | Oh, you're right. my mistake. |
| 17:49.53 | riksta | nice try though ;) tehe |
| 17:50.06 | codefreeze-lap | jmls: still friends. Sorry for the wait. I got yanked to handle a small family crisis. Ooops. here we go again |
| 17:50.23 | jmls | stops turning blue |
| 17:51.03 | jmls | only has large family crisises. Or is that crisisi ? |
| 17:52.00 | putnopvut | riksta: I'll take a closer look when I get back. I need to head out. |
| 17:52.18 | riksta | putnopvut: no problem, any particular time i should be around (pls say in +x hrs hehe) |
| 17:53.12 | *** join/#asterisk-dev stephank (n=urk@2002:52c5:cf78:0:21c:c4ff:fece:ea94) |
| 17:54.29 | codefreeze-lap | jmls: well, we have two things perhaps colliding here: the h-exten being mucked with for the sake of bridged cdrs, one, and two, the parking stuff was modded to do masquerading; the two of them together might be what's going on. I'll have to see if we can work around it. |
| 18:00.12 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 18:10.30 | jmls | codefreeze-lap: if I comment out the "ast_set_flag(chan, AST_FLAG_BRIDGE_HANGUP_RUN);" in res_features.c then the h extension is run a second time when the zap call is hung up |
| 18:10.59 | jmls | so my problem definately is caused by the new block of code introduced in r142675 |
| 18:11.34 | jmls | (the first time h is run is before the zap channel is redirected into a meetme room) |
| 18:15.27 | codefreeze-lap | jmls: I am not-so-familiar with the AMI redirect, and how/why parking is involved. I'll have to look at that code. It sure looks like a parking-related snafu to me... we'll see |
| 18:16.43 | mvanbaak | redirect should not touch parking |
| 18:16.50 | codefreeze-lap | jmls: and yes, the flag is set for the bridge h-exten; if its run there, then you don't want to run it in the pbx. The trick will be recognizing the situation and NOT running the h-exten in the bridge code. |
| 18:16.59 | jmls | heh! |
| 18:17.04 | jmls | found a workaround ... |
| 18:17.08 | mvanbaak | lol |
| 18:17.30 | codefreeze-lap | mvanbaak: or it may just mean that the redirect uses some mechanisms that parking would.... |
| 18:17.54 | jmls | redirect to an extension in [foo] that simply does a goto [bar] where it goes into the meetme |
| 18:18.02 | jmls | [foo] has no h extension, [bar] does |
| 18:18.26 | jmls | because [foo] has no h, the code in res_features is not executed, the flag is therefore not set |
| 18:18.40 | mvanbaak | cool |
| 18:18.40 | jmls | and when zap hangs up, the h in [bar] is executed at the right time ... |
| 18:19.06 | codefreeze-lap | jmls: verrrry interesting. |
| 18:19.26 | mvanbaak | indeed |
| 18:22.08 | jmls | can you set a flag somewhere to say that "this channel is parked" and res_features checks this flag and runs the h-extension code if and only if the flag is set ? |
| 18:23.14 | codefreeze-lap | jmls: no. The masqueraded copy would be the one that got the flag, but no h-exten will get run for him. It's the <Zombie> that would need it. |
| 18:23.56 | codefreeze-lap | jmls: waitaminute. When we do the parking, tho, we might be hand on both, and can set the flag on the zombie.... |
| 18:24.10 | codefreeze-lap | uh, /be/have/ |
| 18:24.26 | codefreeze-lap | not a bad idea. |
| 18:25.10 | jmls | I presume that the park app gets the channel before it masquerades - can a channel variable be set ("ISPARKED") that can be checked |
| 18:26.20 | codefreeze-lap | Third-order effects set in, tho.... let me think. In parking, the other channel gets hung up.... end of bridge... but your redirect may not involve a hangup, and therefore multiple ops in between are possible... |
| 18:28.07 | jmls | but it is only parking that has the problem of no "h" |
| 18:28.24 | jmls | so only set the flag in the parking app itself |
| 18:29.45 | codefreeze-lap | Well, maybe its the only one, maybe not. Masquerades are done in several places. |
| 18:33.24 | freddyk | hi all |
| 18:33.33 | freddyk | good evening (CET) |
| 18:33.40 | codefreeze-lap | It might not matter, tho; if we just park, and other ops happen, might not matter ; we'd just not run the h-exten at the bridge level if it was so marked. |
| 18:34.10 | mvanbaak | good evening (GMT+1) |
| 18:34.20 | jmls | right |
| 18:34.35 | freddyk | mvambaak (CET=GMT+1) |
| 18:34.51 | freddyk | so, |
| 18:35.04 | freddyk | yesterday have released a skinny channel |
| 18:35.08 | freddyk | that works with no hangs |
| 18:35.10 | freddyk | :) |
| 18:35.31 | freddyk | btw |
| 18:35.36 | freddyk | i have a question |
| 18:35.40 | mvanbaak | I have no idea what you mean |
| 18:35.46 | freddyk | eheheh |
| 18:35.46 | mvanbaak | 19:35 < freddyk> yesterday have released a skinny channel |
| 18:35.47 | riksta | putnopvut: are you back? |
| 18:35.48 | mvanbaak | ???? |
| 18:35.55 | freddyk | you know |
| 18:36.02 | freddyk | i'm beginning to patch chan_skinny |
| 18:36.10 | freddyk | and i wrote the same time another channel |
| 18:36.14 | freddyk | for skinny |
| 18:36.17 | freddyk | named chan_sccp |
| 18:36.35 | freddyk | this last one was a bit unstable |
| 18:36.41 | freddyk | and with some tricks |
| 18:36.49 | freddyk | it become stable |
| 18:36.53 | freddyk | i also modified |
| 18:36.56 | freddyk | chan_skinny |
| 18:37.00 | lmadsen | I don't get why you would have two channels to support skinny... |
| 18:37.01 | freddyk | as my code is my code |
| 18:37.08 | jmls | here's another question |
| 18:37.20 | lmadsen | jmls: your question quota has been exhausted for today. Please come back tomorrow. |
| 18:37.27 | jmls | does it matter which field you use for the sizeof when .... |
| 18:37.28 | mvanbaak | chan_sccp is evil |
| 18:37.29 | freddyk | lmadsed: easy, one has been almost wrote, the other it's going to be |
| 18:37.32 | jmls | oh crap |
| 18:37.40 | jmls | turns off the keyboard |
| 18:37.48 | lmadsen | freddyk: does not parse |
| 18:37.53 | lmadsen | jmls: :D joke! |
| 18:37.56 | jmls | heh |
| 18:37.59 | mvanbaak | freddyk: you have patches for chan_skinny ? |
| 18:38.08 | freddyk | mvanbaak: yes i have |
| 18:38.31 | jmls | does it matter which field you use for the sizeof when you use ast_copy_string ? |
| 18:38.45 | jmls | for example |
| 18:38.50 | jmls | a) ast_copy_string(save_exten, chan->exten, sizeof(save_exten)); |
| 18:39.16 | jmls | b) ast_copy_string(savelastdata, bridge_cdr->lastdata, sizeof(bridge_cdr->lastdata)) |
| 18:39.19 | mvanbaak | freddyk: I'm interested in them |
| 18:39.29 | mvanbaak | freddyk: do you have an account on bugs.digium.com ? |
| 18:39.38 | jmls | a) uses field 1, b) uses field 2 for the sizeof |
| 18:39.48 | freddyk | mvanbaak: btw, i should understand if using label declaration for multilanguage support from chan_sccp will be a copy as, they're declared the same by cisco |
| 18:40.48 | freddyk | mvanbaak: also, i patched a cisco discovery protocol driver to get working vt advantage |
| 18:41.09 | freddyk | mvanbaak: i also made a dump of new protocol |
| 18:43.21 | riksta | what is the maximum allowed size of an INVITE? if i send a call with a callerid name that is too long my sip trunk provider is rejecting it (eg 1020 chars) but if i send one at 1017 chars it is being accepted and the call goes through |
| 18:43.48 | freddyk | btw sccp is interesting |
| 18:44.05 | freddyk | as an sccp phone when bridget to a sip trunk |
| 18:44.08 | freddyk | talks sip |
| 18:44.09 | freddyk | :) |
| 18:45.27 | stephank | sccp is horrible :o |
| 18:45.36 | stephank | atleast, our experience with asterisk and sccp is |
| 18:45.49 | freddyk | you're right stephank |
| 18:45.51 | mvanbaak | stephank: chan_sccp or chan_skinny ? |
| 18:46.00 | stephank | chan_skinny |
| 18:46.22 | mvanbaak | freddyk: can you send me a mail with the info etc ? |
| 18:46.35 | mvanbaak | freddyk: I'm about to leave my console for a couple of hours |
| 18:46.44 | freddyk | mvanbaak: we need to talk |
| 18:46.48 | mvanbaak | freddyk: so would be nice if I can read up on it by email and respond |
| 18:46.51 | mvanbaak | freddyk: indeed |
| 18:46.57 | mvanbaak | freddyk: you online this weekend ? |
| 18:47.02 | freddyk | mvanbaak: for sure |
| 18:47.06 | mvanbaak | k |
| 18:47.12 | mvanbaak | then we'll talk this weekend |
| 18:47.30 | mvanbaak | I'll have to go for dinner and party after that |
| 18:47.37 | freddyk | mvanbaak: as you like |
| 18:48.44 | mvanbaak | dont have time right now, sorry |
| 18:48.51 | freddyk | :) |
| 18:48.53 | freddyk | never mind |
| 18:51.01 | ccesario | lmadsen, ping ? |
| 18:51.30 | jmls | mmmm. |
| 18:51.53 | jmls | why can't park be treated like a really simple dynamic meetme ? |
| 18:51.54 | lmadsen | ccesario: pong |
| 18:52.02 | ccesario | lmadsen, moy update the your trunk, and now I update my asterisk |
| 18:52.10 | lmadsen | ccesario: ok... |
| 18:52.20 | ccesario | and I continue with any problems in queues transfer |
| 18:52.57 | jmls | when you "park" you redirect the channel into a meetme room |
| 18:53.10 | ccesario | lmadsen, bt full say me http://pastebin.com/m15a11e09 |
| 18:53.23 | lmadsen | ccesario: again, you need to follow up on the bug report, I can't help you here. |
| 18:53.24 | jmls | when you "pickup" you redirect from the meetme back to the extension |
| 18:53.47 | lmadsen | attach a useful backtrace (i.e. DONT_OPTIMIZE enabled) to the bug report |
| 18:54.01 | lmadsen | the one you have there looks ok |
| 18:54.22 | ccesario | lmadsen, no problem.... I'll pois in bug report ;) |
| 18:54.55 | lmadsen | ccesario: make sure it is attached as a file, don't paste it as a note pls |
| 18:55.48 | ccesario | lmadsen, ok |
| 19:06.32 | *** join/#asterisk-dev joshaidan (n=joshaida@S01060090f8009fa6.tb.shawcable.net) |
| 19:08.09 | putnopvut | riksta: I'm back now. I left you a pm. |
| 19:08.42 | *** join/#asterisk-dev pdfhacker (n=dd@38.104.98.118) |
| 19:08.51 | lmadsen | putnopvut: welecome back! |
| 19:09.00 | putnopvut | lmadsen: thanks, great to be here! |
| 19:09.28 | lmadsen | great to have you here! |
| 19:17.36 | putnopvut | kpfleming: any idea why 13071 is assigned to you? |
| 19:18.07 | kpfleming | mantis 13071 |
| 19:18.13 | kpfleming | doh |
| 19:18.15 | lmadsen | M13071 |
| 19:18.17 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0013071: [patch] OPTIONS response on default port. reported by baron (Karma: +2.00) http://bugs.digium.com/view.php?id=13071 |
| 19:18.29 | kpfleming | vaguely remember that one |
| 19:18.35 | kpfleming | i think i commented on it |
| 19:18.40 | lmadsen | you didn't :) |
| 19:18.40 | kpfleming | and was going to work on it |
| 19:18.52 | kpfleming | well, i don't specifically remember then |
| 19:19.20 | putnopvut | I just didn't want to commit the (reversed) patch that was attached if you had a reason to think it was a bad patch. |
| 19:22.13 | kpfleming | let me look at it |
| 19:23.00 | kpfleming | now i remember... i was working on some NAT related stuff, and this was going to be affected by it |
| 19:23.09 | putnopvut | ah, I see. |
| 19:23.10 | kpfleming | however, that work died a slow death, and will not happen soon |
| 19:23.21 | kpfleming | so this can proceed if the patch does the desired work and is correct |
| 19:23.41 | putnopvut | All right. Aside from the patch being reversed, it passes my quick sanity check. |
| 19:26.47 | *** join/#asterisk-dev qdk (n=qdk@79.138.241.68.bredband.3.dk) |
| 19:31.06 | *** part/#asterisk-dev jtodd (n=jtodd@c-76-124-123-117.hsd1.pa.comcast.net) |
| 19:31.15 | *** join/#asterisk-dev jtodd (n=jtodd@c-76-124-123-117.hsd1.pa.comcast.net) |
| 19:47.05 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 20:06.24 | moy | lmadsen: I'm trying to update a diff in the reviewboard, but, I get "No valid separator after the filename was found in the diff header", do you know what that is? |
| 20:07.27 | lmadsen | sorry, I have never used reviewboard |
| 20:07.29 | lmadsen | russellb: ideas? |
| 20:08.56 | moy | the updated diff is http://www.moythreads.com/mfcr2.diff |
| 20:09.45 | *** join/#asterisk-dev jjshoe (n=jjshoe@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 20:09.48 | seanbright | moy: how did you create the diff? |
| 20:09.58 | seanbright | not with 'svn diff' |
| 20:11.26 | moy | yeah, but, I had problems in the past with reviewboard, and I think you helped me, removing (../trunk/stuff) lines |
| 20:11.42 | tzafrir_laptop | but how? "Index" is not from 'diff' either |
| 20:12.37 | moy | svn diff |
| 20:12.37 | tzafrir_laptop | where's the revision? |
| 20:13.43 | tzafrir_laptop | after the file names? |
| 20:13.56 | moy | tzafrir_laptop: this is a mess, will try again ... in the past, seanbright, or someone here helped me to put the past revisions, because it seemed the revision after the file names was causing problems |
| 20:13.59 | russellb | the easiest way to post a diff is using post-review |
| 20:14.11 | moy | russellb: how's that? |
| 20:14.13 | russellb | get the patch applied to a working copy, then run ... $ post-review -r <review> |
| 20:14.24 | russellb | the post-review script is distributed by reviewboard, i'll get you a link |
| 20:14.33 | moy | cool, thanks |
| 20:14.41 | russellb | http://reviewboard.googlecode.com/svn/trunk/reviewboard/contrib/tools/post-review |
| 20:14.59 | russellb | once you post a diff using that, go to the review, you'll need to "publish" your updated diff |
| 20:15.53 | tzafrir_laptop | doesn't reviewboard take branches? |
| 20:18.19 | russellb | no |
| 20:21.31 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 20:25.50 | lmadsen | otherwiseguy: w00t |
| 20:26.19 | otherwiseguy | lmadsen: w00t? |
| 20:26.31 | lmadsen | 14203 |
| 20:27.09 | otherwiseguy | lmadsen: I get a w00t for committing a simple patch that someone else wrote that fixes an error I made? Awesome! |
| 20:27.18 | otherwiseguy | curses his ctrl-return |
| 20:27.32 | lmadsen | otherwiseguy: yes... yes you did |
| 20:33.00 | *** join/#asterisk-dev ManxPower (n=Administ@router.asteriasgi.com) |
| 20:33.37 | ManxPower | wonders who's bright idea it was to remove sounds.txt from the Asterisk 1.4 tarball. |
| 20:35.24 | Corydon76-dig | ManxPower: it's included in the subsidiary tarball |
| 20:35.51 | ManxPower | not the one I have |
| 20:36.44 | ManxPower | they renamed them which is why I could not find it. |
| 20:37.24 | ManxPower | Sorry I should have saw that fine in the list of 200+ sound files. Whas the name change on UPGRADE.TXT |
| 20:38.47 | Qwell | ManxPower: what's up with the hostname? |
| 20:39.33 | Corydon76-dig | Qwell: he's working in HSV now |
| 20:39.41 | Qwell | orly? |
| 20:40.02 | Corydon76-dig | Qwell: don't worry; you're not his type |
| 20:40.23 | ManxPower | Asteria is my employer now |
| 20:40.41 | ManxPower | Digium had their chance 8-| |
| 20:41.48 | Juggie | i think asteria bought me lunch once :P |
| 20:42.46 | Qwell | Juggie: I was totally there. |
| 20:42.46 | lmadsen | sangoma bought me dinner on top of the CN tower once :) |
| 20:42.59 | Qwell | Juggie: ! |
| 20:43.07 | Qwell | Juggie: Didn't you buy us lunch once too? |
| 20:43.15 | Qwell | or dinner I think |
| 20:43.57 | putnopvut | I ate lunch with Juggie once |
| 20:44.10 | Qwell | putnopvut: but did the Canadian Government pay for it? |
| 20:44.23 | putnopvut | no, I suppose that Sokol and Associates did. |
| 20:44.37 | Juggie | Qwell, i dont get an expense account sadly! |
| 20:44.58 | Juggie | but if it makes you feel better we have a ton of licenses of ABE :) |
| 20:45.02 | Juggie | we bought them not to use them |
| 20:45.06 | Juggie | just to support digium |
| 20:45.09 | Juggie | they are still in boxes |
| 20:45.09 | Qwell | heh |
| 20:45.25 | Juggie | we use the open source version obviously. |
| 20:45.53 | Juggie | that and we figured if we encountered a huge and could repoduce it in ABE we'd get better support from the abe folks on getting it fixed |
| 20:45.55 | Juggie | that hasnt happened though. |
| 20:46.00 | Juggie | *huge bug |
| 20:46.41 | pdfhacker | It seems like Cirpack/v4.39, Mediatrix 1124, and 3Com VCX V7000 SIP gateways use RTP type 96 for DTMF tones. I fixed it by modifying my rtp.c . Has this been a problem for many other people? |
| 20:47.10 | Juggie | pdfhacker, i'd try searching the users list for that question or maybe dev |
| 20:47.18 | Juggie | if it is its definitally been discussed there. |
| 20:49.15 | Juggie | i see some mention of it now, looks like a bug in their implementation and the workaround you mentioned is the correct one |
| 20:49.21 | Juggie | until those vendors fix it |
| 20:50.19 | pdfhacker | Works for me. Just wanted to make sure the problem wasn't more widespread |
| 20:50.26 | jjshoe | Qwell delicious buffalo wild wings for lunch today.. |
| 20:50.54 | Juggie | pdfhacker, it seems to be a known but not extremly common problem |
| 20:51.11 | kpfleming | there is no problem |
| 20:51.25 | kpfleming | all RTP payload numbers above 95 are dynamic, and any number can be used for any payload type |
| 20:51.43 | kpfleming | asterisk defaults to 101 for telephone-event, but will support any payload number the other end wishes to use |
| 20:52.25 | Juggie | kpfleming, if his dtmf doesnt work unless he mods the source |
| 20:52.27 | pdfhacker | interesting. Looking at the SIP data, it looks like the VCX I'm using is indicating that it's using 96, but I still can't read the DTMF tones without hardcoding it in rtp.c |
| 20:52.47 | kpfleming | you are misunderstanding SDP |
| 20:52.57 | kpfleming | did the offer from Asterisk have 96 or 101 as the telephone-event payload number? |
| 20:53.53 | pdfhacker | http://pastebin.com/de8afd9a |
| 20:54.21 | kpfleming | which end sent that? |
| 20:55.52 | pdfhacker | Ah. Sorry. I think that's the side I'm sending back to the gateway. Just a minute |
| 20:56.19 | kpfleming | please use 'VCX' or 'Asterisk'... i have no idea what gateway is in this context |
| 20:57.01 | pdfhacker | that's the side Asterisk is sending to the VCX upon the receipt of a SIP call from the VCX to Asterisk |
| 20:57.22 | kpfleming | so Asterisk sent SDP with 96 as the payload type? was this after your code change? |
| 21:06.11 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-868a18f72883537c) |
| 21:06.11 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 21:10.19 | pdfhacker | yes. This was after the code change |
| 21:10.53 | Juggie | ideadly, a sip debug of the setup not working would be best. |
| 21:10.58 | Juggie | w/o the code change |
| 21:11.56 | kpfleming | correct |
| 21:12.03 | kpfleming | mandatory, actually |
| 21:12.50 | pdfhacker | http://pastebin.com/d42b2dd73 |
| 21:13.18 | pdfhacker | That's what I'm getting after the code change. It's the first thing I receive when Asterisk receives a SIP call from the VCX |
| 21:13.31 | kpfleming | the code change has nothing to do with that |
| 21:13.34 | kpfleming | it's what you received |
| 21:13.37 | pdfhacker | correct |
| 21:13.49 | kpfleming | what we need to see is what asterisk sends in response to that without your code change |
| 21:14.10 | pdfhacker | ok. I'll be able to get that tonight. Right now other people are testing with my existing setup (DTMF working via my hack) |
| 21:14.16 | kpfleming | ok |
| 21:14.21 | pdfhacker | thank you |
| 21:14.26 | kpfleming | is there an issue in mantis for this? |
| 21:15.15 | *** join/#asterisk-dev tacvbo (n=tacvbo@189.146.192.147) |
| 21:20.07 | Corydon76-dig | Okay, I need a field name... for the stored qualify value, but not "qualify"... |
| 21:20.39 | Corydon76-dig | qualify_history perhaps? |
| 21:25.00 | kpfleming | you mean the qualify response time? |
| 21:26.07 | Corydon76-dig | I'm thinking that I might just store the pokeexpire and lastms separately |
| 21:35.01 | Juggie | seanbright! |
| 21:35.53 | seanbright | Juggie! |
| 21:59.59 | mvanbaak | russellb: ping |
| 22:00.04 | russellb | pong |
| 22:00.17 | mvanbaak | any ETA on the res_musiconhold.c patch ? |
| 22:00.34 | russellb | you can commit what i sent you if you want |
| 22:00.49 | russellb | i've been working on other stuff, sorry |
| 22:00.55 | mvanbaak | no problem |
| 22:01.01 | mvanbaak | was just wondering |
| 22:01.17 | mvanbaak | because now I have to scp the patch everytime I setup a new box ;) |
| 22:02.59 | *** join/#asterisk-dev tacubo (n=tacvbo@189.146.185.216) |
| 22:05.27 | putnopvut | what's the res_musiconhold patch? |
| 22:06.09 | russellb | putnopvut: #define mohclass_unref(class) (ao2_ref((class), -1), NULL) |
| 22:06.13 | russellb | that doesn't compile for him |
| 22:06.57 | putnopvut | wtf not? |
| 22:07.06 | putnopvut | change the second comma to a semicolon? |
| 22:07.47 | seanbright | class? CLASS!? |
| 22:07.48 | seanbright | sigh. |
| 22:07.49 | seanbright | heh |
| 22:08.17 | mvanbaak | putnopvut: doesn't work |
| 22:08.19 | russellb | putnopvut: no idea why |
| 22:08.22 | russellb | it's not that ... |
| 22:08.29 | russellb | i mean, it's valid |
| 22:08.33 | mvanbaak | yeah |
| 22:08.34 | seanbright | what's the error? |
| 22:08.35 | russellb | but his gcc version won't take it |
| 22:08.36 | russellb | shrugs |
| 22:08.54 | mvanbaak | res_musiconhold.c: In function `moh_files_release': |
| 22:08.54 | mvanbaak | res_musiconhold.c:217: warning: assignment makes pointer from integer without a cast |
| 22:09.04 | seanbright | the NULL? |
| 22:09.05 | putnopvut | oh, duh |
| 22:09.06 | mvanbaak | I get that for every use of the function |
| 22:09.07 | putnopvut | SENTINEL |
| 22:09.09 | seanbright | yeah |
| 22:09.13 | seanbright | was thinking that |
| 22:09.21 | mvanbaak | hhmm |
| 22:09.24 | putnopvut | even though SENTINEL doesn't really make as much sense there. |
| 22:09.24 | mvanbaak | let me try that |
| 22:09.51 | russellb | SENTINEL? |
| 22:09.55 | russellb | how is that relevant? |
| 22:09.58 | seanbright | cast NULL to a void * |
| 22:10.07 | putnopvut | yeah, on his system NULL is just 0, not a pointer. |
| 22:10.17 | putnopvut | So you have to cast it to a pointer when a pointer is expected. |
| 22:10.25 | putnopvut | SENTINEL does just that. |
| 22:10.35 | russellb | um, that would cause build failures in many places wouldn't it? |
| 22:11.02 | seanbright | russellb: stop questioning putnopvut |
| 22:11.04 | mvanbaak | depends |
| 22:11.05 | seanbright | i don't like it |
| 22:11.15 | mvanbaak | but, no cigar on this one |
| 22:11.21 | putnopvut | ah, crap. |
| 22:11.29 | mvanbaak | replacing NULL with SENTINEL does not change anything |
| 22:11.43 | mvanbaak | res_musiconhold.c: In function `moh_files_release': |
| 22:11.43 | mvanbaak | res_musiconhold.c:217: warning: assignment from incompatible pointer type |
| 22:11.52 | seanbright | well that's different |
| 22:11.53 | mvanbaak | message is different |
| 22:12.06 | russellb | cast NULL to (void *) |
| 22:12.43 | mvanbaak | that fixes it |
| 22:12.49 | seanbright | 17:09 <@seanbright> cast NULL to a void * |
| 22:12.55 | seanbright | <-- awesome |
| 22:13.13 | mvanbaak | SENTINEL is (char *)NULL |
| 22:13.18 | seanbright | ah yes |
| 22:13.27 | seanbright | excellent |
| 22:13.31 | russellb | commits |
| 22:13.50 | mvanbaak | thank you |
| 22:13.59 | putnopvut | ah, I thought SENTINEL was void * |
| 22:14.00 | putnopvut | My mistake |
| 22:16.35 | mvanbaak | it is on linux |
| 22:16.41 | mvanbaak | I think |
| 22:24.34 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 22:25.38 | mvanbaak | I'm not a subnet guru, but isn't 192.168.1.0/255.255.255.0 the same as 192.168.1.255/255.255.255.0 ? |
| 22:26.19 | putnopvut | 192.168.1.255 would be the broadcast address for the subnet |
| 22:26.34 | mvanbaak | uhhuh |
| 22:26.44 | putnopvut | whereas 192.168.1.0 would be the subnet's ...um... network address? ( I forget the term) |
| 22:26.56 | putnopvut | But they're in the same subnet, though. |
| 22:27.02 | mvanbaak | yeah |
| 22:27.27 | mvanbaak | and I thought when you specify the subnetmask like this it would resolve to the same network |
| 22:27.33 | mvanbaak | but I can be wrong |
| 22:28.56 | jpeeler | the valid host address range is 1-254 as putnopvut implied |
| 22:30.10 | putnopvut | I've never specified a network with anything other than the .0 (or equivalent address) |
| 22:30.13 | mvanbaak | 23:28 < mvanbaak> question: is 192.168.1.0/255.255.255.0 the same as 192.168.1.255/255.255.255.0 ? |
| 22:30.16 | mvanbaak | 23:28 < mvanbaak> I always thought it resolved to the same subnet |
| 22:30.19 | mvanbaak | 23:29 < viq> It's just a 192.168.1/24, so should be the same |
| 22:31.22 | mvanbaak | that's what I was trying to say, but he's better in explaining stuff |
| 22:31.23 | mvanbaak | ;) |
| 22:32.29 | jpeeler | as far as i know it would be the same as well as any other such as 192.168.1.87/255.255.255.0 |
| 22:33.53 | mvanbaak | yeah |
| 22:34.03 | mvanbaak | thanks for confirming |
| 22:34.05 | jpeeler | i bet you could type in subnet calculator and find a page that will confirm as well as show you all the bits are masked |
| 22:34.21 | jpeeler | how they are that is |
| 22:34.46 | mvanbaak | that makes the last non-lmadsen comment on 13065 non-relevant |
| 22:36.39 | wedhorn | isn't the 255.255.255.0 is just a bitmask for the first 3 bytes (which means they'll all be the same) |
| 22:37.05 | jpeeler | yes |
| 22:37.52 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:37.52 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 22:40.21 | mvanbaak | yup |
| 22:51.37 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.193.18) |
| 22:52.52 | *** join/#asterisk-dev nirz (i=c075ec1d@gateway/web/ajax/mibbit.com/x-5bb500b6128204f6) |
| 22:54.11 | wedhorn | mvanbaak: we seem to have locks for most structures in chan_skinny, can you think of any reason not to use just device locks? |
| 22:54.28 | wedhorn | if we lock a device, we will protect the lines, subs, speeddials etc |
| 22:54.57 | wedhorn | that fall under the device |
| 22:58.44 | mvanbaak | wedhorn: if any piece of code does something without the device lock we are fsck-ed (when the other locks are removed) |
| 22:59.42 | nirz | hello, someone knows if it's possible to run a cli command from an agi script ? |
| 23:00.32 | mvanbaak | sure |
| 23:00.55 | mvanbaak | just exec 'asterisk -rx "your command here"' |
| 23:00.55 | russellb | #asterisk |
| 23:01.15 | russellb | topic and on-join message isn't enough i guess |
| 23:01.40 | wedhorn | mvanbaak: yep, but there are only limited places where code can originate from, namely: |
| 23:02.04 | Qwell | russellb: Bot that gives +v once he gets a message of "Yes, I have read the topic as well as the information from ChanServ. I agree to these conditions." |
| 23:02.44 | wedhorn | all device stuff comes through handle_message, and all core stuff through one of the procs listed in skinny_tech |
| 23:02.48 | russellb | Qwell: yeah |
| 23:03.23 | wedhorn | mvanbaak: so if we lock at the beginning and end of each of those, there shouldn't be an issue |
| 23:03.33 | wedhorn | unlock at the end |
| 23:04.48 | kpfleming | you have to be careful of locking order as well |
| 23:05.28 | mvanbaak | indeed |
| 23:05.48 | *** part/#asterisk-dev nirz (i=c075ec1d@gateway/web/ajax/mibbit.com/x-5bb500b6128204f6) |
| 23:05.49 | mvanbaak | but, I think I follow what wedhorn is thinking |
| 23:06.19 | wedhorn | kpfleming: that's sort of the point, as long as we don't block execution, my approach should overcome deadlocks |
| 23:07.45 | kpfleming | no |
| 23:07.49 | kpfleming | it can't |
| 23:07.59 | kpfleming | because sometimes when your skinny_tech functions are called, the ast_channel is already locked |
| 23:08.03 | kpfleming | most of the time |
| 23:08.18 | kpfleming | and if your non-skinny_tech functions need to lock an ast_channel, then you have a reverse locking order |
| 23:08.27 | kpfleming | reducing locks inside chan_skinny is good, though |
| 23:08.32 | russellb | see CODING-GUIDELINES in trunk :) |
| 23:08.39 | russellb | i worked on documenting that issue :) |
| 23:09.56 | wedhorn | ok, will need some more pondering |
| 23:20.40 | codefreeze-lap | jmls: what bug did you think was related to your problem? was it 14122? |
| 23:20.57 | jmls | someone else made that connection |
| 23:21.03 | jmls | about macros and no h |
| 23:21.15 | jmls | however, it could be related .. |
| 23:21.43 | codefreeze-lap | yeah... it could... maybe... I'll be working on your and that one over the weekend, methinks. |
| 23:22.02 | mvanbaak | can someone with commit-access run 'blocktrunk6 168265' on 1.6.0 and 1.6.1 ? |
| 23:22.17 | putnopvut | mvanbaak: certainly |
| 23:22.17 | mvanbaak | I reinstalled my laptop and I'm fighting with svnmerge right now |
| 23:22.23 | jmls | ahh - looking at the bug now, and with our discussion, I think he's hitting the problem |
| 23:22.53 | mvanbaak | python-expat is no longer in OpenBSD |
| 23:23.08 | jmls | but what he is hitting is the h extension in res_features (ie before anythign happens) |
| 23:23.17 | putnopvut | mvanbaak: Actually, I'll just do it for 1.6.1, since we typically don't bother to block changes from 1.6.0 |
| 23:23.41 | mvanbaak | good call |
| 23:23.42 | mvanbaak | thanks |
| 23:23.46 | jmls | and not the h extension in the macro |
| 23:23.58 | putnopvut | mvanbaak: done |
| 23:23.59 | mvanbaak | putnopvut: I'm too used to block it in 1.6.0 |
| 23:24.03 | mvanbaak | thanks m8 |
| 23:24.15 | jmls | perhaps |
| 23:24.17 | jmls | ;) |
| 23:24.22 | mvanbaak | putnopvut: I'm(removed the err. too) used to block it in 1.6.0 |
| 23:24.27 | jmls | but thanks for looking into the problem. |
| 23:24.41 | putnopvut | mvanbaak: sometimes I still do it too. |
| 23:24.49 | jmls | I've gotta catch some zzzz's now, but will be back online in about 6-7 hours :( |
| 23:24.51 | mvanbaak | yeah |
| 23:24.54 | jmls | goodnight all |
| 23:24.57 | mvanbaak | old habits die slowely |
| 23:28.14 | codefreeze-lap | jmls: could easily be. I'll be looking into that. |
| 23:33.40 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:40.29 | wedhorn | damn, russelb happily pointed at his locking doco and then ran away. It say what not to do, not what to do ~:( |
| 23:41.21 | wedhorn | I can't see a way around the possibility of reverse locking. If we don't lock non skinny_tech functions, we will (at some stage) end up with a stale pointer to a chan |
| 23:41.50 | mvanbaak | I'm off for today |
| 23:41.52 | mvanbaak | latero |
| 23:42.57 | kpfleming | M10144 |
| 23:42.59 | MuffinMan | [closed] [Asterisk] Sounds 0010144: No license statemement in the sound tarballs reported by user4338 (Karma: neutral) http://bugs.digium.com/view.php?id=10144 |
| 23:43.38 | kpfleming | wedhorn: this is why the other channel drivers have deadlock avoidance code, which attempts to get the ast_channel lock safely |
| 23:43.52 | kpfleming | in trunk, there is even a macro that encapsulates this process for you |
| 23:44.02 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-868a18f72883537c) |
| 23:52.57 | tzafrir_laptop | kpfleming, great :-) |
| 23:53.35 | kpfleming | yes, it is |
| 23:53.56 | kpfleming | the extra-sounds will never have that because the ownership of them is too muddied, but at least the core sounds are good |
| 23:54.27 | tzafrir_laptop | what about extra-sounds-en alone? |
| 23:54.31 | seanbright | what the hell setting in bash is expanding my ~ when i do tab completion? |
| 23:54.31 | kpfleming | nope |
| 23:54.43 | kpfleming | seanbright: don't know, it's always done that |
| 23:54.47 | seanbright | not for me |
| 23:54.51 | tzafrir_laptop | seanbright, your home directory |
| 23:54.56 | seanbright | ... |
| 23:55.14 | seanbright | i type 'emacs ~/.subversio<tab>' |
| 23:55.18 | seanbright | and it changes to |
| 23:55.22 | tzafrir_laptop | ~N (e.g. ~1) is the Nth directory in the directory stack |
| 23:55.23 | jbot | okay, tzafrir_laptop |
| 23:55.29 | seanbright | 'emacs /home/sean/.subversion' |
| 23:55.33 | tzafrir_laptop | if you use pushd |
| 23:55.37 | seanbright | i do not |
| 23:55.50 | seanbright | oh, found it |
| 23:55.57 | seanbright | shopt -s extglob |
| 23:57.04 | wedhorn | kpfleming: I was thinking that. Something like non skinny-tech functions grabbing a device lock, find channel, try_lock channel, if fail, release device and start again. |
| 23:57.36 | kpfleming | exactly |
| 23:57.48 | kpfleming | so... i ordered some RAM from newegg.com for my new laptop |
| 23:58.08 | kpfleming | usually, when i order from newegg, it arrives the next day, because their shipping facility is a few hundred miles away |
| 23:58.27 | kpfleming | however, check out this route: http://tinyurl.com/9pvrvl |
| 23:58.48 | seanbright | hah |
| 23:58.49 | seanbright | wow |
| 23:59.00 | kpfleming | it has taken a whole day to make each of those hops |
| 23:59.08 | kpfleming | using DHL Global Mail, which i have never heard of before |
| 23:59.10 | Qwell | Cincinnati?! |
| 23:59.22 | seanbright | kpfleming: have you ever heard of the 'traveling salesman' problem? :P |
| 23:59.27 | kpfleming | Memphis, TN - Hebron, KY - Forest Park, GA |
| 23:59.34 | kpfleming | three days to get that far |
| 23:59.41 | kpfleming | i don't know how long it will take to get to HSV from there |
| 23:59.58 | Qwell | You should yell at newegg |