| 00:50.45 | *** join/#asterisk-dev moy (~moy@74.12.98.225) |
| 01:19.14 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 03:06.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-120-51.ptld.qwest.net) |
| 03:09.47 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 03:09.47 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 03:25.24 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-117-183.ptld.qwest.net) |
| 05:10.44 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-110-194.ptld.qwest.net) |
| 05:45.06 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 05:45.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:47.59 | *** join/#asterisk-dev _schmidts (~schmidts@lmlo.sil.at) |
| 05:48.32 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 05:48.38 | schmidts | good morning |
| 05:50.15 | snuff-work | hello.. more astdb testing today? |
| 06:01.24 | schmidts | nope i think russell solved it yesterday |
| 06:01.45 | schmidts | have a look at https://reviewboard.asterisk.org/r/825/ |
| 06:11.57 | schmidts | hmmm testing the normal astdb with my app, cause a int overflow :( i think we could call this a slow process :D |
| 06:12.27 | schmidts | means more than 2 billion usecs :D |
| 06:22.28 | snuff-work | :) |
| 06:24.39 | schmidts | 26 ms against 240 mins whould that be a good improvment? |
| 06:26.13 | schmidts | sorry not ms. its 26 sec against 240 mins but still good in my opinion ;) |
| 06:29.28 | schmidts | am i allowd to give this review request a ship it state or does only the digium developers are allowed for this? |
| 06:31.13 | snuff-work | there is no reason u cannot.. |
| 06:34.03 | schmidts | thank you ;) |
| 07:03.35 | *** join/#asterisk-dev xiaclo (~xiaclo@142.167.247.23) |
| 07:10.23 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 07:10.43 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:10.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.41 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:24.03 | Corydon76-dig | Yeah, you're welcome to give a "Ship It!" if you think it's merited. |
| 07:31.03 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:49.22 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 10:51.32 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.11) |
| 11:05.39 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 11:05.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:33.40 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:41.43 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 11:49.47 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:49.47 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:04.38 | *** join/#asterisk-dev OlafsenM (~mark.olaf@193.198.31.85) |
| 12:04.46 | *** part/#asterisk-dev OlafsenM (~mark.olaf@193.198.31.85) |
| 12:10.28 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:44.35 | *** join/#asterisk-dev Justman (~just@78.108.73.46) |
| 13:03.09 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:20.31 | *** join/#asterisk-dev paravoid (~paravoid@zebra.cslab.ece.ntua.gr) |
| 13:23.53 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 13:23.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:33.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:33.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:36.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:36.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:55.00 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:14.24 | *** join/#asterisk-dev JerJer (~PhatJ@asterisk/original-h323-guy/JerJer) |
| 14:15.02 | JerJer | is anyone currently working on the TLS support in chan_sip ? |
| 14:16.32 | JerJer | found an interesting 'bug' when a network connection starts flapping. |
| 14:19.55 | russellb | nobody is actively working on it AFAIK |
| 14:23.07 | oej | JerJer: Good to see you! |
| 14:26.31 | anonymouz666 | russellb: would be possible to run devstate on queue members? ex.: all members are free (no active calls) until the app_queue delivery the first call to the first member and get the 486 BUSY (the ATA is offhook)... so at this point app_queue sets the devstate for this member as BUSY |
| 14:28.12 | oej | properly configured, that member should be busy already... ;-) |
| 14:28.39 | oej | It would be hard to set a state based on the response. When do you want to reset this state to something else? |
| 14:30.12 | anonymouz666 | well, that's a good question. |
| 14:34.52 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.97) |
| 14:39.35 | russellb | yes, what oej said. :-) A better question is why Asterisk doesn't already know it's busy. |
| 14:40.13 | russellb | oej: re: timezone configuration, isn't it specified in RFC 3261 that the time is in GMT? |
| 14:41.11 | anonymouz666 | if the operator is using a softphone they can just press the DND button or using ATA they just put as offhook the headset |
| 14:41.43 | russellb | anonymouz666: then how would asterisk know that it's not busy anymore, and that it should start trying to send calls there again? |
| 14:42.08 | *** join/#asterisk-dev CunningPike (~CunningPi@S01060014bf81366b.vc.shawcable.net) |
| 14:42.41 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:44.51 | anonymouz666 | I don't know... maybe a better approach would be to use the chan_agent |
| 14:45.31 | putnopvut | Yeah, DND has always been problematic because SIP phones don't actually send any external signaling when DND is started and stopped. |
| 14:45.53 | kpfleming | some of them can, if enabled, via PUBLISH |
| 14:46.11 | russellb | now in that case, we could do something about it :-) |
| 14:46.22 | putnopvut | ooh, and Asterisk 1.8 has a framework for implementing an event state compositor for such events. |
| 14:46.27 | russellb | yes! |
| 14:46.34 | putnopvut | neato |
| 14:46.40 | anonymouz666 | SUBSCRIBE/NOTIFY could also be used to monitor the busy state ? |
| 14:48.10 | putnopvut | Possibly. The difference is that the dialog-info events that Asterisk currently listens for are used to change extension state for an extension. As long as an appropriate hint is set up in the dialplan, this could work, I do believe. |
| 14:51.45 | anonymouz666 | so that could be used then to reset the state of queue member :D as both methods are widely supported by the UAc's |
| 14:52.59 | putnopvut | I *think* so, but I haven't looked at queue or device state code in a looong time :) |
| 14:53.11 | oej | russellb: You are right at the same time as you're on the wrong path... I want my SIP phone to always use greek indications for disa and playtones in asterisk |
| 14:54.11 | oej | SIP phones DOES send PUBLISH, but Asterisk doesn't listen... So we could potentially support DND on phones that does send a notification. SNOM phones can do a lot of things that will work for asterisk in that case too... |
| 14:54.24 | oej | Right, kpfleming already said that |
| 14:54.57 | oej | :-) |
| 14:55.24 | file | I wonder if you could do setvar=CHANNEL(tonezone)=tonezone for greek in the sip.conf |
| 14:55.25 | oej | russellb: You haven't been able to configure this on a per-device setting before. Only in CHANNEL() |
| 14:55.43 | oej | file: That would not work with the SIPPEER function, which I need too |
| 14:55.44 | russellb | ohhhh, _that_ timezone :-) |
| 14:55.46 | russellb | 3 |
| 14:56.12 | russellb | oh, and tonezone, not timezone |
| 14:56.15 | russellb | gosh, i was way off |
| 14:56.15 | oej | Right |
| 14:56.22 | oej | Welcome back! |
| 14:56.26 | russellb | thanks :-p |
| 14:56.43 | russellb | I guess you can do setvar=CHANNEL(tonezone)=se |
| 14:56.47 | russellb | but that's a hack |
| 14:56.48 | oej | russellb: If you have a minute, can you quickly review my reviewboard thing with res_agi? It's simple. We discussed it yesterday |
| 14:56.56 | russellb | yes, will look now |
| 14:57.05 | schmidts | russell have you seen my report? |
| 14:57.07 | oej | ...and I could not use SIPPEER to check tonezone for a peer with SETVAR |
| 14:57.24 | russellb | good point, like i said, it's a hack |
| 14:57.26 | oej | schmidts: You are in the russellb queue, position 33 |
| 14:57.27 | russellb | schmidts: I did, yes :-) |
| 14:57.41 | oej | That queue moved quickly :-) |
| 14:58.14 | russellb | oej: I'm not sure what that patch changes ... if res == -1, it will already return NULL |
| 14:58.33 | russellb | maybe you meant to put it before ast_filehelper() ? |
| 14:59.18 | russellb | schmidts: was your test with 1/2 second or 1 second? |
| 14:59.20 | oej | Hmm. It was late in the night... I'll check... Sorry ;-) |
| 14:59.32 | russellb | oej: np, that's what peer reviews are for! |
| 14:59.44 | schmidts | both, the result i posted was with 1/2 sec |
| 14:59.53 | russellb | okay. |
| 15:00.06 | oej | Hmm. Absolutely - it should go before ast_filehelper. Hmmm... |
| 15:00.15 | oej | Ok, later tonight with another interesting bug ;-) |
| 15:00.17 | oej | bye for now. |
| 15:00.20 | russellb | bye |
| 15:01.04 | schmidts | cya olle |
| 15:02.06 | schmidts | ok see you guys later ;) |
| 15:20.44 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 15:21.43 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 15:27.00 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:27.00 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:41.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:41.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:41.58 | *** join/#asterisk-dev datacompboy (~opera@l49-3-84.cn.ru) |
| 15:42.00 | datacompboy | Hi! Anybody knows where in zaptel source decode of input number over PRI line is done? |
| 15:42.44 | Kobaz | datacompboy: libpri |
| 15:43.06 | Kobaz | and you should be using dahdi |
| 15:43.30 | datacompboy | Kobaz: i know, but that quite old system, i just need to patch decode so it replace 00 in nuber with "B" |
| 15:43.38 | datacompboy | can't do full upgrade there |
| 15:44.51 | datacompboy | q931_get_number -- found, thanks! |
| 15:51.09 | datacompboy | < [70 10 a1 32 31 31 37 33 36 33 33 30 35 00 30 30 30 36] |
| 15:51.10 | datacompboy | < Called Number (len=18) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '2117363305B0006' ] |
| 15:51.26 | datacompboy | Yo! Working. Kobaz, you saves me one life, thanks :D |
| 15:51.35 | Kobaz | i take visa and mastercard |
| 15:51.41 | Kobaz | :P |
| 15:52.45 | datacompboy | Kobaz: well, when i'll send it -- i'll transfer to you :D |
| 15:54.50 | *** part/#asterisk-dev datacompboy (~opera@l49-3-84.cn.ru) |
| 15:57.11 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-116-148.ptld.qwest.net) |
| 16:06.32 | Qwell | So, because of a conversation in #-bugs, I've realized that using patches from downloads.asterisk.org to upgrade to a version where the configure script (or any file marked as binary) will fail. Miserably. I have 0 ideas on how to fix that... Thoughts? |
| 16:14.22 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-110.ptld.qwest.net) |
| 16:14.36 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-nfyntbobotlywquv) |
| 16:16.16 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-usiedbcrszeztawt) |
| 16:23.38 | *** join/#asterisk-dev elguero (~miguel323@65.214.33.61) |
| 16:36.49 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 16:36.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:42.59 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-tcexybsglembcdve) |
| 16:45.32 | *** join/#asterisk-dev erotavlas_turbo (~chatzilla@host171-79-dynamic.59-82-r.retail.telecomitalia.it) |
| 16:46.19 | erotavlas_turbo | I have a question about ast_channel structure. In version 1.6.2 the structure ast_channel has a member called ast_callerID, the new version 1.8 hasn't this structure |
| 16:51.48 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 17:05.50 | *** topic/#asterisk-dev by leifmadsen -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. -=- AstriDevCon 2010, October 29, sign up here: http://bit.ly/astridevcon2010 |
| 17:06.02 | erotavlas_turbo | Nobody can help me? |
| 17:06.16 | *** join/#asterisk-dev javierj (~quassel@190.146.192.22) |
| 17:06.18 | leifmadsen | it's lunch time in Huntsville... |
| 17:08.54 | Kobaz | erotavlas_turbo: asterisk-dev mailing list |
| 17:10.27 | erotavlas_turbo | it's dinner time in Siena |
| 17:11.09 | Kobaz | it's lunch time on the east coast |
| 17:13.40 | erotavlas_turbo | Ok |
| 17:15.28 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 17:16.41 | pabelanger | It's hammer time! |
| 17:16.44 | pabelanger | http://www.youtube.com/watch?v=2c4L4CPfQY8 |
| 17:16.48 | Kobaz | it's miller time! |
| 17:16.56 | Kobaz | although, i hate beer |
| 17:34.17 | *** join/#asterisk-dev ccesario_ (~ccesario@189-29-32-71-ac.cpe.vivax.com.br) |
| 17:44.12 | Kobaz | okay so.. what do you guys think of a 'prepared dial' |
| 17:44.33 | Kobaz | or augmenting ChanIsAvail to actually do something with the AVAILCHAN that it sets |
| 17:45.40 | Kobaz | ChanIsAvail(SIP/foo); NoOp(${AVAILCHAN}); Dial(SIP/foo) You're running on SIP/202-00000132 AVAILCHAN=SIP/201-00000133 and when you Dial().. you get SIP/201-00000134 |
| 17:46.06 | Kobaz | i can't think of any way to get the channel that's going to be used, before the Dial() |
| 17:46.50 | Kobaz | you can store the channel in a pickup macro... but that's only when the other side actually picks up... what if you want the channel before that? and don't want to do AMI shenanagins |
| 17:47.00 | file | you can't. |
| 17:51.31 | Kobaz | hmm |
| 17:51.42 | Kobaz | well anything is possible |
| 17:51.51 | Kobaz | it depends how much code you want to tear through |
| 17:52.10 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 17:52.13 | file | so you'd have to write something that requested a channel, and then also modify app_dial to be aware of that and use that instead of creating its own |
| 17:52.25 | file | so that requesting and calling become two separate steps in the dialplan |
| 17:52.56 | Kobaz | exactly |
| 17:53.16 | file | you might be able to use the macro/whatever options to Dial as well... it would be able to get the channel name at that time... but that's not before... |
| 17:53.17 | Kobaz | PrepareDial DoPreparedDial |
| 17:53.43 | Kobaz | having something like that that would solve all kinds of quirks I have, and possible race conditions |
| 17:54.00 | Kobaz | i'll do some experiments |
| 17:56.19 | Kobaz | it could be simplified to DialRequestChan or something... and then pass in an option to Dial... to use the channel that was made |
| 18:02.12 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 18:02.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:45.50 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 19:00.47 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 19:00.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:07.45 | *** join/#asterisk-dev ahowlader (~Adnan@119.30.38.77) |
| 19:17.55 | *** join/#asterisk-dev elguero (~miguel323@65.214.33.61) |
| 19:28.34 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 19:37.04 | *** join/#asterisk-dev ccesario_ (~ccesario@187.75.139.188) |
| 19:44.39 | *** join/#asterisk-dev schmidts (563b1f02@gateway/web/freenode/ip.86.59.31.2) |
| 19:44.43 | schmidts | hello all |
| 19:45.45 | schmidts | i have thought about the patch to the chan_sip do_monitor function and read again what the ao2_t_callback does |
| 19:46.50 | schmidts | is it right that this ao2_t_callback iterate through EACH sip dialog, does the callback and if the response is right, this would be count as a match |
| 19:48.18 | kpfleming | schmidts: yes |
| 19:48.41 | kpfleming | it iterates over every item in the container it is passed... i can't say whether that is every sip dialog or not |
| 19:50.22 | schmidts | if its called with these flags: OBJ_UNLINK | OBJ_NODATA | OBJ_MULTIPLE like the callback from do_monitor to delete dialogs which has the needdestroy flag set, i think it would |
| 19:50.41 | kpfleming | what container is it being called on? |
| 19:50.57 | schmidts | dialogs |
| 19:51.07 | schmidts | sorry have forgot about that |
| 19:51.15 | kpfleming | then yes.. it will iterate over every dialog, calling the callback function for each one, unless the callback function tells it to stop |
| 19:51.37 | kpfleming | this is why i mentioned the other day that probably 'needdestroy' dialogs need to be put into a separate container, rather than just flagged |
| 19:51.57 | schmidts | this callback function (dialog_needdestroy) doesnt return anything else than 0 |
| 19:52.29 | schmidts | yes i remember ;) cause of this i was reading again what really happens now to improve |
| 19:53.15 | schmidts | i dont know much about containers. is it possible for a dialog to be placed into 2 containers? |
| 19:53.53 | schmidts | forget this question, there is no need for this, if it has the need_destroy flag we just wait to kill it ;) |
| 19:54.38 | kpfleming | yes, it can be in more than one container |
| 19:54.50 | kpfleming | peers, for example, are in two containers, one hashed by name, and the other hashed by IP address |
| 19:55.33 | schmidts | ok i see |
| 19:56.05 | kpfleming | so instead of setting the 'needdestroy' flag on a dialog, you'd instead place a pointer to it into the dialogs_needdestroy container |
| 19:56.42 | schmidts | so what we need, would be another container , if a dialog gets its needdestroy flag, remove it from the dialogs container and place it into the dialogs2die container |
| 19:56.44 | schmidts | :D |
| 19:57.12 | schmidts | this was like thought translation ;) |
| 19:57.50 | kpfleming | actually, you'd leave it in the dialogs container too |
| 19:57.57 | kpfleming | because other operations might need to find it there |
| 19:59.35 | schmidts | they are unlinked (dialog_unlink_all func) from the container if the dialog_needdestroy function is called. so the only time another operation could access this dialog would be in between setting the flag and the next call of this callback |
| 20:00.16 | kpfleming | well, that doesn't make any sense, because if they aren't in the container after the flag is set, the callback loop in do_monitor won't be able to find them |
| 20:00.54 | schmidts | no, what i mean is the callback function which is called from do_monitor unlinks the dialog |
| 20:01.01 | kpfleming | right |
| 20:01.09 | *** join/#asterisk-dev elguero (~miguel323@65.214.33.61) |
| 20:01.19 | kpfleming | but what i am saying is that long before that, some other code set the 'needdestroy' flag on the dialog, right? |
| 20:01.36 | schmidts | yes |
| 20:01.52 | kpfleming | so instead of doing that, that code should place a pointer to the dialog into the new container for dialogs that need to be destroyed |
| 20:02.12 | schmidts | ok |
| 20:02.17 | kpfleming | and in the do_monitor loop, it only has to iterate over the dialogs in that smaller container, removing them from both that container and the real dialogs container |
| 20:02.33 | kpfleming | and if there are no dialogs that need to be destroyed, it will be very fast |
| 20:02.53 | schmidts | i will give it a try ;) |
| 20:02.59 | kpfleming | great! |
| 20:03.19 | kpfleming | really, any operation in chan_sip that iterates over the entire dialogs container is a case where there could be a performance improvement possible |
| 20:04.17 | schmidts | like handle_subscribe ;) |
| 20:04.41 | kpfleming | right |
| 20:05.14 | schmidts | maybe i had a new reviewrequest for this tomorrow |
| 20:06.23 | schmidts | but right now, my wife looks angry at me cause i sit again in front of doxygen and try to understand the code ;) cya later |
| 20:07.03 | anonymouz666 | how can MeetMe works without chan_dahdi loaded? |
| 20:07.41 | anonymouz666 | if the mixing is done in dahdi... |
| 20:08.46 | kpfleming | it doesn't use chan_dahdi it uses dahdi directly |
| 20:08.53 | kpfleming | chan_dahdi and dahdi are not the same thing |
| 20:09.24 | anonymouz666 | I thought that the only way to use dahdi was through chan_dahdi |
| 20:09.45 | anonymouz666 | at asterisk level |
| 20:09.49 | kpfleming | no. dahdi is a completely usable set of code by itself. chan_dahdi uses it. |
| 20:10.56 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 20:10.56 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:14.28 | *** join/#asterisk-dev elguero (~miguel323@65.214.33.61) |
| 20:33.32 | *** join/#asterisk-dev ahowlader (Adnan@180.234.39.137) |
| 21:04.44 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 21:21.49 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 21:28.19 | *** join/#asterisk-dev Sipster_ (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 21:36.41 | *** join/#asterisk-dev bspidel (~IceChat7@63.134.128.4) |
| 21:37.12 | bspidel | anybody working on app_queue. |
| 21:37.36 | Qwell | You're going to need to be a little more specific. |
| 21:38.15 | kpfleming | i was considering putting it through a wood chipper... does that count? |
| 21:38.37 | jsmith | kpfleming: Oooh... Can I help? |
| 21:38.46 | Qwell | I've got a chan_agent here that can go in next.. |
| 21:38.58 | bspidel | I am tasked with fixing a bug where a member gets 2 calls if part of multiple queues |
| 21:39.00 | jsmith | kpfleming: I'll bring some gasoline and help you start a bonfire with the chips :-) |
| 21:39.28 | jsmith | bspidel: That should only happen if the call-state mechanism isn't recognizing that they're already on another call |
| 21:40.41 | bspidel | the member gets assigned to 2 calls within 10 microseconds so I don't think the state is set soon enough |
| 21:40.44 | jsmith | If they're SIP devices, make sure you using callcounter (newer versions) or call-limit (older versions) turned on in sip.conf |
| 21:41.01 | kpfleming | if ti happens that fast, state won't help |
| 21:41.56 | bspidel | I have a system with 400 members and 50 queues. Each member is in multiple queues and I see it dozens of times daily |
| 21:42.18 | bspidel | I have peaks of 400 simultaneous calls |
| 21:43.06 | bspidel | I was thinking state is not granular enough but don't know where to put structure that is global enough |
| 21:43.55 | bspidel | how will call counter help and yes they are sip devices |
| 21:44.33 | bspidel | if i dont enable autofill calls will backup too long |
| 21:45.36 | kpfleming | if you set the call limit for each sip device to '1', then app_queue will get back busy when it tries to send a second call to that device. that's not based on device state, it happens in chan_sip. |
| 21:46.04 | bspidel | cool let me check that out |
| 21:53.53 | schmidts | someone said fast enough? |
| 21:54.32 | kpfleming | schmidts: aren't you supposed to be asleep? |
| 21:54.52 | schmidts | nope put wife into bed and got time for coding :D |
| 21:55.33 | bspidel | if I use call-limit will it restrict outgoing calls by member? |
| 21:56.04 | schmidts | but if you are still here kevin, should i call dialog_unlink_all for both containers? |
| 21:56.09 | *** join/#asterisk-dev mpe (~mpe@75-101-82-64.static.dsltransport.net) |
| 21:56.45 | kpfleming | schmidts: yes, you'll need to remove it from the needdestroy container as well, otherwise the dialog won't be actually destroyed |
| 21:56.55 | kpfleming | bspidel: yes, it will, i believe |
| 21:57.18 | schmidts | even if its unref at both unlink functions? |
| 21:57.34 | bspidel | when my member gets bridged he needs to be able to make calls |
| 21:57.58 | kpfleming | schmidts: i don't understand that question |
| 21:59.19 | schmidts | sorry ;) as far as i understand the container, there is a refer value which is count 1 up if its in use and count 1 down if its free |
| 22:00.19 | kpfleming | that is correct |
| 22:00.32 | kpfleming | but if you don't remove it from both containers, the object's reference count will never reach zero |
| 22:01.28 | schmidts | i know, but for dialogs there is a function called dialog_unlink_all which delete or unref the dialog from every place (like scheduler ....) |
| 22:02.25 | schmidts | sorry i am slow today, you allready give me the answer ;) the reference counter has to reach zero to be deleted ;) |
| 22:02.30 | schmidts | got it |
| 22:04.52 | *** join/#asterisk-dev JunK-Y (~junky@64.15.77.94) |
| 22:06.01 | JunK-Y | kpfleming: why you asked to remove the memmove in Review 912 exactly? |
| 22:06.09 | bspidel | any way to limit incoming but not outgoing calls? |
| 22:06.44 | JunK-Y | use the GROUP() for incoming, but not outgoing? |
| 22:11.26 | kpfleming | JunK-Y: because there's no point in copying the data over and over again just to parse it |
| 22:12.50 | bspidel | JunK-Y, kplfeming: thanks for help |
| 22:12.59 | *** part/#asterisk-dev bspidel (~IceChat7@63.134.128.4) |
| 22:14.58 | JunK-Y | thanks |
| 22:28.29 | pabelanger | waves to JunK-Y |
| 22:32.31 | schmidts | any developer left? |
| 22:33.00 | schmidts | maybe iam blind but i cant find the ao2_container_alloc call for the dialogs container in chan_sip.c |
| 22:36.10 | bbryant | schmidts: line 28371 in trunk |
| 22:36.20 | bbryant | it's actually ao2_t_container_alloc and it's at the top of load_module |
| 22:36.51 | schmidts | aaaaaahhhhh i always trap into this ao2_TTTTT_ missing :D |
| 22:36.54 | schmidts | thank you very much |
| 22:36.59 | bbryant | no problem |
| 22:44.02 | schmidts | wow nice allready working as expected ;) |
| 22:44.41 | schmidts | i have created a own container (yep now allocated) to hold the dialogs which needdestroy so there is no need to iterate through all dialogs anymore |
| 22:46.21 | schmidts | the ao2 callback now only tooks 18 usec if the list is empty and around 200 usec with 300 sip dialogs |
| 22:46.47 | schmidts | the old method was around 2 ms even there was not a single dialog to unlink |
| 22:48.37 | bbryant | nice |
| 22:50.18 | schmidts | i just have found something which in my opinion should not be launched on every loop of do_monitor |
| 22:51.21 | schmidts | the check_rtp_timeout function was in the ao2_callback of all dialogs |
| 22:53.16 | schmidts | should this not being checked in the rtp thread? or will the thread for this call be locked, waiting for the next incoming package? |
| 23:01.33 | schmidts | maybe another container holding only the dialogs which has a rtptimeout set would be a solution ;) |
| 23:03.25 | *** join/#asterisk-dev felipe_ (~felipe@my.nada.kth.se) |
| 23:03.37 | bbryant | schmidts: it returns after only after a few comparisons if it doesn't have an rtp timeout |
| 23:04.01 | bbryant | doesn't seem like it would be a big performance hit |
| 23:05.59 | schmidts | the callback function itself, yes but you have to iterate through ALL dialogs and does this callback |
| 23:06.39 | schmidts | that was the cause why i have build this solution with a seperate container for the dialogs with needdestroy flag ;) |
| 23:08.03 | bbryant | ah, ok |
| 23:08.21 | bbryant | well I'm out for the day, cya |
| 23:08.28 | schmidts | good idea ;) |
| 23:08.29 | schmidts | cya |
| 23:20.24 | *** join/#asterisk-dev mpe (~mpe@75-101-82-64.static.dsltransport.net) |
| 23:26.50 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 23:51.56 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |