| 00:02.25 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 00:02.25 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 00:12.42 | Kobaz | hmm. i think i found another bug |
| 00:12.51 | Kobaz | DIALEDTIME isn't being populated on Dial() |
| 00:13.09 | seanbright | grep DIALEDTIME apps/app_dial.c |
| 00:14.41 | Kobaz | yeah i know |
| 00:14.52 | Kobaz | it's only being populated if the call is actually bridged |
| 00:15.17 | Kobaz | if it's supposed to do what the documentation says it's supposed to do... it should also be populated if the call isn't bridged |
| 01:16.32 | *** join/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 01:24.29 | seanbright | Kobaz: patches are welcome |
| 01:34.50 | Kobaz | yeap... it's on my list |
| 01:37.57 | *** part/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 03:02.05 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 04:01.15 | d-k-t | hey folks, I had a requirement to detect early media SIT on SIP calls... I've implemented this in app_dial, activated by a dial option, and it works, but, I don't feel it's very clean the way I've done it... using the existing media stream, not cloning it or using hooks... only detecting SIT in early media when it might be more useful to have more generic progress detection with the different features activatable individually etc... so... does anyone have |
| 04:01.15 | d-k-t | any feelings on how this should be implemented? |
| 04:04.26 | snuff-work | mm.. wasn't there some post on ast-dev list about SIT? |
| 04:04.38 | snuff-work | in the last week |
| 04:05.32 | d-k-t | eek, was there? I'll check... I submitted a patch last week I think to make SIT detection work in in the dsp |
| 04:05.33 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 04:05.34 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 04:06.11 | snuff-work | d-k-t: i may be totally wrong.. but just check past week of emails to ast-dev list |
| 04:08.00 | d-k-t | snuff-work, last email I saw about SIT on ast-dev was last july with people requesting it |
| 04:14.04 | snuff-work | mm.. i must have been thinking about another issue :) |
| 04:16.17 | d-k-t | :) |
| 07:11.21 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 07:11.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:12.49 | *** join/#asterisk-dev philipp64 (~chatzilla@63.224.43.239) |
| 07:48.49 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 08:18.07 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:18.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:18.32 | oej | Morning folks |
| 08:25.27 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:32.14 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 08:47.37 | mvanbaak | mornin oej |
| 09:05.41 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:05.41 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:14.19 | wedhorn | hey mvanbaak, how's things |
| 09:20.58 | mvanbaak | hey wedhorn |
| 09:21.02 | mvanbaak | things are good :) |
| 09:21.14 | mvanbaak | wedhorn: and over there ? |
| 09:25.42 | wedhorn | yeah, pretty good, still summer so weather's good |
| 09:26.29 | wedhorn | I note you made a recent reference to the skinny sub handling patch that hasn't be touched for almost a year, any plans for it |
| 10:16.55 | mvanbaak | I'm going to re-test it soon |
| 10:17.02 | mvanbaak | see how it behaves with current asterisk |
| 10:17.34 | wedhorn | i've been pondering over the months whether maybe it's too much for a single bite |
| 10:18.34 | mvanbaak | I've had the same feeling |
| 10:24.45 | wedhorn | how about we start again, and do it in small bits. I've still got all the patches I made along the way somewhere |
| 10:26.08 | wedhorn | I vaguely remember there were 3 main stages, turn common code in procs (eg new call) rather than in-line, do the new sub handling, and redo the locking |
| 10:26.53 | wedhorn | of course there was a lot of overlap between the last two, but hopefully it won't be an issue if I get the chan->readq stuff done |
| 10:33.33 | mvanbaak | hhmm, sounds like a plan |
| 10:33.40 | mvanbaak | that way it's also easier to test |
| 10:34.27 | mvanbaak | because you can say: I'm redoing this, it will for sure impact foo, so test that as much as you can |
| 10:46.49 | wedhorn | yep, and the first bunch of changes only restructure the code without really changing anything. I'll dig out the patches and see if there's something i've overlooked |
| 11:12.42 | LauPro | i have a questin about connect() in asterisk. currently i'm making a new channel for a protocol. and this protocol has to register itself to other servers |
| 11:12.52 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:12.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:12.54 | LauPro | but when i use connect asterisks blocks |
| 11:13.36 | LauPro | and i can't find out how sip or iax implement connect() |
| 11:14.33 | kpfleming | they don't use connect() |
| 11:14.43 | kpfleming | they use UDP, which does not require connect() |
| 11:14.54 | LauPro | ok but SIP is TCP/IP right? |
| 11:15.13 | LauPro | how do they connect with TCP? |
| 11:16.09 | kpfleming | SIP can use TCP, yes |
| 11:16.42 | LauPro | okay.. but how can i implement connect(), because it hangs now on that call, is there some alternative or API? |
| 11:17.46 | kpfleming | no, connect() is how it must be done. if you need to connect() to a remote peer, it will have to be done in a thread dedicated to that task if you don't want it to block any other threads |
| 11:18.30 | LauPro | okay thanks. i'll investigate further why it blocks on my connect-call |
| 11:18.48 | LauPro | but can i see somewhere in the code where sip uses connect? |
| 11:21.29 | kpfleming | sure. open chan_sip.c and search for connect! |
| 11:21.48 | kpfleming | well, actually that's not true... the TCP connection handling is in tcptls.c |
| 11:25.01 | LauPro | ahh ic |
| 11:26.37 | LauPro | wauw, thanks :) |
| 11:27.17 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:19.22 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:19.23 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:25.27 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 12:26.20 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 12:26.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:39.37 | kpfleming | oej: i assume 'bredband' is swedish for broadband... what does the rest of your provider's name mean? |
| 12:41.49 | oej | Umm. I don't know my provider. I'm at customer site :-) |
| 12:41.50 | leifmadsen | mmm.... bread |
| 12:41.51 | oej | Let me check |
| 12:43.16 | oej | Bredbandsbolaget. Bolaget is "company" |
| 12:43.32 | kpfleming | ahh |
| 12:43.44 | kpfleming | the Broadbands Company then :-) |
| 12:43.52 | oej | Nowadays part of Telenor - the norwegian incumbent |
| 12:45.10 | kpfleming | Telenor would also be a good name for a character in a Tolkien novel |
| 12:50.58 | mvanbaak | gheh, indeed |
| 13:16.41 | *** join/#asterisk-dev janinge (j@ninge.net) |
| 14:09.07 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:27.42 | *** join/#asterisk-dev Laureano (~Laureano@190.245.116.231) |
| 15:33.24 | oej | russellb: around? |
| 15:35.01 | kpfleming | no, he's on a plane to las vegas for a short vacation |
| 15:38.33 | *** join/#asterisk-dev d-k-t (~D@112.202.232.46) |
| 15:41.56 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:41.56 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:54.09 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:54.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:54.27 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:54.27 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:01.31 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:11.47 | *** join/#asterisk-dev bsilberman (~bsilberma@65.213.221.1) |
| 16:12.29 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:12.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:17.07 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:19.22 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:19.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:30.40 | Kobaz | EXEC Hangup |
| 16:30.42 | Kobaz | er |
| 16:34.22 | jsmith | hangs up on Kobaz, as instructed |
| 16:35.57 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 16:38.22 | Kobaz | heh |
| 16:40.26 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 17:13.13 | *** join/#asterisk-dev outtolunc (~me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 17:19.13 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-hdepuylnoazngdej) |
| 17:21.42 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-qqsrvcyhnfleygtk) |
| 17:31.04 | *** join/#asterisk-dev elguero (~elguero@ns1.nashuacs.com) |
| 17:45.26 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 18:16.42 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:29.41 | *** join/#asterisk-dev michael-i (~michael-i@141.41.40.185) |
| 18:31.30 | michael-i | Hi everyone. After moving from DAHDI 2.2.0.2 to 2.2.1, some custom drivers (GPL'd not yet stable!) I'm working on stopped loading their tone zone data and /dev/dahdi/transcode is no longer appearing. I saw the refactor on tonezones' ioctl in DAHDI but other than that am clueless what to change in my code. Any pointers? |
| 18:52.08 | *** join/#asterisk-dev korihor (~korihor@201.210.226.98) |
| 18:53.10 | seanbright | The_Boy_Wonder: my review brought to you by the department of redundancy department |
| 18:53.23 | seanbright | i need to read what i write more carefully before clicking "submit" |
| 18:59.33 | Kobaz | heh |
| 18:59.35 | Kobaz | mmm |
| 18:59.45 | Kobaz | so i noticed that app_stack.c is missing a StackPeek() |
| 19:00.27 | kpfleming | we don't allow peeking. it's not nice :-) |
| 19:00.41 | seanbright | kpfleming: so it looks like you guys need to a hire a .net developer |
| 19:00.45 | seanbright | *cough* |
| 19:00.55 | kpfleming | that would be a incorrect conclusion |
| 19:01.03 | seanbright | ah well |
| 19:01.07 | Kobaz | don't allow? |
| 19:01.08 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 19:01.15 | Kobaz | i just wrote a StackPeek()... it's really nifty |
| 19:01.28 | kpfleming | Kobaz: it was a joke |
| 19:01.31 | Kobaz | hehe |
| 19:01.35 | Kobaz | just making sure |
| 19:01.37 | kpfleming | sorry, i guess english is not your native language |
| 19:01.40 | Kobaz | it is |
| 19:01.51 | kpfleming | oh. then i'm sorry again :-) |
| 19:01.53 | Kobaz | heh |
| 19:02.18 | Kobaz | well I was talking to Qwell a bit ago, and he was giving me some do's and dont's of dialplan apps |
| 19:02.19 | seanbright | is there a StackPush? |
| 19:02.24 | Kobaz | seanbright: nope |
| 19:02.31 | Qwell | was I? |
| 19:02.33 | Kobaz | there's a StackPop() |
| 19:02.40 | Qwell | that doesn't seem like me at all |
| 19:02.42 | Kobaz | oh |
| 19:02.44 | Kobaz | maybe it was someone else |
| 19:02.49 | seanbright | i don't think the intent of app_stack is to be a stack data structure |
| 19:02.53 | seanbright | though i might be wrong |
| 19:02.59 | Kobaz | because i wrote a EXPORT function |
| 19:03.06 | Kobaz | that can overwrite any channel variable |
| 19:03.10 | seanbright | i think it's supposed to be like "stack frame" |
| 19:03.18 | Kobaz | and i guess it wasn't Qwell.. but someone didn't like that |
| 19:03.23 | Kobaz | saying channels shouldn't mess with other channels |
| 19:03.39 | seanbright | if someone didn't like it and they were clear about it, then that narrows the list down considerably |
| 19:03.42 | Kobaz | but i diagree, i think you should be able to do anything to anything |
| 19:03.43 | Kobaz | haha |
| 19:03.43 | Qwell | that isn't quite what I said |
| 19:03.44 | Kobaz | yeah i know |
| 19:03.54 | Kobaz | shouldn't mess with the internals of other channels |
| 19:04.12 | Qwell | also not what I said :D |
| 19:04.28 | Kobaz | well someone said something about something |
| 19:04.36 | Qwell | This is true |
| 19:04.40 | Kobaz | yeap |
| 19:04.42 | Kobaz | so we agree on something |
| 19:08.28 | Kobaz | anyways.... i had two ideas... one was EXPORT... which i already wrote... and another was to be able to change GROUP() assignments of other channels (in dialplan) |
| 19:09.11 | Kobaz | i'm a big fan of allowing users/developers to do anything any which way, and if they have problems... well... they shouldn't be monkeying with other channels if they aren't prepared for it |
| 19:10.48 | seanbright | the GROUP() thing is still in review, right? |
| 19:10.52 | Kobaz | yeah |
| 19:11.00 | Kobaz | i did one resubmit with fixes |
| 19:11.02 | Kobaz | still need to do more |
| 19:11.06 | seanbright | gotcha |
| 19:11.17 | seanbright | i like the idea |
| 19:11.21 | seanbright | for what it's worth |
| 19:11.24 | Kobaz | once yeah |
| 19:11.33 | Kobaz | I've used it for at least three projects now |
| 19:11.51 | seanbright | i also agree with russellb that you shouldn't expose the linked list directly |
| 19:11.51 | Kobaz | otherwise I would have had to use DB or something, and have all kinds of horrible hooks everywhere for cleanup |
| 19:11.57 | Kobaz | yeah, that's fine |
| 19:11.58 | seanbright | do you know about function pointers and all that jazz? |
| 19:12.03 | Kobaz | i'll change that to an itterator |
| 19:12.06 | Kobaz | yeah |
| 19:12.12 | Kobaz | i've been coding c for 15+ years |
| 19:12.16 | seanbright | ah, good. |
| 19:13.07 | Kobaz | all i did was model the existing style of the access functions |
| 19:13.32 | seanbright | yeah, except you need to access it from another compilation unit |
| 19:13.39 | Kobaz | but yeah, since it's a new addition, it should be in the new style... ast2 objects and everything |
| 19:13.44 | seanbright | which required using the functions |
| 19:13.50 | seanbright | right |
| 19:13.53 | seanbright | ok, i'm going to lunch finally |
| 19:13.56 | Kobaz | k |
| 19:13.58 | Kobaz | have fun |
| 19:14.40 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 19:17.33 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:20.16 | Kobaz | the problem is... with the cost per port... it's sometimes almost as expensive as rewrireing and getting ip phones |
| 19:20.19 | Kobaz | er |
| 19:20.21 | Kobaz | wrong chan |
| 19:33.23 | *** join/#asterisk-dev |Rain| (rain@ev.il.net) |
| 19:51.07 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 20:10.17 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 20:10.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:17.19 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:41.31 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 20:42.58 | *** join/#asterisk-dev elguero (~elguero@ns1.nashuacs.com) |
| 20:45.40 | leifmadsen | huh... I think someone changed the formatting on ENUMLOOKUP() to add a new option between two existing options |
| 20:46.21 | leifmadsen | no idea how long ago... this could have been years ago, but an example I was looking at didn't have the record# option listed, and noticed that I needed an extra comma to skip that field |
| 20:46.30 | leifmadsen | <random_find /> |
| 20:46.59 | kpfleming | yes, there was a big change to ENUMLOOKUP and DUNDILOOKUP to allow for iterating over the results of the lookup |
| 20:47.43 | leifmadsen | aye, that makes sense, and there is ENUMQUERY and ENUMRESULT for that as well. Just seemed like bad form to add the record# field in the middle of existing fields :) |
| 20:47.57 | leifmadsen | it going onto the end would have been the ideal |
| 20:48.09 | leifmadsen | oh well, now I found the reason my ENUMLOOKUP didn't work |
| 20:52.53 | |Rain| | can ao2_link() link an the same object into a container more than once? |
| 20:57.30 | seanbright | hmm |
| 20:58.13 | seanbright | yes |
| 20:58.44 | seanbright | it would just end up in the same bucket |
| 20:59.11 | seanbright | |Rain|: ^^^^ |
| 21:01.01 | |Rain| | hash bucket? |
| 21:01.52 | |Rain| | I think that explains the behavior I'm seeing |
| 21:01.55 | seanbright | yes |
| 21:02.00 | |Rain| | k, thank you! |
| 21:02.21 | |Rain| | I wish this bug was easier to reproduce :/ |
| 21:03.27 | LauPro | i put my rain in a waterton |
| 21:07.45 | Kobaz | hey, back to the topic of stacks |
| 21:08.10 | Kobaz | so... since there's a StackPop()... and i just finished writing StackPeek()... i'm gonna write a StackPush() |
| 21:08.18 | Kobaz | which i do actually need |
| 21:08.33 | Kobaz | that would be acceptable in trunk... right? |
| 21:13.34 | seanbright | you realize that StackPop is not a general purpose stack function, right? |
| 21:13.51 | seanbright | or app, rather. |
| 21:16.59 | Kobaz | hmm |
| 21:17.07 | Kobaz | it's just for gosub and stuff |
| 21:17.09 | Kobaz | right? |
| 21:17.30 | seanbright | yeah |
| 21:17.41 | Kobaz | yeah, that's what i thought, and that's what it seems |
| 21:17.45 | Kobaz | here's the situation |
| 21:17.49 | seanbright | ok, go with god then. |
| 21:18.35 | Kobaz | i have an agi script that runs some stuff... doesn't matter what. If a certain condition is met, the channel that's running the agi is Redirect'ed to somewhere else |
| 21:18.54 | Kobaz | so, after the Redirect, I want to be able to return to the caller |
| 21:19.47 | Kobaz | so... you have a gosub(foo) context foo { agi(...); timeout_label: dostuff()... return() } |
| 21:20.02 | Kobaz | so while in the agi... i need a way to rip the call out of the agi... and put it into timeout_label... which i've done |
| 21:20.33 | Kobaz | and then time_label is just a label in context fooo. and then i want to return to the caller (the next line after gosub(foo)) |
| 21:21.49 | Kobaz | so, i've accomplished this with my StackPeek(), save the caller info... run the agi... jump back to context foo... and then Goto(the saved caller) |
| 21:21.53 | Kobaz | but this only works for one level |
| 21:24.18 | Kobaz | if you store the stack... restore the stack... and return()... it's like nothing changed |
| 21:26.11 | JunK-Y | The_Boy_Wonder: regarding https://issues.asterisk.org/view.php?id=16475, can you clarify me the goal of the C option? |
| 21:30.57 | The_Boy_Wonder | JunK-Y: i have no idea what the goal of the C option is good for. i know what it does but i don't understand its use |
| 21:52.38 | Corydon76-dig | Kobaz: Umm, why not just do a pbx_exec(gosub) ? |
| 21:54.37 | Corydon76-dig | Kobaz: same as running the AGI GOSUB command... |
| 21:55.58 | Corydon76-dig | JunK-Y: the purpose of it is to make Polycom (and other various phones) not mark the call as "missed". |
| 21:57.12 | Kobaz | Corydon76-dig: because the agi is currently executing something |
| 21:57.37 | Kobaz | Corydon76-dig: and agi is currently executing MusicOnHold... and I have another process that says... "hey, i need to send you somewhere else" |
| 21:57.48 | Kobaz | but... i want to retain the gosub stack |
| 21:58.52 | Corydon76-dig | Right, so in the same way that you're interrupting that application, just execute the AGI GOSUB command |
| 21:59.29 | Corydon76-dig | Does everything for you, you don't need to create some weird stack commands to do it for you |
| 21:59.49 | Kobaz | but how would you make it bail from musiconhold |
| 22:00.24 | Corydon76-dig | I'd use the AbsoluteTimeout flag |
| 22:00.54 | Kobaz | hmm... what's that? |
| 22:00.59 | Kobaz | that's not in musiconhold |
| 22:01.16 | Corydon76-dig | It's a type of hangup that will make ast_check_hangup return true |
| 22:01.46 | tzafrir_laptop | just in case somebody's actually interested (and I know this is not the right place, but still) |
| 22:02.01 | Corydon76-dig | Then intercept in AGI, kill the flag, do your bidness, and return to MOH when finished |
| 22:02.08 | Kobaz | i would call Hangup on the channel? with a specific cause code? |
| 22:02.16 | tzafrir_laptop | anybody cares about iaxclient? It'll being removed from Debian soon, probably |
| 22:02.21 | Corydon76-dig | No, not calling Hangup |
| 22:02.34 | Kobaz | i'm missing something... how do you set this AbsoluteTimeout flag |
| 22:02.55 | tzafrir_laptop | (mainly due to being unmaintained) |
| 22:03.01 | Corydon76-dig | It's a SoftHangup code, not a Hangup cause |
| 22:03.09 | Kobaz | tzafrir_laptop: kiax2 is much better, but that's also unmaintained |
| 22:03.11 | Kobaz | okay |
| 22:03.29 | tzafrir_laptop | Kobaz, does it build? |
| 22:03.34 | Kobaz | tzafrir_laptop: it used to |
| 22:03.42 | Kobaz | but the real question is |
| 22:03.44 | Kobaz | does it blend? |
| 22:03.57 | Corydon76-dig | Kobaz: or, for that matter, define a different softhangup code for this purpose |
| 22:04.14 | Kobaz | Corydon76-dig: i don't see that in any SoftHangup() options |
| 22:04.25 | Corydon76-dig | We're only using 7 of the possible 32 codes |
| 22:04.28 | Kobaz | i'm still missing something... is there a way to trigger this flag from the AMI or dialplan? |
| 22:04.41 | Corydon76-dig | Kobaz: nope, gotta happen in C |
| 22:04.45 | Kobaz | okay |
| 22:05.18 | Kobaz | so what you're saying is, if you set the AbsoluteTimeout flag (which lives somewhere that's not been mentioned)... then whatever dialplan app is executing will bail? |
| 22:05.30 | Corydon76-dig | ast_softhangup(channel, AST_SOFTHANGUP_AGI_INTERRUPT) for example |
| 22:05.39 | Corydon76-dig | the flag lives in channel.h |
| 22:05.42 | Kobaz | k |
| 22:06.27 | Kobaz | allrightey... i'm almost getting it |
| 22:06.59 | Kobaz | soooo... there needs to be a new soft hangup code, that sets AbsoluteTimeout... which will make the dialplan app bail |
| 22:07.44 | Corydon76-dig | Forget absolutetimeout. It was an example of a flag that uses softhangup to get what it needs done, without actually hanging up the channel |
| 22:08.23 | Kobaz | oh okay |
| 22:08.30 | Corydon76-dig | Define a new softhangup code, set it via some command, intercept the code in AGI, clear it, call the GOSUB AGI command |
| 22:08.31 | Kobaz | okay i see |
| 22:08.35 | Kobaz | hehe |
| 22:08.45 | Kobaz | okay all that timeout flag stuff was confusing me |
| 22:09.37 | Corydon76-dig | The idea is not to mess with the gosub stack code, but use a facility to do what you want |
| 22:09.42 | Kobaz | yeah |
| 22:09.49 | Kobaz | well, there's already a StackPop() |
| 22:09.58 | Corydon76-dig | Yes, but that's for other purposes |
| 22:09.59 | Kobaz | i figure, there's no harm in a StackPush() |
| 22:10.06 | Corydon76-dig | Yes, there is |
| 22:10.09 | Kobaz | hehe |
| 22:10.18 | Kobaz | what other stuff uses StackPop ? |
| 22:10.42 | Corydon76-dig | StackPop allows you not to return, because you've found some error where a return would be inappropriate |
| 22:10.58 | Corydon76-dig | It's for error handling |
| 22:11.10 | Kobaz | ah |
| 22:11.12 | Corydon76-dig | That's the whole purpose of it |
| 22:11.55 | Kobaz | i still think stackpeek and stackpush are quite useful.. i'm sure there's plenty of things other people could do with them |
| 22:12.06 | Kobaz | i already finished the peek |
| 22:12.20 | Corydon76-dig | There's already a dialplan function called PEEK |
| 22:12.38 | Kobaz | Command 'core show function PEEK' failed. |
| 22:12.41 | Corydon76-dig | LOCAL_PEEK |
| 22:12.41 | Kobaz | trunk? |
| 22:13.02 | Corydon76-dig | Not sure why Leif wanted it, but it's there |
| 22:13.20 | Kobaz | oh yeah |
| 22:13.26 | Kobaz | that's a pretty standard scripting language function |
| 22:13.27 | Corydon76-dig | Allows you to look at variables that have been masked out by LOCAL() |
| 22:13.31 | Kobaz | yeah |
| 22:13.40 | leifmadsen | ya, I think I was using it for a client, and I was trying to solve a problem, but I'm not sure that ever really solved the problem |
| 22:13.53 | leifmadsen | :) |
| 22:13.59 | Kobaz | yeah local_peek doesnt get the caller information though |
| 22:14.13 | leifmadsen | I think I was using it to try and determine the state of call recording on another channel |
| 22:14.16 | Kobaz | my StackPeek() returns the context,exten,priority of each stack lebvel |
| 22:14.17 | Corydon76-dig | caller information shouldn't matter |
| 22:14.37 | Kobaz | it depends what you're writing |
| 22:14.53 | Corydon76-dig | and in any case, since all it does is returning information, an application is inappropriate for the task |
| 22:14.58 | Kobaz | it's useful for writing say... custom stack tracing |
| 22:15.10 | Corydon76-dig | Okay, for debugging |
| 22:15.12 | Kobaz | well it sets dialplan variables |
| 22:15.25 | Corydon76-dig | AUUGGGGH! Don't do that! |
| 22:15.27 | Kobaz | STACK_CONTEXT |
| 22:15.28 | Kobaz | hehe |
| 22:15.31 | Kobaz | okay |
| 22:15.38 | Corydon76-dig | Implicit setting of variables is very, very bad |
| 22:15.47 | Kobaz | well it's in the documentation for it |
| 22:15.50 | Kobaz | okay... i' |
| 22:15.56 | Kobaz | i'll convert it to a func |
| 22:16.42 | Corydon76-dig | something like STACK_PEEK(level,name), where level is a number and name is context, extension, priority, or all |
| 22:17.03 | Kobaz | but stack_peek only returns on value |
| 22:17.17 | Kobaz | oh yeah, i gues you could just call it multiple times for each type |
| 22:17.30 | Corydon76-dig | You could have all return all values, comma-separated |
| 22:17.32 | Kobaz | i like get it all at once, style functions |
| 22:18.03 | Kobaz | but then you run into data content issues... what if your context name has a comma in it |
| 22:18.33 | Corydon76-dig | I prefer functions that grab each piece of information as you need it, so you can embed functions in expressions, rather than trying to rip apart expressions afterwards |
| 22:18.52 | Kobaz | yeah |
| 22:19.00 | Kobaz | for straight dialplan that makes sense |
| 22:19.02 | Corydon76-dig | If your context name has a comma in it, you're going to have OTHER problems |
| 22:19.25 | Kobaz | hehe |
| 22:20.02 | leifmadsen | commas in context names? ahhhh! |
| 22:20.09 | Kobaz | i'm just saying... heh |
| 22:20.27 | Corydon76-dig | Leif will have you shot if you put a comma in a context name |
| 22:20.28 | Kobaz | if commas are bad in context names, then that should be an error reported in context definition |
| 22:20.47 | Kobaz | if it isn't already |
| 22:20.50 | Kobaz | i haven't tried |
| 22:21.06 | Corydon76-dig | It isn't, but we prefer giving people enough rope to hang themselves |
| 22:21.26 | Kobaz | and then some |
| 22:21.59 | leifmadsen | I've never seen an example using a comma in a context name :) |
| 22:22.10 | Corydon76-dig | If you do something stupid, don't be surprised if something doesn't work |
| 22:22.15 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-140-104.lns3.bat.bigpond.net.au) |
| 22:22.36 | Kobaz | yeap |
| 22:23.04 | Corydon76-dig | If you intentionally do something stupid while on other people's time, don't be surprised that they want to kill you |
| 22:23.12 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-140-104.lns3.bat.bigpond.net.au) |
| 22:24.02 | Kobaz | hehe |
| 22:31.53 | kpfleming | someone was asking about the purpose of the app_queue() C option? |
| 22:33.40 | seanbright | points at JunK-Y |
| 22:40.06 | Kobaz | yeah i saw that option, and i'm like eh? |
| 22:40.48 | kpfleming | its purpose is to indicate to the queue member devices when outgoing calls time out that they should not include the call in their 'missed call' list or similar |
| 22:41.37 | Kobaz | oh, interesting |
| 22:42.09 | Kobaz | is there something like that for Dial ? |
| 22:42.34 | Kobaz | like, dial 6 devices.. and one picks up... and now you have 5 phones showing missed calls |
| 22:43.25 | Kobaz | oh yeah, there's a c option |
| 22:54.44 | seanbright | wow... thou shalt remember the semi after struct definitions |
| 22:56.57 | Qwell | seanbright: yes.. errors are not very obvious |
| 22:57.09 | Qwell | ran into that tuesday |
| 22:58.33 | seanbright | me too |
| 22:58.36 | seanbright | just figured it out |
| 22:58.37 | seanbright | heh |
| 23:18.47 | Kobaz | seanbright: heh, i was just having the same issue |
| 23:33.15 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 23:33.15 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 23:35.28 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |