| 03:25.35 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 03:28.25 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-182.ptld.qwest.net) |
| 05:49.19 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 05:49.23 | schmidts | good morning |
| 06:05.02 | snuff-work | hello |
| 06:13.56 | schmidts | how are you? everything running as expected ;) |
| 06:14.50 | snuff-work | mm.. bit of a slow day. |
| 06:15.03 | snuff-work | given up on my enum sort for now.. |
| 06:15.47 | snuff-work | for some reason it can't sort all rec's properly.. |
| 06:16.40 | schmidts | what are your sort conditions? just name or ips or ?? |
| 06:17.32 | snuff-work | just order and prio |
| 06:21.02 | schmidts | ok, i see so if there are more than one NAPTR entry in dns you want to order them, right? |
| 06:21.56 | snuff-work | yer i show u example via pbin.. |
| 06:22.31 | schmidts | k |
| 06:26.24 | snuff-work | http://pastebin.ca/1946384 |
| 06:27.16 | snuff-work | basically the ones that match both order and prio should be next to one another but they are not.. least in my sort |
| 06:28.14 | snuff-work | so if i do a enum request for all under a certain number which has say 5-8 entries.. |
| 06:28.46 | snuff-work | and the dns gives them back in a diff order than the one specified.. fail on sorting in enum.c |
| 06:29.14 | schmidts | ok i see |
| 06:29.54 | schmidts | dns allways give back a unsorted result, which is expected, cause you normally want to spread things up by different dns entries |
| 06:30.11 | snuff-work | the dns response has both the prio and order numbers |
| 06:30.39 | snuff-work | so we asterisk should be able to put it back in proper order |
| 06:32.06 | schmidts | yes ;) |
| 06:34.55 | snuff-work | gives better example dns entries |
| 06:35.04 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 06:37.16 | snuff-work | http://pastebin.ca/1946391 |
| 06:37.19 | schmidts | :D |
| 06:38.41 | schmidts | so we have the collum under NAPTR which is the sort, next is prio right? |
| 06:39.09 | schmidts | and last would be data |
| 06:39.35 | snuff-work | yer |
| 06:40.26 | snuff-work | now current enum sort.. can't even order that correctly.. it always swapping http with email |
| 06:40.41 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 06:40.48 | schmidts | i havent looked at the code, but how are these entries retrieved from dns, and inserted into the array? |
| 06:40.49 | schmidts | ok |
| 06:41.24 | snuff-work | it just does a naptr request like dig would.. as far as i know.. |
| 06:41.41 | snuff-work | aka dig 4.3.2.1.e164.arpa naptr |
| 06:41.49 | schmidts | ok |
| 06:41.53 | snuff-work | would spam u all of those records |
| 06:42.38 | schmidts | my idea would be to use a linklist and sort it by process, so you do the dns query and on every answer look at the sort order and prio in this link list and enter it directly where it should go at, and when you are finished with retrieving, just put it in a array in right order |
| 06:43.12 | snuff-work | well that's what it does.. makes a array like my 1st one.. then sorts |
| 06:43.21 | schmidts | on which dns server are these entries? |
| 06:43.31 | snuff-work | my own bind |
| 06:43.39 | schmidts | ok :D |
| 06:44.13 | snuff-work | i will be giving a copy similar to this to russ etc to put on asterisktest.com |
| 06:45.34 | schmidts | in which file is enum lookup? main/enum.c i guess ;) |
| 06:45.43 | snuff-work | yer line 540 or so |
| 06:50.24 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 06:50.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:50.42 | schmidts | morning olle |
| 06:57.19 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 07:02.40 | schmidts | snuff i cant see where it does a check if its a E2U+sip or E2U+tel or mailto or whatever |
| 07:03.20 | schmidts | there is a check on row 464, but i doesnt see if there is a rating about sip, tel or something else |
| 07:11.28 | snuff-work | mmm 870 |
| 07:11.37 | snuff-work | approx |
| 07:12.00 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:13.58 | schmidts | ok ;) thats after the retrieving, but do we need something like web or mail in the array? |
| 07:14.14 | schmidts | why not drop this? |
| 07:15.03 | snuff-work | that 470 stuff is for retrieving sub records.. or being more specific.. |
| 07:15.42 | snuff-work | aka what u'd normally want to do rather than getting every record for a number.. |
| 07:17.35 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 07:18.05 | schmidts | i doesnt get it by now |
| 07:18.51 | schmidts | the parse_naptr is called with every resolut row of the naptr query and after parsing things around the result is stored into the array |
| 07:19.46 | schmidts | then this array should be sorted |
| 07:20.29 | snuff-work | the array should be sorted.. but its not always correct.. |
| 07:21.07 | schmidts | cause there is a problem with the e2u+web for example, as you said |
| 07:27.54 | schmidts | i still didnt see where the tech is checked :( there is nothing in the sort about the tech |
| 07:28.18 | snuff-work | it doesn't matter about the 'tech's |
| 07:28.25 | snuff-work | it matters only on order and prio.. |
| 07:28.34 | snuff-work | that's all it should be sorting by.. and it does |
| 07:28.40 | snuff-work | but just gets it wrong |
| 07:29.13 | schmidts | ok, sorry missunderstood ;) |
| 07:32.01 | snuff-work | ;) |
| 07:33.09 | schmidts | what exactly is wrong, the sort order or the pref? |
| 07:35.04 | snuff-work | the sortorder that comes out.. is not correct according to the 'pref' number |
| 07:44.13 | schmidts | the naptr.order are the values of the first column after NAPTR right? |
| 07:47.03 | *** join/#asterisk-dev frawd (~francois@201.Red-79-159-79.staticIP.rima-tde.net) |
| 07:47.26 | snuff-work | yer |
| 07:48.44 | schmidts | and you try this with the example you have pasted ? |
| 07:49.48 | schmidts | cause if yes, the if condition which sorts the pref is never called, but it still should be right :( |
| 07:58.13 | snuff-work | yes.. |
| 07:59.31 | snuff-work | atm i want to replace its sort |
| 08:06.52 | *** join/#asterisk-dev frawd (~francois@201.Red-79-159-79.staticIP.rima-tde.net) |
| 08:07.32 | schmidts | why not do this right in the parse_naptr instead of later? |
| 08:11.22 | oej | Morning schmidts |
| 08:12.21 | oej | You talking about ENUM and NAPTR? |
| 08:12.29 | schmidts | morning ;) yes |
| 08:12.30 | oej | Our support needs a lot of love, in addition to SRV. |
| 08:16.40 | schmidts | :D |
| 08:20.54 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 09:04.17 | *** join/#asterisk-dev Justman (~just@78.108.73.46) |
| 10:01.43 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 10:31.48 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 10:33.23 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 10:33.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:34.18 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 10:38.54 | *** join/#asterisk-dev mpe (~mpe@109.70.54.7) |
| 10:51.58 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:08.18 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:21.45 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:21.45 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:43.17 | *** join/#asterisk-dev asilva (~structz@gandalf.ai.unesp.br) |
| 11:48.04 | *** join/#asterisk-dev leif[mobile] (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:48.04 | *** mode/#asterisk-dev [+o leif[mobile]] by ChanServ |
| 12:03.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:03.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:15.23 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:24.39 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:24.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:02.04 | *** join/#asterisk-dev oej_ (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 13:02.04 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:23.33 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:43.53 | dwayne | anyone know if rmudgett hangs out in here? Not sure if this is a bug, but q931.c defines TRANS_MODE_PACKET as 0x40 while AT&T TR41459 section 3.6.5.4 indicates that it should be 0 |
| 13:55.53 | *** join/#asterisk-dev crowbar7 (~JKLOBUCAR@12.2.84.2) |
| 13:56.47 | *** join/#asterisk-dev zerohalo (~zerohalo@173-13-92-17-NewEngland.hfc.comcastbusiness.net) |
| 14:06.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:06.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:10.44 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:10.44 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:12.47 | kpfleming | dwayne: he does not |
| 14:14.13 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:14.13 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:37.15 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 14:37.49 | russellb | dwayne: if you post to the -dev list he'll see it |
| 15:02.02 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 15:04.28 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:42.55 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:42.55 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:01.31 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-182.ptld.qwest.net) |
| 16:15.33 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 16:17.19 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 16:21.42 | *** join/#asterisk-dev espiceland (~erin@nat/digium/x-ueoclifmathsoatu) |
| 16:26.08 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:26.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:02.48 | *** join/#asterisk-dev ahowlader (~Adnan@119.30.39.49) |
| 17:04.13 | *** join/#asterisk-dev frawd (~francois@201.Red-79-159-79.staticIP.rima-tde.net) |
| 17:20.03 | *** join/#asterisk-dev vrban (~chatzilla@p508963D5.dip.t-dialin.net) |
| 17:22.14 | vrban | hello, i have a good gdb output, where manager.c (1.8-beta5) crash when calling pthread_kill, see https://issues.asterisk.org/file_download.php?file_id=27323&type=bug |
| 17:51.17 | *** join/#asterisk-dev vrban (~chatzilla@p508963D5.dip.t-dialin.net) |
| 17:55.23 | Kobaz | allrightey, lets see if this works |
| 18:08.03 | Kobaz | vrban: post the bug info on issues.asterisk.org |
| 18:22.13 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 18:22.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:28.53 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 18:32.38 | Kobaz | hmm |
| 18:32.47 | Kobaz | what funtion should i use to run a gosub on an already set up channel |
| 18:32.52 | Kobaz | apparently it's not ast_pbx_run |
| 18:33.02 | Kobaz | [Sep 22 14:31:44] WARNING[31439]: pbx.c:3661 __ast_pbx_run: SIP/intellasoft-tipton-local-00000006 already has PBX structure?? |
| 18:34.14 | kpfleming | ast_async_goto or something like that |
| 18:34.25 | kpfleming | or maybe there is an async_gosub... i'm not sure |
| 18:34.32 | Kobaz | k |
| 18:34.48 | Kobaz | i'm adding my predial executor thing |
| 18:34.57 | Kobaz | i just kind of copy and pasted the code that handles U() |
| 18:35.03 | Kobaz | for Dial() |
| 18:35.11 | Kobaz | it does a: res = pbx_exec(chan, theapp, gosub_args); |
| 18:35.18 | Kobaz | and then a ast_pbx_run_args(chan, &args); |
| 18:55.29 | Kobaz | whoops |
| 18:58.10 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 18:58.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:09.52 | Kobaz | okay that kinda works |
| 19:09.55 | Kobaz | what about a non async goto |
| 19:10.49 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 19:11.40 | Kobaz | i guess that's ast_explicit_goto*() |
| 19:21.51 | Kobaz | hmm |
| 19:21.58 | Kobaz | if i use pbx_exec it doesn't do anything |
| 19:22.06 | Kobaz | it returns 0 for success though |
| 19:28.58 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 19:45.39 | Kobaz | i think i got it |
| 19:54.21 | Corydon76-home | How gosub works is actually pretty neat |
| 20:11.01 | Kobaz | so i switched to ast_spawn_extension |
| 20:11.07 | Kobaz | that works much better |
| 20:38.05 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 21:29.09 | Kobaz | <PROTECTED> |
| 21:29.13 | Kobaz | <PROTECTED> |
| 21:29.16 | Kobaz | <PROTECTED> |
| 21:29.18 | Kobaz | how awesome is that? |
| 21:41.43 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 21:45.24 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 21:53.01 | Kobaz | sleepy wednesday eh |
| 22:22.59 | leifmadsen | Kobaz: what does I() do again? |
| 22:23.32 | Kobaz | predial |
| 22:23.52 | Kobaz | run dialplan on the newly allocated channel, before dialing the actual endpoint for that channel |
| 22:24.41 | Kobaz | see, in betweem dial, and called, you see a dialplan exec of the predial context |
| 22:26.44 | Kobaz | it runs the target on all destination channels |
| 22:26.50 | leifmadsen | interesting! |
| 22:26.54 | Kobaz | so if you did dial(sip/1&sip/2) |
| 22:26.57 | Kobaz | it would run predial on both |
| 22:27.10 | Kobaz | it's a way to get the channel that's going to be used, before it gets used |
| 22:27.16 | Kobaz | which i've needed for a very long time |
| 22:27.49 | Kobaz | i've done all kinds of roundabout hacks to get around not having that feature |
| 22:28.30 | Kobaz | this is so exciting, i can get rid of all kinds of cruft |
| 22:33.35 | dwayne | Kobaz, does it do the dial after the I() extension completes or is it in parallel ? |
| 22:34.49 | Kobaz | after |
| 22:34.49 | dwayne | oh you said "...before dialing..." |
| 22:35.05 | Kobaz | it's all in one thread |
| 22:35.36 | Kobaz | dial will call the endpoint after I finishes |
| 22:35.53 | Kobaz | I is for predIal |
| 22:35.55 | Kobaz | heh |
| 22:36.01 | Kobaz | most of the good letters are taken |
| 22:36.08 | leifmadsen | Kobaz: it'd be interesting to add the same functionality to Queue() when it checks for another caller in the queue. I'd like to run some dialplan to check with other Asterisk boxes (perhaps via DUNDi) to set the callers position in the "queue". This would be useful for a system where you want to have the same "queue" on multiple boxes. |
| 22:36.24 | leifmadsen | I haven't thought it out entirely, but I have some ideas of how it might work :) |
| 22:36.36 | leifmadsen | sounds like the same type of approach might be able to get applied |
| 22:36.41 | dwayne | yeah, I had to add a Z() namespace for something and inside Z I reused various letters that were already used for Dial |
| 22:36.42 | Kobaz | yeah |
| 22:36.45 | Kobaz | the code is pretty simple |
| 22:37.01 | leifmadsen | Kobaz: even better -- maybe I could hack something together :) |
| 22:37.09 | Kobaz | i'll post the patch to -dev |
| 22:37.13 | Kobaz | and you can have fun with it |
| 22:37.29 | leifmadsen | coolio! |
| 22:37.40 | Kobaz | i need to write a gosub parser though |
| 22:37.42 | Kobaz | and then it's done |
| 22:37.43 | leifmadsen | for now I think I will go and do something computer un-related |
| 22:37.55 | Kobaz | a lot of the parsing stuff is so spread out and duplicated in asterisk |
| 22:38.12 | Kobaz | i've centralized goto parsing |
| 22:38.16 | Kobaz | need to do gosub next |
| 22:39.14 | Kobaz | leifmadsen: that's an interesting idea for the queue to be distributed in multiple boxes |
| 22:39.22 | Kobaz | how does it do agent availability? |
| 22:39.53 | leifmadsen | Kobaz: the agent available would work with existing tools (distributed device state via OpenAIS or XMPP and database driven configuration files) |
| 22:40.13 | leifmadsen | the only part missing is the "Box A has callers 1, 3, 5, and Box B has callers 2, 4, 6" |
| 22:41.20 | Kobaz | ah okay |
| 22:41.21 | Kobaz | yeah |
| 22:41.35 | leifmadsen | Right now the first caller to each of Box A and B would be in position 1 respectively |
| 22:41.40 | Kobaz | yeah |
| 22:41.50 | leifmadsen | When the caller comes in, you need a way to dynamically control the positions across the boxes |
| 22:41.55 | Kobaz | yeah |
| 22:42.01 | leifmadsen | I think it could be handled via some clever dialplan via the right triggers |
| 22:42.05 | Kobaz | i find the Queue() app to be really limited |
| 22:42.15 | leifmadsen | or maybe even via XMPP directly |
| 22:42.28 | leifmadsen | I personally don't, but depends what you're doing I guess |
| 22:42.39 | leifmadsen | I've implemented it for several clients |
| 22:42.41 | Kobaz | heh |
| 22:43.01 | Kobaz | two years ago i tried to implement it for a client. and then wound up writing it all in dialplan |
| 22:43.15 | Kobaz | now, two years later, i have 3000 lines of perl code that handles my call queues |
| 22:43.28 | leifmadsen | heh, well a lot of things have changed in 2 years ;) |
| 22:43.38 | Kobaz | it still can't do what i need it to do |
| 22:43.55 | leifmadsen | ok, I'm out |
| 23:36.27 | *** join/#asterisk-dev frawd (~francois@47.Red-88-26-137.staticIP.rima-tde.net) |
| 23:45.50 | *** join/#asterisk-dev moy_ (~moy@bas1-toronto47-1177731709.dsl.bell.ca) |