| 00:05.53 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 00:56.53 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 00:57.09 | *** part/#asterisk-dev ClintGoudie-Nice (~clint@smtp.callware.com) |
| 00:57.38 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 01:08.48 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 01:24.50 | Kobaz | do you have to destroy mutexes for linked lists? |
| 01:24.57 | Kobaz | or is freeing the list good enough |
| 01:25.07 | Kobaz | for an RWLIST |
| 01:33.00 | Corydon76-home | Yes, you have to destroy the rwlock |
| 01:36.01 | Kobaz | k, thanks |
| 01:36.25 | Kobaz | how does a module increment/decrement it's use count? |
| 01:36.35 | Kobaz | i was wandering through the 30k lines of chan sip and can't find it yet |
| 01:40.59 | Corydon76-home | It's implicit |
| 01:41.18 | Corydon76-home | The increment and decrement code is in main/loader.c |
| 01:42.29 | Kobaz | implicit hmm |
| 01:42.52 | Kobaz | the use count in sip goes up for each channel, i thought it would be module dependent whether it went up or down |
| 01:44.38 | Kobaz | ah |
| 01:44.41 | Kobaz | there it is |
| 01:44.42 | Kobaz | ast_module_ref |
| 01:44.43 | Kobaz | thanks |
| 01:45.53 | Kobaz | there's a ref leak in 1.6.0.26 in chan sip |
| 01:46.43 | Kobaz | so anyways |
| 01:46.53 | Kobaz | from all your help, here's the gift back to you |
| 01:47.26 | Kobaz | http://pastebin.com/sfy0gDpD |
| 01:48.25 | Kobaz | you can make a link from one channel to another, and it doesn't matter if the channel renames, you can still get at it (ie: transfer/masquerade/etc) |
| 01:48.43 | Kobaz | i need to add some more features and i'll reviewboard it up |
| 01:49.23 | Kobaz | usage: Set(TIE(foo)=SIP/abc); |
| 01:49.47 | Kobaz | and then SIP/abc can become anything at all, you just do ${TIE(foo)} on the channel that set it, and you get the current channel name |
| 01:51.17 | Kobaz | took like 4 days to write |
| 01:51.38 | Kobaz | very painful with deadlocks and everything |
| 01:59.43 | snuff-work | 1 small comment.. use of '//' comment style is against coding guidelines ;) |
| 02:03.21 | snuff-work | from memory also.. use of \retval rather than many \return for doxygen |
| 02:05.15 | snuff-work | another minor thing.. in tie_function_read.. should probably put all the struct's 1st.. rather than having an int then last struct define |
| 02:06.01 | WIMPy | Oh, yes, I read that comment and wondered if a modern compiler wouldn't rearrange them anyway? |
| 02:07.03 | snuff-work | its purely 'readability'.. |
| 02:07.33 | snuff-work | also.. the doco is not yet in xml form for the function |
| 02:07.51 | snuff-work | i mean.. for the 'module'.. |
| 02:07.54 | WIMPy | ok, but the comment, whereever I found it talked about size optimisation. |
| 02:09.09 | snuff-work | i'm not talking about a 'struct' definition.. just in one of his functions.. |
| 02:09.30 | snuff-work | it goes struct x 5 or so.. int.. struct ;) |
| 02:10.01 | WIMPy | ok |
| 02:11.18 | snuff-work | compiler will only move dec order in a struct if u specifically tell it to.. (from memory) |
| 02:18.25 | WIMPy | can only sopt info on reordering functions and istructions, but not data. |
| 02:28.09 | snuff-work | pahole would tell u if you've got wasted space and give u possible 'optimisation' |
| 02:37.34 | Kobaz | snuff-work: i differentiate the // comments from /* comments, for stuff i'm still working on, or stuff that is temporary |
| 02:38.00 | Kobaz | snuff-work: this module is for 1.6.0.26 i havent ported it up |
| 02:38.23 | snuff-work | ah |
| 02:38.27 | Kobaz | i know the coding standard is /* heh |
| 02:38.37 | Kobaz | notice all the stuff commented with // is lock related |
| 02:38.46 | Kobaz | except for maybe one or two things |
| 02:39.28 | Kobaz | so, how do you guys like it? |
| 02:39.49 | Kobaz | it's letting me remove a few hundred lines of external channel tracking |
| 02:39.54 | snuff-work | is too out of coding to say much for anything but style |
| 02:39.54 | Kobaz | stuff i wrote in perl |
| 02:40.01 | Kobaz | heh |
| 02:40.12 | Kobaz | well, i was just curious as to the reaction of what it does |
| 02:40.22 | snuff-work | i think the 'btl_lock;' is not right style |
| 02:40.32 | Kobaz | not necessarily the code (unless there's problems you guys notice in the code) |
| 02:40.35 | Kobaz | yeah i know |
| 02:40.43 | Kobaz | btl lock is temporary to get around deadlock problems |
| 02:40.52 | Kobaz | "bit tie lock" |
| 02:41.01 | Kobaz | parody of the "big kernel lock" in linux |
| 02:41.08 | snuff-work | also i noticed a lot said 'note lock before use' |
| 02:41.13 | snuff-work | i gathered that |
| 02:41.22 | Kobaz | yeah |
| 02:41.31 | Kobaz | and i don't lock it yet because i was hitting horrible deadlock problems |
| 02:41.48 | Kobaz | but btl lock locks everything, so you can only have one writer or one reader at a time anyway with the current design |
| 02:42.00 | Kobaz | so it doesnt matter if you lock lists or not (other than causing deadlocks) |
| 02:42.14 | snuff-work | the 'technical' only time u should have that is if a function could be called when something else already has lock |
| 02:43.16 | Kobaz | yeha |
| 02:43.22 | Kobaz | which is pretty much all of them |
| 02:43.44 | Kobaz | multiple accesses to the read, or multiple hangups or fixups could be happening all at once |
| 02:44.06 | Kobaz | i needed to get my design simplified before i focued on making it more efficient by not locking everything |
| 02:44.16 | Kobaz | you should have seen the early revs |
| 02:44.21 | Kobaz | i still have some code actually |
| 02:44.31 | Kobaz | horrible horrible nested linked list traversals |
| 02:44.40 | snuff-work | just pointing out things that are simple enough.. haven't been in a coding fram eof mind for a while now |
| 02:44.46 | Kobaz | yeah |
| 03:44.33 | WIMPy | Is there a proposed wa to check for either new or old format representation? |
| 03:44.54 | WIMPy | Would #ifdef AST_FORMAT_INC be a good idea? |
| 05:37.08 | luckman212 | is http://www.voip-info.org/wiki/view/Asterisk+debugging still relevant for debugging Ast 1.8.x? |
| 05:37.52 | luckman212 | i'm about to compile a build with DEBUG_THREADS and DONT_OPTIMIZE |
| 05:38.43 | luckman212 | i've also installed strace & gdb, not that I have a clue how to properly use those tools |
| 05:39.11 | luckman212 | but I guess bringing a dull knife to a fight is better than no knife at all |
| 05:39.12 | WIMPy | Just like it says there :-) |
| 05:42.14 | luckman212 | ok, lets give it a spin eh |
| 05:43.55 | luckman212 | do I need to do a 'make clean' first or is it enough to just run the menuselect, enable the compiler flags and do make && make install |
| 05:44.55 | WIMPy | Clean shouldn't be neccessary, but I don't think you gain much by not making clean. |
| 05:45.55 | luckman212 | ok i'm gonna make clean then, thats what they suggest on voip-info. what's 'make valgrind' never heard of that before |
| 06:48.12 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 07:35.36 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e17f:bb65:bc44:1ee1) |
| 07:36.56 | wdoekes2 | valgrind is a memory debugging tool |
| 07:48.15 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:48.18 | schmidts | good morning |
| 07:53.18 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 08:13.23 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:13.23 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:17.14 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:13.03 | *** join/#asterisk-dev mvanbaak_ (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:13.04 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 09:33.44 | tzafrir | Anybody else having problems with attaching a file to a bug report? |
| 09:36.20 | schmidts | havent tried it, but will do it |
| 09:36.21 | schmidts | mom |
| 09:38.30 | schmidts | tzafir works fine for me: R 18765 |
| 09:45.03 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 10:03.14 | tzafrir | ok. Works now |
| 10:26.51 | schmidts | ok |
| 10:53.23 | *** join/#asterisk-dev ccesario_ (~ccesario@189-29-59-116-ac.cpe.vivax.com.br) |
| 10:54.00 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 11:02.43 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:02.43 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:17.43 | *** join/#asterisk-dev kriegerod (~krieger@95.81.21.216) |
| 11:33.02 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:33.02 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:02.46 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:02.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:09.33 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 12:26.20 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 13:45.39 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 14:07.24 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 14:12.58 | *** join/#asterisk-dev erinspice1 (~erin@nat/digium/x-tgalekeqyhulfeps) |
| 14:18.51 | *** join/#asterisk-dev ApOgEE__ (apogee@gateway/shell/bshellz.net/x-djxpmhouavovkvmh) |
| 14:39.54 | *** join/#asterisk-dev erinspice (~erinspice@nat/digium/x-juxmntuzyptmfzdl) |
| 14:44.38 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:44.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:00.08 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:09.21 | *** join/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 15:09.36 | *** part/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 15:11.33 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:14.08 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 15:28.19 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 15:28.29 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:28.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:35.55 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-zkfiukqpkpskjpom) |
| 15:36.32 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:36.32 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:38.16 | asterisk-learner | Hi, any ideas why ast_gethostbyname() might crash ? |
| 15:38.27 | asterisk-learner | isn't supposed to be thread safe ... ? |
| 16:15.08 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:15.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:50.11 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 17:11.29 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 17:14.31 | *** join/#asterisk-dev outtolunc (~me@adsl-66-218-53-172.dslextreme.com) |
| 17:14.43 | *** join/#asterisk-dev moy (~moy@h96-61-34-34.mdsnwi.tisp.static.tds.net) |
| 18:12.50 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 18:38.03 | Qwell | The_Boy_Wonder: ping! |
| 18:39.25 | The_Boy_Wonder | Qwell: hey |
| 18:39.41 | Qwell | The_Boy_Wonder: you're setting best_dst_fmt to slin16 in the if and the else |
| 18:40.08 | The_Boy_Wonder | ! |
| 18:41.11 | kpfleming | that's because it's like totally the best |
| 18:41.22 | file | double rainbow best |
| 18:41.40 | The_Boy_Wonder | fixed |
| 18:42.18 | The_Boy_Wonder | i'd like to think i would have caught that in testing :p |
| 18:42.38 | Qwell | probably |
| 18:53.24 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-hcrwtdnmnvkhdtww) |
| 18:55.23 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-xqpsloowulgyicgw) |
| 19:07.58 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 19:46.27 | philippel_mac | putnopvut: ping |
| 19:47.31 | putnopvut | philippel_mac: pong, sir! |
| 19:48.03 | philippel_mac | putnopvut: ok couple things, first, somethign did change on m side which leads me to some questions but before going there a report back on your changes |
| 19:48.21 | philippel_mac | I now get the CC_INTERFACES set |
| 19:48.42 | philippel_mac | however, there are no MACRO_EXTENSION, PIROIRTY, CONTEXTs set at all anymore |
| 19:48.49 | philippel_mac | where as before, CONTEXT and PRI were set |
| 19:49.13 | philippel_mac | so ... other than the INTERFACES, no identifier to seee who is calling unless it is steering me in the face an I am missing something |
| 19:49.29 | philippel_mac | (and thus CDR(dnid) also blank |
| 19:49.56 | philippel_mac | and MACRO_DEPTH = 0 |
| 19:53.58 | putnopvut | ugh |
| 19:54.48 | philippel_mac | :( I guess you could always just set a channel variable since you can obviously get CC_INTERFACES set properly at that point, unless there are further implications |
| 19:55.31 | putnopvut | Okay, so when you say that something changed on your side, I take it the problem where CallCompletionRequest() was failing has stopped happening, though? |
| 19:56.11 | philippel_mac | yeah that was a series of dumbness on my side, plus what is leading to the next quesiton I have which may be my lack of understanding or may be other issues |
| 19:56.17 | putnopvut | I think the easy way to go would just to make the channel variable instead. |
| 19:56.41 | philippel_mac | that would work for me if you just added a new channel variable |
| 19:57.13 | philippel_mac | when you are ready I will throw my next question to you |
| 19:57.27 | philippel_mac | does not want to bombard putnopvut with 3 questions at once |
| 19:59.21 | putnopvut | heh |
| 19:59.55 | putnopvut | philippel_mac: lay it on me! |
| 20:00.00 | philippel_mac | ok |
| 20:00.45 | philippel_mac | I'm trying to use the CALLCOMPETION() function call and not have anything set in sip.conf. When i do that though, it doesn't quite work, further explanation coming |
| 20:01.34 | philippel_mac | When I don't have it set, I make a call and prior to my call I set all of the settings, dial the number and then I get positive feedback similar to when it does work |
| 20:01.50 | philippel_mac | [Feb 8 11:53:01] CC[11884]: ccss.c:1793 cc_extension_monitor_init: Created an extension cc interface for '3001@from-internal' with id 1 and parent 0 |
| 20:01.57 | philippel_mac | that just after the Dial() |
| 20:02.48 | philippel_mac | but when i hangup, it ends up dumping all the informationabout the call with 4 debug messages which I won't paste all here (if you need them I can pastebin) but the last one being |
| 20:03.05 | philippel_mac | [Feb 8 11:53:04] CC[11851]: ccss.c:2959 cc_do_state_change: Core 0: Unable to find core instance. |
| 20:03.30 | putnopvut | Does one of the messages indicate that a core instance was destroyed? |
| 20:03.31 | philippel_mac | that results in the subsequent call the CallCompletionRequest() to fail |
| 20:03.41 | philippel_mac | yes |
| 20:03.53 | putnopvut | ah, hold on... |
| 20:03.55 | philippel_mac | Destroying cc interface 3001@from-internal |
| 20:04.41 | philippel_mac | anyhow, if I put just cc_agent_policy=generic and cc_monitor_policy=generic in the two sip devices in sip.conf |
| 20:05.14 | philippel_mac | and then run the call, all works and it obviously picks up the other settings like the macro, dialstring, etc because when callback happens, it uses those, so the call is partially working |
| 20:05.43 | philippel_mac | my goal is to have NO settings in sip.conf and use exclusively CONNECTEDCALL() |
| 20:08.04 | putnopvut | Sorry, plumber just showed up at my house so I need a few minutes. |
| 20:08.32 | philippel_mac | np - ping me so my thing beeps when you get back and hope the plumber deal is not a big issue :( |
| 20:15.34 | Corydon76-home | Your thing beeps? |
| 20:23.14 | philippel_mac | what that for me (the thing beeps?) |
| 20:23.59 | philippel_mac | goes back and reads and now understands, yeah it beeps loud and clear, it is very talented |
| 20:24.07 | philippel_mac | can even do ticks :) |
| 20:27.33 | Corydon76-home | and crabs? |
| 20:27.36 | Corydon76-home | ducks |
| 20:31.28 | putnopvut | philippel_mac: ping. I have returned |
| 20:31.37 | philippel_mac | k |
| 20:32.04 | philippel_mac | so ... back to what I was saying, my goal is to use exclusivley CONNECTEDCALL() and nothing in the sip.conf |
| 20:32.09 | philippel_mac | my understanding is that should work? |
| 20:32.59 | putnopvut | Yep, that should. Based on what you're saying, my guess is that the cc_offer_timer is defaulting to 0 seconds in that situation and so the core instance is immediately destroyed once the original call is hung up. |
| 20:33.07 | putnopvut | I can take a look at the code to try to confirm that. |
| 20:33.45 | philippel_mac | I should be setting it just a sec and will check |
| 20:34.23 | philippel_mac | <PROTECTED> |
| 20:35.22 | putnopvut | K, so that's not it. |
| 20:35.35 | philippel_mac | no errors/warning in the log |
| 20:36.39 | putnopvut | Wait a sec, I think I may know what's up. |
| 20:36.54 | philippel_mac | listens carefully |
| 20:36.55 | Corydon76-home | What's up, doc? |
| 20:37.05 | putnopvut | Corydon76-home: lol |
| 20:37.29 | putnopvut | Wait a sec, I think I may know what's up. If you removed all CC options from sip.conf, then that means the device you're calling has no cc_monitor_policy set. |
| 20:38.12 | putnopvut | I have a feeling that might be the problem. If you don't see any CC messages about a device monitor being created, I'd suspect that's the issue. |
| 20:38.34 | philippel_mac | I do see the messages of it being created, just it then get's destroyed |
| 20:38.46 | philippel_mac | I am using CALLCOMPLETION() to set the policies |
| 20:39.08 | philippel_mac | I thought that was adequate ? (otherwise they would not be an option in that function right?) |
| 20:42.07 | Kobaz | i haven't studied the code for 1.8 too much, but is there still one lock per channel? ie... do do still have the lock the whole channel to modify string fields |
| 20:42.52 | philippel_mac | putnopvut: for what it's worth, trying one setting at a time |
| 20:43.12 | philippel_mac | it appears that having cc_monitor_policy in the target extension is what makes it start working |
| 20:43.37 | philippel_mac | even though I am setting that but maybe not soon enough as I set it before that extension has been called |
| 20:44.19 | philippel_mac | do I have to do some sort of 'magic' in the dialplan somehow to get it to set on the target extension which may never answer? |
| 20:44.30 | putnopvut | So I'm thinking about it, and being able to set the monitor policy from the dialplan may not have the utility that the other options do, unless you could somehow set the policies for the destinations you're dialing. |
| 20:45.05 | putnopvut | The thing about dialplan functions is there isn't really the magical __ notation you can use on channel variables to make the option apply to called channels. |
| 20:45.09 | philippel_mac | some how I assumed that setting it in the dialplan would make it 'stick' to what ever devices I eventually call out to ? |
| 20:45.26 | kpfleming | you need to run it in a macro on the dialed channel |
| 20:45.31 | putnopvut | The only thing I can think of is to use the Dial option that calls a macro on the called channel when it answers. |
| 20:45.40 | philippel_mac | kpfleming: won't work if the called cahnnel does not asnwer |
| 20:45.41 | putnopvut | Except that won't help for CCBS. |
| 20:45.44 | kpfleming | right |
| 20:45.45 | putnopvut | jinx |
| 20:46.14 | kpfleming | putnopvut: does the function populate a datastore? |
| 20:46.17 | philippel_mac | I would think that touching it in the current channel shoudl make it 'stick' to what ever channels you dial? |
| 20:46.23 | putnopvut | kpfleming: yes, it does |
| 20:46.30 | kpfleming | so the datastore could be inherited |
| 20:47.22 | putnopvut | You'd have to have some directive to explicitly indicate to do so, though. We don't want that to be automatic. |
| 20:47.44 | Kobaz | datastore inheritance/duplication is optional |
| 20:48.00 | putnopvut | Kobaz: no I mean from the dialplan. |
| 20:48.08 | philippel_mac | putnopvut: well is there any other functional reason you would set CALLCOMPLETION() functions against monitor_ variables ? |
| 20:48.09 | Kobaz | oh yeah you could set a flag saying to inherit or not |
| 20:48.43 | philippel_mac | putnopvut: because my assumption when I am setting those are they are specifically for the called channels |
| 20:48.46 | putnopvut | philippel_mac: not that I can think of. |
| 20:48.55 | putnopvut | Yeah, I can see how that could be a problem. |
| 20:48.59 | philippel_mac | I don't see a scenario where it would do anything for 'me' |
| 20:49.17 | philippel_mac | in which case it would be implicit I think |
| 20:49.19 | putnopvut | Yeah, setting monitor stuff for the calling channel doesn't really help anything. |
| 20:49.45 | philippel_mac | not unless it 'sticks' to my channel and I actually used it to dynamcially change my own phoen's abiilities |
| 20:49.57 | philippel_mac | like making my phone not campable . |
| 20:50.31 | putnopvut | stuff set in CALLCOMPLETION() only applies to the current call, it doesn't stick. So yeah, monitor stuff should either be removed from CALLCOMPLETION() or be changed to apply to the called channels. |
| 20:51.02 | philippel_mac | putnopvut: ok well for the immediate it sounds like I need to set it in sip.conf to get it to work, should I file a bug against that one? |
| 20:51.27 | philippel_mac | and ... on the other first issue of a channel variable available in the macro, should I file a 'bug' against that to or were you just going to go and add something? |
| 20:52.17 | putnopvut | First off, yes file a bug about the fact you have to use sip.conf in order to make things work. It's intended to be able to work from the dialplan if that's what you'd rather do. |
| 20:52.27 | putnopvut | Regarding the channel variable, I'll just add something real quick for that. |
| 20:52.37 | putnopvut | Any preference for the variable name? |
| 20:52.40 | philippel_mac | k sounds great |
| 20:52.56 | philippel_mac | umm - just consistent with your other naming, what will you be using? |
| 20:53.06 | philippel_mac | will it be context and extension, or |
| 20:53.11 | philippel_mac | exten@context |
| 20:53.13 | philippel_mac | or ? |
| 20:53.43 | philippel_mac | otherwise CC_MONITOR_TARGET or sometihng somewhat consistent with your current nomenclature |
| 20:54.26 | putnopvut | How about CC_EXTEN and CC_CONTEXT? |
| 20:54.35 | philippel_mac | sure |
| 20:54.40 | putnopvut | or CC_TARGET_EXTEN and CC_TARGET_CONTEXT. |
| 20:54.43 | putnopvut | I like the first better :) |
| 20:54.46 | putnopvut | less to type |
| 20:55.33 | philippel_mac | sounds good |
| 20:57.32 | putnopvut | Dang I don't even have a 1.8 local copy on this computer. Nice. |
| 20:57.43 | putnopvut | I'll get that in ASAP |
| 20:58.09 | philippel_mac | cool thanks! |
| 20:58.15 | philippel_mac | I"ll get that other bug filed |
| 21:04.40 | *** join/#asterisk-dev bklang_ (~bklang@tesla.alkaloid.net) |
| 21:30.03 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:30.03 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:44.44 | philippel_mac | M18772 |
| 21:44.46 | MuffinMan | [new] [Asterisk] Core/CallCompletionSupplementaryServices 0018772: CALLCOMPLETION(cc_monitor_policy) has no affect after the call attempt ends reported by p_lindheimer https://issues.asterisk.org/view.php?id=18772 |
| 21:44.56 | philippel_mac | ok that should do it :) |
| 21:53.56 | putnopvut | Thanks for filing it! |
| 22:23.43 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 22:29.19 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 23:14.02 | *** part/#asterisk-dev datachomper (~Adium@nat/digium/x-xqpsloowulgyicgw) |
| 23:33.43 | The_Boy_Wonder | Corydon76-home: There appears to be a pretty massive memory leak when debug threads is enabled. i think it may be a result of your locking patch last week. for some reason the tracking structure isn't getting destroyed |
| 23:49.19 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:49.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:49.40 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |