| 00:27.15 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:27.15 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 01:19.22 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 01:46.14 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.50.214) |
| 01:48.41 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 01:48.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:52.08 | *** join/#asterisk-dev bklang_ (~bklang@tesla.alkaloid.net) |
| 02:49.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 02:49.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:12.58 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-182.ptld.qwest.net) |
| 04:03.16 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 05:32.26 | *** part/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 05:39.08 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 05:39.08 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:35.43 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.11) |
| 07:52.59 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 07:53.02 | schmidts | good morngin |
| 07:53.22 | schmidts | s/morngin/morning/ |
| 08:03.22 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.11) |
| 08:28.21 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:41.14 | *** join/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 09:11.58 | schmidts | anybody out there? |
| 09:12.12 | schmidts | i have a question about rtptimeout, trpholdtimeout and rtpkeepalive |
| 09:12.34 | schmidts | is it possible that this values would change during a call or specially during a dialog exists? |
| 09:16.44 | schmidts | *silence* :D |
| 10:23.03 | jlpedrosa | Hi all, anyone have a couple of spare minutes? |
| 10:23.22 | *** join/#asterisk-dev ahowlader (~Adnan@180.234.49.161) |
| 10:23.25 | schmidts | hello |
| 10:23.34 | schmidts | depends on your problem i would say ;) |
| 10:24.05 | jlpedrosa | i'd need to know if there's any similar function to pbx_exec, but instead passing a channel, pass a bridge |
| 10:24.57 | schmidts | ok, why? |
| 10:25.20 | jlpedrosa | I need to implement dynamic features that's executes on both channels, instead of self or peer |
| 10:25.48 | schmidts | hmmm interesting |
| 10:26.10 | schmidts | what kind of features? does these functions have to run on both channels at the same time? |
| 10:26.43 | jlpedrosa | ie Playback(tt-monkeys) :) |
| 10:26.51 | jlpedrosa | yep |
| 10:27.19 | jlpedrosa | i tried to put two pbx_exec, but, it executes them in secuence... |
| 10:27.37 | jlpedrosa | and i don't think launching threads would be a nice idea... |
| 10:28.24 | schmidts | the problem is, that pbx_exec just loads the app you have called and exec it. and AFAIK all apps has a channel as parameter |
| 10:28.24 | schmidts | s/has a/has one/ |
| 10:28.39 | schmidts | infobot tooo late ;) |
| 10:28.42 | schmidts | i see |
| 10:29.26 | schmidts | i dont know if there is anything like that allready in * |
| 10:29.54 | schmidts | have you looked at the queue functions how they play a "user xy enters room" message to all members |
| 10:31.14 | jlpedrosa | ... sounds as a good start point, and other (probably very diffuclt) problem... sync the sound in both channels, it gotta be recoded with mix monitor |
| 10:33.00 | schmidts | sorry i was wrong, not queue i mean the meetme room |
| 10:34.47 | schmidts | atleast why do you dont use a meetme room for this? two channels connected to a meetme and a third where you can record or playback something |
| 10:35.33 | jlpedrosa | because I need a lot of Dial parameters |
| 10:35.56 | jlpedrosa | as call max duration, notify ringing... |
| 10:36.09 | schmidts | ok |
| 10:36.17 | schmidts | brb - afk |
| 10:36.36 | jlpedrosa | bad luck... meetme has a fd for the bridge... |
| 10:36.38 | jlpedrosa | ok, |
| 10:48.53 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:48.53 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:52.59 | schmidts | back |
| 10:53.19 | schmidts | ok than this would not work |
| 10:58.05 | snuff-home | mmm.. vmware buys suse |
| 11:12.59 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:24.47 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:24.47 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:25.23 | leifmadsen | morning all |
| 11:27.25 | schmidts | good afternoon ;) |
| 11:32.24 | snuff-home | ello leif |
| 11:32.46 | leifmadsen | snuff-home: yo! |
| 11:37.23 | snuff-home | lookin forward to the w/end? |
| 11:58.36 | leifmadsen | heck ya :) |
| 11:58.37 | leifmadsen | half day today |
| 12:43.34 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 13:15.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:15.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:58.35 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 14:09.35 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 14:31.07 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 14:35.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:35.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:39.07 | schmidts | i have a question about issue 17950 |
| 14:39.09 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_sip/Subscriptions 0017950: iterate through all ao2_sip dialogs on every subscribe is slow, and not needed reported by schmidts https://issues.asterisk.org/view.php?id=17950 |
| 14:39.36 | schmidts | why does it have a target version if my review has not got a ship it ? |
| 14:41.37 | russellb | what is it set to? |
| 14:41.49 | russellb | 1.10 ? |
| 14:41.51 | schmidts | 1.6.2.15 |
| 14:41.56 | russellb | oh. |
| 14:42.22 | russellb | well leifmadsen is going through all of the issues we put in our current sprint |
| 14:42.32 | russellb | we (digium software development) work in 4 week development iterations |
| 14:42.33 | schmidts | ok i see ;) |
| 14:42.37 | russellb | we just did our planning meeting yesterday |
| 14:42.42 | russellb | and that one is assigned to me to review :-) |
| 14:42.54 | leifmadsen | indeed |
| 14:43.13 | leifmadsen | target version means, "targeted for that release" |
| 14:43.18 | russellb | the idea being that hopefully I can work with you to get it done here soon |
| 14:43.23 | leifmadsen | sometimes I mess up though and assign features where they shouldn't :) |
| 14:43.27 | leifmadsen | aye |
| 14:43.41 | russellb | this one is one those crazy ones where it's tough to decide |
| 14:43.42 | schmidts | i see ;) |
| 14:43.44 | leifmadsen | in particular, that one should probably not be assigned to a version :) |
| 14:43.51 | russellb | it's sort of a bug, sort of a performance enhancement :-) |
| 14:44.01 | leifmadsen | ya, would that go into 1.6.2? |
| 14:44.11 | leifmadsen | it looks like it might be dangerous enough to not :) |
| 14:44.15 | leifmadsen | however that is your call |
| 14:44.45 | leifmadsen | I saw, "Major" and "1.6.2 branch" which is why it got assigned to 1.6.2.15 |
| 14:44.56 | leifmadsen | which is the version we'll tag after this sprint |
| 14:45.04 | leifmadsen | (1.6.2.14 is being tagged today or Monday) |
| 14:45.13 | leifmadsen | s/1.6.2.14/1.6.2.14-rc1/ |
| 14:45.56 | schmidts | ok ;) |
| 14:53.27 | Kobaz | how hard would it be to add 'pickup macros' for a channel that's making progress |
| 14:55.55 | schmidts | impossible |
| 14:56.05 | schmidts | what are pickup macros? |
| 14:56.14 | russellb | schmidts: lol.. |
| 14:56.30 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 14:56.46 | schmidts | this is the second best answer you can give to a question, directly after NO |
| 14:57.08 | Kobaz | schmidts: the macro/gosub you can run when the endpoint of a dial answer()'s |
| 14:57.29 | schmidts | aaaahh you mean the M option on dial? |
| 14:57.33 | Kobaz | the autoservice type stuff |
| 14:57.34 | russellb | so you want macro/gosub on a channel when it gets a progress indication? |
| 14:57.34 | Kobaz | M/U |
| 14:57.35 | Kobaz | yeah |
| 14:57.46 | russellb | not hard at all |
| 14:57.50 | schmidts | hmmm impossible |
| 14:57.52 | schmidts | :D |
| 14:57.53 | Kobaz | oh, nice |
| 14:57.55 | russellb | schmidts: haha.. |
| 14:57.59 | Kobaz | heh |
| 14:58.26 | Kobaz | i'm talking to an adtran t1->sip which is giving me progress indication when opening up a channel on a e&m wink t1 |
| 14:58.30 | schmidts | let me guess another dial parameter? where are we by now with them, something like Z66 i guess |
| 14:58.43 | russellb | pretty much. |
| 14:59.03 | Kobaz | and i get progress, and dialtone on early media |
| 14:59.10 | russellb | or it could also be done with channel variables ... |
| 14:59.16 | Kobaz | but i cant get ast to pulse out digits, because it doesnt get an answer from the adtran, just progress |
| 14:59.34 | russellb | Kobaz: if you read app_dial, you should find a big loop that's watching the outbound channel(s) |
| 14:59.46 | russellb | you just need to cook into the case statement for AST_CONTROL_PROGRESS |
| 14:59.49 | Kobaz | k |
| 14:59.55 | russellb | and do the same code as the macro/gosub handling |
| 15:00.01 | Kobaz | yheah |
| 15:00.02 | russellb | probably the gosub one ... |
| 15:00.05 | Kobaz | that's autoservice... right? |
| 15:00.08 | russellb | no |
| 15:00.17 | Kobaz | yeah, no point in adding macro handling, which is old |
| 15:00.18 | Kobaz | oh |
| 15:00.25 | russellb | autoservice is involved, but it's a side effect, really.. |
| 15:00.42 | russellb | autoservice needs to be started on the inbound channel while you do it |
| 15:00.55 | Kobaz | k |
| 15:01.02 | russellb | you say, "Hey autoservice, take care of this channel for me, I need to go do something else for a bit and won't be able to keep up with its incoming frames. kthx" |
| 15:01.12 | russellb | that's autoservice :-) |
| 15:01.19 | leifmadsen | phew, an hour later and mantis is updated |
| 15:01.48 | schmidts | thanks to leif for another 300 new mails in inbox |
| 15:01.55 | Kobaz | ah okay |
| 15:01.56 | leifmadsen | :D |
| 15:01.56 | schmidts | from mantis ;) |
| 15:02.03 | leifmadsen | welcome to my world |
| 15:02.07 | leifmadsen | I get about 100 a day |
| 15:02.30 | schmidts | Kobaz Row 981 in app_dial.c |
| 15:02.39 | Kobaz | row... hehe |
| 15:02.46 | Kobaz | schmidts: trunk? |
| 15:02.53 | schmidts | 1.6.2 branch |
| 15:02.54 | schmidts | mom |
| 15:02.55 | Kobaz | k |
| 15:03.12 | Kobaz | i'm developing on 1.6.0 still |
| 15:03.17 | schmidts | Row 1217 on trunk :D |
| 15:03.48 | Kobaz | i can't switch to 1.6.2 until i find out the moh corruption problem that i get |
| 15:04.10 | schmidts | to less power of 1.6.2 wait for my patches *gg* |
| 15:05.42 | Kobaz | which ones? |
| 15:06.44 | schmidts | review 901 but allmost 917 and atleast the astdb patch from russell |
| 15:07.07 | schmidts | 901 is only for subscribe handling but with 917 and the astdb patch, you will have M U C H more cpu power free |
| 15:07.25 | russellb | <3 |
| 15:08.37 | schmidts | now i can go home for WE *HAPPY* |
| 15:09.06 | schmidts | maybe if david will have a look at my latest version i will have some work again, but for now its enough |
| 15:09.21 | schmidts | have a nice evening, and nice WE too |
| 15:09.58 | schmidts | cya |
| 15:33.10 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:33.10 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:02.18 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:58.35 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 16:58.36 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:59.35 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 17:29.49 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 19:20.56 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-182.ptld.qwest.net) |
| 19:20.57 | sruffell | russellb: :) dahdi-linux mirror wedged? |
| 19:28.05 | Kobaz | mmm, cheese wedge |
| 19:38.06 | russellb | sruffell: >_< |
| 19:39.37 | sruffell | Should I have up git-svn dcommit and slow things down? Or is the stress testing valuable? |
| 19:39.37 | russellb | sruffell: fixed |
| 19:39.45 | sruffell | s/have/fix/ |
| 19:39.57 | sruffell | thx |
| 19:40.11 | russellb | it seems to pretty much only be a problem with the dahdi repo, so it has _got_ to be the rapid commits from doing a git svn dcommit ... |
| 19:40.30 | russellb | if a quick hack to put a second in between each commit isn't a big deal, it'd be nice i guess |
| 19:40.36 | russellb | although fixing it isn't that hard, either |
| 19:41.05 | sruffell | I mean...I guess it's conceivable that it could happen on the other repos if people happened to commit close to one another... |
| 19:41.06 | russellb | obviously it shouldn't be breaking, but i don't care enough to figure it out |
| 19:41.09 | russellb | true |
| 19:41.16 | russellb | i guess the issue is just pushed |
| 19:41.36 | sruffell | ok...but I'll slow it down until you ask me to speed it back up again. |
| 19:44.04 | kpfleming | russellb: this problem could also be solved by making the svnsync process for that repo not run in the background, which will slow down commits to that repo... but if they are going to be artificially slowed down anyway, that might not matter |
| 19:46.16 | russellb | kpfleming: i tried doing that already |
| 19:46.20 | russellb | still breaks, dunno why |
| 19:46.23 | russellb | unless i didn't do it right :-p |
| 19:47.01 | kpfleming | i suspect that might be the case... because if the commit waits until the sync is done, there shouldn't be a way for the lock to get messed up |
| 19:47.25 | russellb | if [ "${REPOS}" = "dahdi" ] ; then |
| 19:47.25 | russellb | do_post_commit |
| 19:47.25 | russellb | else |
| 19:47.25 | russellb | do_post_commit & |
| 19:47.25 | russellb | fi |
| 19:47.40 | kpfleming | it might be backgrounded in the script itself too |
| 19:47.47 | russellb | checked, it is not |
| 19:47.54 | kpfleming | oh... and REPOS is likely supposed to be a full path |
| 19:48.00 | russellb | fail, yes |
| 19:48.05 | russellb | >_< |
| 19:48.18 | russellb | got it confused with a variable we also have in there, REPO, which is `basename ${REPOS}` |
| 19:48.32 | sruffell | hope that I don't have to slow down git-svn glimmers... |
| 19:48.45 | russellb | sruffell: no need to slow it down |
| 19:48.54 | kpfleming | it will get slowed down some, but only as much as is necessary, not an arbitrary amount |
| 19:48.55 | russellb | i think it's fixed for real now |
| 19:49.01 | sruffell | cool |
| 19:49.14 | russellb | though your commits will go slower anyway, but imposed by the server |
| 19:49.20 | russellb | it will blocked until it finishes mirroring each rev |
| 19:50.29 | russellb | let's just migrate DAHDI to git this afternoon :-p |
| 19:51.05 | sruffell | I'm interested in what the list of preconditions for that are..... |
| 19:51.19 | sruffell | ...but I'm sure I'll hear about that from kpfleming when the time is right. |
| 19:51.21 | kpfleming | time and time and some more time |
| 19:52.14 | sruffell | speaking of that...any problem with committing the change that makes a GIT-<hash> version directly into SVN? |
| 19:52.26 | sruffell | that would be the last thing I install a post-checkout hook for... |
| 19:53.11 | kpfleming | i don't understand that question |
| 19:53.35 | sruffell | currently I install http://github.com/sruffell/dahdi-linux/blob/externals/post-checkout when I'm using a git repo for my development. If I edited the makeversion script, I wouldn't have to install that. |
| 19:53.54 | kpfleming | oh, you are talking about make_version |
| 19:53.58 | sruffell | ahh.yeah |
| 19:54.03 | kpfleming | your question didn't mention that at all :-) |
| 19:54.18 | sruffell | bad question. |
| 19:54.24 | kpfleming | it would not offend me if our make_version script was upgraded to support Git hashes, no |
| 19:54.35 | sruffell | ok, cool. |
| 19:57.16 | Corydon76-dig | Oh, come on. That's blatantly offensive. ;-) |
| 19:57.38 | Corydon76-dig | It's a practical fix, though. :-) |
| 20:06.05 | *** join/#asterisk-dev ccesario_ (~ccesario@189-29-53-173-ac.cpe.vivax.com.br) |
| 20:22.09 | *** join/#asterisk-dev schmidts (~sst@86.59.31.4) |
| 20:22.17 | schmidts | hello all |
| 20:27.02 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 20:48.35 | schmidts | args i didnt know the boy wonder is david vossel :( |
| 20:48.49 | schmidts | so i have could talked to him directly |
| 20:49.10 | russellb | heh, yep |
| 20:49.23 | russellb | but now he's gone for the weekend |
| 20:49.52 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 20:55.24 | schmidts | good to know |
| 20:58.07 | Corydon76-dig | Probably not for the entire weekend. We all are rather addicted to our work. |
| 21:00.35 | schmidts | me too :D |
| 21:05.06 | schmidts | is kevin still here? probably he is cause he answered my last comment ;) |
| 21:07.47 | Corydon76-dig | I believe he is intentionally not monitoring the channel, in order to be able to concentrate |
| 21:08.04 | schmidts | ok |
| 21:11.25 | kpfleming | no, i'm lurking here too |
| 21:12.23 | schmidts | nothing to hurry about it wont tell your boss :D |
| 21:13.00 | Corydon76-dig | Kevin's boss doesn't log onto IRC |
| 21:13.23 | Corydon76-dig | At least, I've never seen him on here |
| 21:13.49 | schmidts | i can understand this from his point ;) |
| 21:13.55 | schmidts | kevin i have a question about your last mail, are you sure this will work, or do you just think this could work ;) |
| 21:14.23 | kpfleming | it should work |
| 21:14.40 | kpfleming | but the loop will have to keep checking the socket to see if there is data available on it, otherwise it will block |
| 21:15.02 | kpfleming | unless the socket has been set to O_NONBLOCK... i don't know if we do that or not for the SIP UDP socket |
| 21:15.21 | schmidts | nope its not set to nonblocking |
| 21:16.08 | kpfleming | well, then the code would have to loop reading a packet, processing it, and then checking the socket to see if more data is available before doing all the other non-socket-reading stuff |
| 21:16.27 | schmidts | i have tried this, by just looping back to polling until the timeout is really over, but in my opinion this works not as good as it could be |
| 21:16.45 | kpfleming | why not? |
| 21:18.44 | schmidts | cause the timeout would never be exactly, cause the callback itself needs also time, and if there are events set between now and the timeout which is given to ast_io_wait they would stay there without being runned |
| 21:19.01 | kpfleming | no, you would not give a timeout to ast_io_wait |
| 21:19.27 | kpfleming | you would call it with a zero timeout, if it returns telling you there is nothing to read, then you wait for the next scheduled entry or for a packet to arrive like the loop does now |
| 21:20.58 | schmidts | the loop now doesnt wait until the next event if a packet is received meanwhile, it just loops allover ( also doing the ao2 callback) |
| 21:21.19 | kpfleming | that's my point |
| 21:21.35 | kpfleming | here's the logic: at the top of the loop, you wait for the next scheduler entry *or* a packet to arrive |
| 21:21.54 | schmidts | i see |
| 21:21.56 | kpfleming | if no packet arrives, you run the scheduler queue, do all the rest of the timeout processing and stuff, and go back to the top of the loop |
| 21:22.56 | kpfleming | if a packet *does* arrive, you read it, process it, and immediately check to see if another packet is available. if there is no packet available, then you run the rest of the stuff as normal . if a second packet has arrived, read it, process it,and keep doing that untill there are no more packets to read. |
| 21:23.37 | schmidts | without a brake condition? |
| 21:23.41 | kpfleming | that way, if the loop wakes up because there are four packets to read, they all get read and processed before the next run through the timeout containers, needdestroy containers and the scheduler queue |
| 21:24.04 | kpfleming | it might need a reasonable limit... say no more than six packets in a row or somethign, to ensure the scheduler doesn't get starved |
| 21:24.13 | schmidts | ;) |
| 21:24.33 | schmidts | but we are not talking about the timeout container and needdestroy container, they are fast as hell |
| 21:24.42 | kpfleming | that's true |
| 21:24.53 | schmidts | the problem i described happens with the normal callback with iterate through all dialogs |
| 21:25.08 | kpfleming | you just want to achieve some level of balance between reading incoming packets and processing the scheduler queue |
| 21:25.11 | kpfleming | right |
| 21:25.15 | schmidts | right |
| 21:25.52 | kpfleming | and as david said, this change is really too invasive for 1.6.2, unless there is a very critical need for it. the inability to handle 10K registrations is not that need... nobody expects 1.6.2 to be able to handle that. |
| 21:26.28 | schmidts | 10k was just on my testsystem, my production hosted pbx server handles now 3300 peers with 1.2.40 without any problem |
| 21:26.38 | schmidts | i made a upgrade to 1.6.2 and kabumm ;) |
| 21:26.41 | kpfleming | and as i told you before, that was not intentional |
| 21:26.52 | kpfleming | so we don't consider that a regression, you just got very lucky |
| 21:26.58 | schmidts | i remember |
| 21:28.14 | schmidts | ok then i will change the patch from 1.6.2 to trunk version, as far as i have seen this should only affect the row number but not the structure itself |
| 21:29.51 | schmidts | is there a chance that this chances come into trunk? |
| 21:30.22 | kpfleming | absolutely |
| 21:30.23 | schmidts | s/chances/changes/ |
| 21:30.37 | schmidts | ok ;) |
| 21:31.58 | schmidts | i will think about your idea of balancing incoming reading and waiting, this could result in a more stable sip handling |
| 21:33.14 | schmidts | thanks for your time, many things are much clearer by now |
| 21:33.48 | kpfleming | great! |
| 21:37.42 | schmidts | i wish you a nice weekend, i think i have some work todo now ;) |
| 22:07.17 | *** join/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 22:24.02 | *** join/#asterisk-dev felipe_ (~felipe@my.nada.kth.se) |
| 22:37.37 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 22:59.02 | schmidts | anyone left on this friday evening? |
| 22:59.21 | kpfleming | nope |
| 22:59.22 | schmidts | i maybe found a bug in trunk with ast_softhangup_nolock |
| 22:59.25 | schmidts | :D |
| 22:59.49 | russellb | i may be physically here, but my brain left a few hours ago |
| 22:59.52 | schmidts | i 1.6.2 this function cause a bye on this channel. in trunk i didnt see it |
| 23:00.50 | schmidts | atleast the function itself hasnt changed from 1.6.2 to trunk |
| 23:03.59 | schmidts | maybe this is expacted to happen but i dont think so |
| 23:06.44 | kpfleming | umm... if the channel is hung up, it will send a BYE to its connected SIP endpoint |
| 23:07.30 | schmidts | http://pastebin.com/1bCC3eCi |
| 23:07.40 | schmidts | this is with enabled sip debug |
| 23:09.01 | kpfleming | beyond my interest level at this point :-) |
| 23:09.17 | schmidts | i understand this :D |
| 23:22.55 | schmidts | i think its time for me to go to bed ;) |
| 23:23.25 | schmidts | cya all |
| 23:50.46 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |