| 00:08.17 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 01:10.35 | *** join/#asterisk-dev CcRnp (n=shishir@208.179.165.18) |
| 01:11.20 | CcRnp | can anyone tell me which version of asterisk is sable to use CEL ? or CEL still buggy ? |
| 01:23.28 | snuff-work | for CEL i think its in trunk |
| 01:23.39 | snuff-work | not in 1.6.1 or 1.6.2 |
| 01:30.21 | CcRnp | yeah its in trunk and will be available after 1.6.3 but my questionis ; Is it safe to use on production server ? |
| 01:40.51 | snuff-work | well.. try it.. technically CEL can't get too much wrong because YOU are the one that has to do the thinking on combining records |
| 01:42.30 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.230.252) |
| 02:44.13 | JunK-Y | russellb: take some pics at google complex! |
| 02:47.50 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 03:21.18 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 03:21.18 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 03:38.01 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 03:39.50 | *** join/#asterisk-dev xpot-mobile (n=xpot@70.91.210.233) |
| 05:10.39 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:10.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:55.52 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:55.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:02.58 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 06:02.58 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 06:17.59 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 07:29.10 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:47.28 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@62.90.10.53) |
| 07:47.29 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 08:38.19 | *** join/#asterisk-dev wildzero-cw (n=chatzill@p50997436.dip0.t-ipconnect.de) |
| 08:54.55 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 09:02.36 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:02.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:26.21 | oej | hello folks |
| 09:26.41 | mvanbaak | hey oej |
| 09:27.28 | oej | Missed you at Astricon, Michiel! |
| 09:27.34 | mvanbaak | I know |
| 09:27.38 | mvanbaak | I missed it as well |
| 09:28.04 | mvanbaak | but budget for it was spent on a motor license and a motorbike |
| 09:34.06 | oej | propably good for you |
| 09:34.09 | oej | :-) |
| 09:39.06 | mvanbaak | yups |
| 09:48.44 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 09:48.44 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:02.50 | oej | ello snuff! |
| 10:02.52 | oej | :-) |
| 10:03.50 | snuff-home | ello oej |
| 10:20.37 | *** join/#asterisk-dev kazaa_lite (n=msaleem@94-193-98-124.zone7.bethere.co.uk) |
| 10:31.44 | mvanbaak | 12 |
| 10:36.00 | snuff-home | ello mvanbaak :) |
| 10:36.23 | mvanbaak | hey hey |
| 10:36.55 | snuff-home | im getting closer.. |
| 10:37.08 | mvanbaak | sweet ! |
| 10:38.18 | snuff-home | i had linker issue last 2 tries.. forgot how to add somethin to ld.so.conf |
| 10:40.07 | mvanbaak | :) |
| 10:41.30 | snuff-home | after i get it to run inside *.. more work to be done.. |
| 10:41.30 | mvanbaak | will i be able to specify the expiration when adding stuff ? |
| 10:41.53 | snuff-home | well should be.. |
| 10:42.19 | mvanbaak | add(somekey, somevalue, 30) <--- will stare somevalue in somekey and expire after 30 seconds |
| 10:43.05 | snuff-home | yer.. the library supports it |
| 10:43.14 | snuff-home | shouldn't be too hard to put it together |
| 10:44.53 | snuff-home | i also see there is a version that stores sql |
| 10:45.52 | snuff-home | so u can have some kind of 'stable' version |
| 10:46.32 | mvanbaak | uhhuh |
| 10:51.01 | snuff-home | hopefully i have working get/set + expiry / mirror by monday.. |
| 10:55.40 | *** join/#asterisk-dev Grof (n=grof@89.201.165.226) |
| 11:25.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:44.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:44.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:17.06 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 12:48.18 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 13:00.12 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 13:08.38 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:08.38 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:12.35 | leifmadsen | snuff-work: ping? |
| 13:12.37 | leifmadsen | snuff-home: ping? |
| 13:13.41 | atis_work | snuff-orbit: ping? |
| 13:13.53 | leifmadsen | heh, actually nevermind, I got the answer I was looking for already |
| 13:14.51 | atis_work | leifmadsen: actually i had question for you :p |
| 13:15.09 | *** join/#asterisk-dev wildzero-cw (n=chatzill@p50997436.dip0.t-ipconnect.de) |
| 13:15.32 | atis_work | what did you mean by "appropriate status" in M16007, why "confirmed" is more appropriate than "ready for review" :) |
| 13:15.46 | leifmadsen | M16007 |
| 13:15.48 | MuffinMan | [confirmed] [Asterisk] Documentation 0016007: [patch] Clean valgrind output by suppressing false errors reported by atis (Karma: +18.00) https://issues.asterisk.org/view.php?id=16007 |
| 13:16.40 | leifmadsen | atis_home: hmmm, I misread something -- Ready for Review is probably most appropriate -- I'm going to assign to myself and see if I can get through some of my documentation issues today |
| 13:17.37 | atis_work | leifmadsen: well, it would be nice to see why amorsen has troubles getting core with --log-fd, but i don't think that it's related |
| 13:18.52 | leifmadsen | atis_home: ya, that is entirely possible -- and it's just documentation, so we can always revise it again if need be |
| 13:18.58 | *** join/#asterisk-dev xpot (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 13:19.53 | *** join/#asterisk-dev oej (n=olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 13:19.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:27.07 | wildzero-cw | hello, when sip_send_mwi_to_peer in chan_sip (*1.4-svn) is called and i use odbc voicemail, and the odbc SELECT is slow (let's say 1000ms) then _entire_ chan_sip goes to sleep 1000ms, and the Recv-Q gets crowded, also see issue 16110, that's dump |
| 13:32.20 | file | same goes for realtime when querying the DB. |
| 13:34.42 | kpfleming | wildzero-cw: you won't have that problem in 1.6.1.0 and later, because SIP MWI no longer polls the database each time, it's event based |
| 13:39.32 | leifmadsen | M16110 |
| 13:39.34 | MuffinMan | [new] [Asterisk] Applications/app_voicemail/ODBC 0016110: slow ODBC database completely LOCK chan_sip reported by vrban (Karma: neutral) https://issues.asterisk.org/view.php?id=16110 |
| 13:40.07 | leifmadsen | based on what I just read here, that basically means that issue should be closed as "resolved in 1.6.1.0+" ? |
| 13:40.26 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 13:40.38 | kpfleming | it's not likely to be fixable in 1.4 and 1.6.0, without moving the MWI sending operations of chan_sip into their own thread |
| 13:41.26 | kpfleming | and of course, an ODBC database that takes 1+ seconds to respond is going to cause problems all over the place |
| 14:03.39 | oej | Agree. The first priority problem is the ODBC database. |
| 14:04.23 | wildzero-cw | the odbc 1+ second was a example , the main problem is, when 25+ subscribe or a register per second arrive chan_sip, and for every subscribe or a register chan_sip goes to sleep until the odbc SELECT is done, the Recv-Q gets crowded, and a lot of SIP messages get dropped or run into timeouts that causes the connected phones to send retransmission. Without odbc chan_sip can handle much much... |
| 14:04.25 | wildzero-cw | ...more subscribe and register. |
| 14:05.12 | kpfleming | that is true |
| 14:05.35 | oej | Out of curiousity - what's the database behind the odbc system? |
| 14:05.41 | kpfleming | and there is no simple fix, other than making chan_sip able to either handle the incoming requests with multiple threads (very hard) or handle the ODBC queries asynchronously (evern harder) |
| 14:05.44 | wildzero-cw | mysql |
| 14:06.07 | kpfleming | the real answer is that *normal* processing of such call loads should not be dependent on the database response if it can be avoided |
| 14:06.20 | kpfleming | which is the major failing of the current realtime design in Asterisk |
| 14:06.40 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:06.40 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:07.54 | kpfleming | i just had a slightly evil thought about how to handle this |
| 14:08.29 | kpfleming | what about if we did this: when a request arrives for which we can't find a peer in memory, we launch a background thread to do the realtime search for the peer, and *drop* the incoming request |
| 14:08.46 | kpfleming | if we did that, then normal SIP retransmission of the request would result in the request arriving after we have loaded the peer into memory |
| 14:09.04 | kpfleming | arriving *again*, i mean |
| 14:09.23 | atis_work | kpfleming: wouldn't it be better to receive request and then launch a separate thread to process it? |
| 14:09.29 | kpfleming | no |
| 14:09.50 | kpfleming | because that requires complex locking of dialog structures, in case the request is for an active dialog being processed by another thread already |
| 14:10.05 | kpfleming | it took us nearly a year to make that work properly in chan_iax2, which is much simpler than chan_sip |
| 14:10.40 | atis_work | aah, iax already does that? |
| 14:10.42 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 14:10.51 | kpfleming | even so, if you did that, you'd quickly consume all your threads waiting on the database, and couldn't respond to requests that arrived for peers that are already in memory |
| 14:10.56 | kpfleming | yes, chan_iax2 is multithreaded |
| 14:11.10 | kpfleming | not iax the protocol, chan_iax2 the implementation in asterisk |
| 14:11.30 | atis_work | kpfleming: yeah, i understand that much :) |
| 14:11.42 | atis_work | *terminology* ugh |
| 14:12.55 | atis_work | kpfleming: well, what about that: if request arrives, parse it and see if there's a thread for it. if not - create another one |
| 14:14.10 | kpfleming | no, there has to be a limit on how many threads you create |
| 14:14.31 | kpfleming | in any case, that's easily 6-9 months of hard work by an experienced chan_sip developer, because of the current design of chan_sip |
| 14:15.00 | kpfleming | and for the current problem of just getting realtime peers into memory when they are needed, the drop and wait approach might work just fine |
| 14:15.39 | atis_work | well, it might work, but it sounds ugly :) |
| 14:16.07 | kpfleming | it is really? we're queueing the request for later processing, but just letting the sender hold on to it, which they are required to do anyway |
| 14:16.25 | oej | drop and wait will cause cool issues when people report bugs... ;-) Wireshark and sip debug doesn't match. |
| 14:16.42 | kpfleming | yeah, we'd have to output something in sip debug so we knew when it happened |
| 14:18.12 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:18.17 | kpfleming | but anyway... if you are going to use asterisk realtime for something like chan_sip, you cannot use a database with such long query response times. it's just not practical. |
| 14:18.50 | atis_work | kpfleming: well, you just have to make sure that responses are fast |
| 14:19.01 | kpfleming | right |
| 14:19.07 | atis_work | i'm successfully keeping a copy of all channels in database |
| 14:19.08 | oej | Is there a difference in audiohooks between 1.4.23 and 1.4.26 - anyone that remembers any changes? |
| 14:19.35 | kpfleming | possibly... i don't remember if my multiframe patch touched that area or not, it may have |
| 14:19.45 | atis_work | so, it's 100-200 channels, each updated 10-20 times per call |
| 14:19.51 | atis_work | one small table does the job |
| 14:20.18 | oej | My mutestream stuff doesn't work in .26... :-)( |
| 14:20.24 | kpfleming | hmm |
| 14:20.34 | kpfleming | just no effect on the audio, or crashes, or ?? |
| 14:20.42 | oej | No effect on the audio. |
| 14:20.51 | oej | I see that it blanks out frames, but the audio is still around |
| 14:20.59 | kpfleming | huh |
| 14:21.06 | *** join/#asterisk-dev moy (n=moy@74.12.134.3) |
| 14:22.52 | kpfleming | yes, i see a change that may have broken that... still looking |
| 14:24.03 | oej | I just love having svn view back - thanks! |
| 14:25.30 | kpfleming | yes, there was a bug, it's already fixed in the 1.4 branch and in the 1.4.27 rc release(s) |
| 14:25.43 | oej | Tilghmans change? |
| 14:26.11 | kpfleming | i don't understand the question |
| 14:26.29 | oej | I see a change by tilghman a few days ago to main/audiohook.c |
| 14:26.37 | kpfleming | the bug was caused when i modified the code in channel.c to handle frame lists, and then dvossel fixed the problem you are experiencing as part of a chanspy problem fix |
| 14:26.39 | kpfleming | no |
| 14:26.42 | kpfleming | this was in channel.c |
| 14:26.48 | oej | Aha. |
| 14:26.57 | oej | Thanks for checking, appreciated! |
| 14:27.15 | kpfleming | commit asterisk 214194 |
| 14:27.18 | MuffinMan | [214194] Committed by dvossel on 2009-08-26T16:36:42.667015Z: ast_write() ignores ast_audiohook_write() results |
| 14:27.18 | MuffinMan | .. |
| 14:27.18 | MuffinMan | ..In ast_write(), if a channel has a list of audiohooks, those |
| 14:27.18 | MuffinMan | ..lists are written to and the resulting frame is what ast_write() |
| 14:27.18 | MuffinMan | ..should continue with. The problem was the returned audiohook frame |
| 14:27.21 | MuffinMan | ..was not being handled at all, and the original frame passed |
| 14:27.24 | MuffinMan | ..into it did not contain the mixed audio, so essentially audio |
| 14:27.26 | MuffinMan | ..was being lost. One result of this was chan_spy's whisper |
| 14:27.29 | MuffinMan | ..mode no longer worked. To complicate the issue, frames |
| 14:27.32 | MuffinMan | ..passed into ast_write may either be a single frame, or a list |
| 14:27.35 | MuffinMan | ..of frames. So, as the list of frames is processed in the |
| 14:27.38 | MuffinMan | ..audiohook_write, the returned frames had to be added to a new |
| 14:27.40 | MuffinMan | ..list. |
| 14:27.42 | MuffinMan | .. |
| 14:27.45 | MuffinMan | ..(closes issue #15660) |
| 14:27.47 | MuffinMan | ..Reported by: corruptor |
| 14:27.50 | MuffinMan | ..Tested by: dvossel |
| 14:27.52 | MuffinMan | .. |
| 14:27.54 | MuffinMan | .. |
| 14:27.56 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=214194 |
| 14:30.02 | *** join/#asterisk-dev CGMChris (n=chris@74.143.228.142) |
| 14:32.45 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 14:33.50 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:33.50 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:35.27 | oej | Interesting question |
| 14:35.41 | oej | Can I force CHANUNAVAIL as dialstatus when dial(local/exten@context) |
| 14:35.47 | oej | I can do busy, congestion etc |
| 14:38.11 | Grof | guys |
| 14:38.13 | Grof | need help |
| 14:38.17 | Grof | my server just crashed |
| 14:38.19 | oej | HELP |
| 14:38.21 | oej | there you are. |
| 14:38.24 | oej | ;-) |
| 14:38.36 | Grof | it crashed at jb_destro |
| 14:38.37 | Grof | y |
| 14:38.48 | Grof | eventhough i'm not using jitterbuffer |
| 14:39.19 | Grof | one of jb_frame-s |
| 14:39.25 | Grof | had refcount -1???? |
| 14:39.27 | Grof | wtf??? |
| 14:39.50 | Grof | can someone help? |
| 14:39.50 | Grof | it's 1.6.2-rc1 |
| 14:40.20 | atis_work | oej: a quick question for you |
| 14:40.35 | oej | Yes, atis_work. |
| 14:41.08 | atis_work | is it somehow possible to configure first response for INVITE to answer with m=image .. udptl |
| 14:41.30 | atis_work | for some number masks of peer |
| 14:42.08 | atis_work | i again have troubles with t38 and our provider.. just thinking if that could help |
| 14:43.18 | oej | Compared with other people in this channel, I have no experience of T.38, so I'll let someone else answer. Someone else : Please answer atis_work! |
| 14:43.25 | oej | You know who you are... :-) |
| 14:44.00 | oej | Hmm. Only for some numbers... That's interesting. |
| 14:44.05 | atis_work | oej: well, i just wanted to know if chan_sip can answer with non-audio without reinvites |
| 14:44.25 | atis_work | it's probably an users question.. heh.. |
| 14:44.27 | file | we don't support non-reinvite based T.38 negotiation |
| 14:44.35 | oej | THe problem here is also that you want one peer to act diffferently for some DIDs |
| 14:44.46 | oej | And we only do that with codecs in the dialplan |
| 14:44.50 | atis_work | file: ok, that's all i needed. i have to forget this test |
| 14:45.10 | file | what are your T.38 troubles? |
| 14:45.33 | atis_work | file: it's more my provider's T.38 troubles. they just can't seem to support T.38 on inbound calls |
| 14:45.42 | file | fun. |
| 14:45.54 | atis_work | at some point it was working, but i don't have any sip traces from that time |
| 14:45.58 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:45.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.46 | *** join/#asterisk-dev puzzled (n=foobar@83.163.53.136) |
| 14:47.39 | atis_work | i was using callweaver for sending/receiving and 1.4 for passhtrough.. but after upgrade they couldn't negotiate, so i dropped callweaver (as i intended to) |
| 14:48.11 | atis_work | but somehow my provider just doesn't seem to accept udptl now |
| 14:48.17 | *** join/#asterisk-dev hat_panda (n=pete-joh@triton.dsv.su.se) |
| 14:48.27 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:48.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:09.12 | *** join/#asterisk-dev gardo (n=gardo@110.55.240.37) |
| 15:28.00 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:28.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:29.10 | kpfleming | Corydon76-dig: ping |
| 15:34.09 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:56.42 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-syaowgnxevnleurm) |
| 15:58.57 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:58.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:59.05 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:08.50 | Corydon76-dig | kpfleming: pong |
| 16:11.53 | kpfleming | do you know if the ODBC/Postgres/MySQL APIs generally offer asynchronous (callback) methods for performing queries? |
| 16:12.24 | Corydon76-dig | ODBC does. Not sure about the others |
| 16:14.06 | kpfleming | that's interesting... so it would be possible to have an ast_realtime_load_multientry_callback() that just called you back when it had the results |
| 16:14.52 | Corydon76-dig | Well, it's not actually callback method in ODBC |
| 16:15.16 | Corydon76-dig | It's "go perform this query and I'll check back after a bit to see if it's completed yet" |
| 16:15.25 | kpfleming | oh. yuck. |
| 16:15.43 | kpfleming | so res_config_odbc/res_odbc would have to have a thread to do the checking and callback. |
| 16:15.43 | Corydon76-dig | Still asynchronous |
| 16:15.58 | Corydon76-dig | Yes |
| 16:16.10 | kpfleming | which is what would happen if a realtime provider didn't offer asynchronous mode at all, so it's not that awful. |
| 16:16.38 | kpfleming | this is all related to the discussion we had here earlier this morning where chan_sip can get blocked for an extended period of time if the find_realtime_peer() operation does not complete quickly |
| 16:20.25 | Corydon76-dig | So the question would be, do we want to create a) asynchronous versions of the realtime API, b) asynchronous routines in each user of the API, or c) a generic routine for calling APIs that may block, with callbacks |
| 16:20.42 | kpfleming | i don't think c is really an option |
| 16:20.44 | Corydon76-dig | I think C would be a good way to go, since DNS is another thing that may block |
| 16:20.48 | kpfleming | not unless you want to write it in C++ |
| 16:21.19 | Corydon76-dig | I'd love to try |
| 16:21.28 | Corydon76-dig | to write it in C, I mean |
| 16:21.36 | kpfleming | we already have asynchronous DNS, in dnsmgr |
| 16:21.39 | Corydon76-dig | write C in C |
| 16:21.49 | kpfleming | which does more than just do it async, it also updates, which is required for DNS |
| 16:22.05 | Corydon76-dig | Ah |
| 16:22.07 | kpfleming | if we were going to do this, i'd approach it from the (a) direction |
| 16:22.25 | kpfleming | and let users of the API decide whether to use the sync or async versions |
| 16:23.28 | putnopvut | root@belew:/usr/src/asterisk# ./configure --enable-dev-mode |
| 16:23.28 | putnopvut | bash: ./configure: Permission denied |
| 16:23.29 | putnopvut | Awesome |
| 16:23.43 | kpfleming | rm -rf / |
| 16:23.50 | putnopvut | perfect! |
| 16:24.30 | Corydon76-dig | kpfleming: I just hate the idea of suddenly doubling the number of API calls |
| 16:24.44 | putnopvut | Apparently somehow configure got set to 644 permissions... |
| 16:25.05 | Corydon76-dig | putnopvut: Windows unzip FTW |
| 16:25.30 | kpfleming | i just don't see how it would be practical to write a generic wrapper... forwarding arguments and results in a generic way is not at all easy |
| 16:25.32 | putnopvut | Corydon76-dig: I don't follow |
| 16:26.15 | Corydon76-dig | putnopvut: Windows permissions which don't mirror the Unix standard for permissions |
| 16:26.33 | Corydon76-dig | putnopvut: so unzip just ignores stored permissions |
| 16:26.48 | putnopvut | Ah |
| 16:27.10 | Corydon76-dig | That's usually how it gets lost |
| 16:37.49 | Corydon76-dig | kpfleming: what scares me a little about async API calls are the potential for queries that allocate results that are never released |
| 16:38.56 | Corydon76-dig | Well, but that's true for anything |
| 16:39.44 | Corydon76-dig | Okay, add it to the project list... |
| 16:43.08 | kpfleming | yeah, i think it should go on the list for the next planning meeting |
| 16:43.30 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 16:43.30 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 16:44.56 | atis_work | windows is usually how everything gets wrong :P |
| 16:57.06 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 17:16.34 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:20.57 | The_Boy_Wonder | I'm getting a segfault every time i issue a sip reload in trunk right now |
| 17:21.02 | The_Boy_Wonder | is anyone else seeing this? |
| 17:26.50 | putnopvut | The_Boy_Wonder: I'll give it a shot in my CCSS branch. Give me a sec. |
| 17:26.57 | The_Boy_Wonder | cool |
| 17:27.03 | putnopvut | The_Boy_Wonder: yep |
| 17:34.39 | putnopvut | For those following along, it appears to be a refcounting error with sip peers. |
| 17:34.59 | putnopvut | oh, and <3 valgrind |
| 17:38.09 | putnopvut | Hey The_Boy_Wonder, you may want to try reverting the recent OBJ_MULTIPLE commit to trunk and see if that makes the crash disappear. |
| 17:38.26 | putnopvut | because it looks like the peer is being freed while callling ao2_find on it. |
| 17:38.29 | putnopvut | Which is a bit bizarre. |
| 17:38.39 | The_Boy_Wonder | ahh |
| 17:40.07 | putnopvut | The_Boy_Wonder: Hmm, so the peer is being freed because ao2_find is being called with the OBJ_UNLINK flag apparently. |
| 17:40.53 | putnopvut | The_Boy_Wonder: yeah, that code in build_peer is totally f'ed up. |
| 17:41.26 | putnopvut | Actually, I suppose it's not. |
| 17:41.41 | putnopvut | We want to find the peer, get a reference to it, and unlink it from the container in one call. |
| 17:41.55 | The_Boy_Wonder | yep |
| 17:42.04 | putnopvut | But the problem is that the unlink appears to be causing it to be freed, too. |
| 17:42.41 | putnopvut | It's because of the if (!(flags & (OBJ_UNLINK | OBJ_MULTIPLE)) in astobj2.c |
| 17:42.43 | The_Boy_Wonder | I can confirm it is the recent astobj2 change that causes this |
| 17:42.50 | putnopvut | Yep |
| 17:43.51 | putnopvut | Yeah if you don't have OBJ_NODATA set but have OBJ_UNLINK set, then the bump of the refcount doesn't happen before the unlink. |
| 17:44.44 | putnopvut | I suppose it would be a good idea to ask kpfleming why that if was added. |
| 17:44.56 | putnopvut | But for now, I think I'll be eating some lunch :) |
| 17:45.03 | The_Boy_Wonder | me too |
| 17:45.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:45.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:26.26 | kpfleming | i will take a look at that, i did change the OBJ_UNLINK code in ao2_callback, i may have broken it |
| 18:26.27 | kpfleming | stay tuned |
| 18:34.14 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:40.10 | ebroad | Corydon76-dig, ping |
| 18:42.17 | kpfleming | putnopvut: The_Boy_Wonder: ok, fixed, if you want to test again |
| 18:42.34 | The_Boy_Wonder | thanks! |
| 18:44.12 | The_Boy_Wonder | kpfleming, putnopvut, that fixed it |
| 18:44.18 | kpfleming | yay! |
| 18:46.48 | ebroad | M16106 |
| 18:47.06 | MuffinMan | [confirmed] [Asterisk] Core/General 0016106: Hangup extension executed twice in 1.6.2 RC2 reported by ajohnson (Karma: +1.75) https://issues.asterisk.org/view.php?id=16106 |
| 18:47.36 | ebroad | anyone got a minute to answer a question or two? |
| 18:48.33 | kpfleming | we can try |
| 18:48.36 | ebroad | ok |
| 18:48.51 | ebroad | i confirmed this on svn trunk |
| 18:49.22 | ebroad | the wierd thing is, if i comment out the while loop in pbx.c that steps through the h extension |
| 18:49.29 | ebroad | it works fine |
| 18:49.59 | ebroad | it seems to be getting called elsewhere |
| 18:50.09 | kpfleming | that seems logical |
| 18:50.41 | ebroad | where else would it get called at the end of a call? |
| 18:50.44 | ebroad | autofallthrough? |
| 18:50.54 | kpfleming | you'll have to track it down |
| 18:51.13 | kpfleming | add something to the first priority of the 'h' extension that forces a segfault, then use gdb to find out how you got there |
| 18:51.22 | ebroad | hmm |
| 18:51.30 | ebroad | thats one way to do it |
| 18:51.45 | ajohnson | checks out the asterisk command Segfault() |
| 18:51.51 | kpfleming | lol |
| 18:51.59 | kpfleming | app_segfault |
| 18:52.11 | ajohnson | int i = 0/0; |
| 18:52.39 | ebroad | heh, that wouldnt be such a bad idea |
| 18:52.46 | ebroad | maybe func_segfault |
| 18:53.04 | Qwell | we've had this conversation before... like 10 times. |
| 18:53.04 | ebroad | i missed it |
| 18:53.11 | kpfleming | no, 0/0 isn't a segfault |
| 18:53.16 | ebroad | oh |
| 18:53.19 | Qwell | I think somebody always says "yeah, we should do that" |
| 18:53.32 | Qwell | I thought we actually did implement something though... |
| 18:53.38 | kpfleming | int i = *(int *) NULL; |
| 18:53.56 | kpfleming | or, just use DO_CRASH which is already in the code |
| 18:54.16 | ebroad | right, but not in the dialplan |
| 19:07.13 | *** join/#asterisk-dev titter (n=titter@c-98-208-156-75.hsd1.fl.comcast.net) |
| 19:13.43 | Corydon76-dig | ebroad: pong |
| 19:15.44 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 19:16.08 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:20.53 | *** join/#asterisk-dev CcRnp (n=shishir@208.179.165.18) |
| 19:21.30 | CcRnp | what is the maximum sample rate asterisk can support for MOH ? |
| 19:25.58 | ebroad | kpfleming, i found it |
| 19:26.01 | ebroad | features.c |
| 19:27.11 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:27.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:30.10 | ebroad | we are running the h extension in ast_bridge_channel |
| 19:30.45 | ebroad | s/ast_bridge_channel/ast_bridge_call/ |
| 19:32.14 | ebroad | and again in __ast_pbx_run |
| 19:34.10 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 19:42.53 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:42.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:47.52 | *** join/#asterisk-dev xpot-mobile (n=xpot@173.8.94.1) |
| 20:12.53 | kpfleming | some big commits to trunk this week... nice work everyone |
| 20:13.55 | *** join/#asterisk-dev errotan (n=errotan@81.0.115.122) |
| 20:14.02 | atis_home | kpfleming: maybe you have any idea of this comment https://issues.asterisk.org/view.php?id=15609#112626 |
| 20:14.45 | atis_home | reporter claims that it's your commit that faulty |
| 20:15.16 | atis_home | russell was trying to debug it for few days |
| 20:18.16 | ebroad | kpfleming, i tracked down the double h issue, posted a patch, but im not sure if i went about fixing it correctly |
| 20:19.34 | ebroad | spawn_extension keeps returning -1 when we do our bridge hangup run, even though the h dialplan gets executed |
| 20:22.43 | kpfleming | atis_home: well, it should be easy to test, just revert that #5 section of that patch (use ast_frdup instead of ast_frisolate in the autoservice run thread) |
| 20:22.56 | kpfleming | if that fixes the problem, that means the autoservice thread is being fed partially broken frames |
| 20:25.51 | *** join/#asterisk-dev gardo (n=gardo@110.55.240.37) |
| 20:32.59 | *** join/#asterisk-dev denon (i=denon@69.165.165.115) |
| 20:36.28 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 20:36.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:40.39 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:40.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:26.38 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:26.38 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:28.21 | *** part/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 21:35.12 | leifmadsen | atis_work: ping |
| 21:47.07 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 21:47.07 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 22:07.19 | *** join/#asterisk-dev atis_home (n=atis@193.238.213.215) |
| 22:08.20 | leifmadsen | anyone know for sure if 1.6.1 introduced 'core show help' or if that was 1.6.2 ? |
| 22:08.33 | leifmadsen | (before I compile 1.6.1 to find out) |
| 22:09.11 | atis_home | leifmadsen: let me check on 1.6.1 |
| 22:10.13 | atis_home | leifmadsen: nope, just "hint and hints" |
| 22:10.43 | leifmadsen | ok, so probably 1.6.2 has 'core show help' |
| 22:11.07 | atis_home | leifmadsen: regarding valgrind.txt, i wonder if it needs adding instructions to chdir /tmp |
| 22:11.30 | leifmadsen | atis_home: that is possible -- we could add it |
| 22:11.31 | atis_home | or it doesn't matter, as amorsen actually didn't read about compile flags :) |
| 22:11.35 | leifmadsen | :D |
| 22:12.08 | snuff-work | leifmadsen: wanted me for anythin? |
| 22:13.33 | leifmadsen | snuff-home: ummm... that was this morning (local, like 11pm your time I think) -- I was trying to calculate time diff between here and GMT+10, then I gave up and googled :) |
| 22:13.58 | leifmadsen | anyone have 1.6.2 installed and can confirm 'core show help' exists? |
| 22:14.03 | leifmadsen | I want to commit some documentation updates |
| 22:14.24 | jsmith | leifmadsen: I don't believe you |
| 22:14.34 | jsmith | ducks, and runs off to cook dinner |
| 22:14.38 | leifmadsen | jsmith: oh snap! I just commited 2 doc updates within the last hour |
| 22:14.38 | file | you goof, in the amount of time between when you asked and now you could have answered it yourself :P |
| 22:14.48 | leifmadsen | file: no, I'm compiling 1.6.2 now |
| 22:14.53 | leifmadsen | I was asking about 1.6.1 before |
| 22:15.28 | file | use the source, Leif |
| 22:15.46 | file | (the answer is yes, it exists in 1.6.2) |
| 22:16.13 | leifmadsen | the run around was fun though |
| 22:17.28 | atis_home | leifmadsen: i think you could consider M15244 a documentation too, as it doesn't break anyting |
| 22:18.50 | leifmadsen | M15244 |
| 22:18.52 | MuffinMan | [ready for testing] [Asterisk] PBX/pbx_ael 0015244: [patch] Invalid syntax with two ampersands in if block reported by atis (Karma: +18.00) https://issues.asterisk.org/view.php?id=15244 |
| 22:20.06 | leifmadsen | atis_home: I think you should update that to say, "but is not valid within expressions" |
| 22:20.17 | leifmadsen | actually, I can do that, heh |
| 22:22.33 | atis_home | damn, if i would remember where those were valid |
| 22:23.16 | atis_home | i think i meant something like && is valid if put inside $[...] but not in AEL |
| 22:23.54 | atis_home | nope, outside.. so you're right |
| 22:24.21 | atis_home | i tested that so long ago, i don't even remember how it worked |
| 22:25.07 | leifmadsen | we don't use && in conditions anywhere -- it is always & |
| 22:26.14 | atis_home | yeah, it was valid to use && somewhere, but not inside expressions |
| 22:26.42 | leifmadsen | oh really? hmmm |
| 22:27.00 | atis_home | well, for example in value of variable |
| 22:27.47 | atis_home | i know i put the check of $[ for some reason :D |
| 22:28.01 | snuff-work | leifmadsen: it was 1am i think.. (we are +10 GMT +1 extra for daylight savings |
| 22:28.36 | leifmadsen | atis_home: heh, well I'll check it tomorrow as it is now 6:30pm and my brain is done |
| 22:28.45 | atis_home | aah, sure |
| 22:28.57 | atis_home | it's 1:30am here, and beer tastes good :) |
| 22:29.04 | leifmadsen | I think I will go and play some flight simulator, or watch the Ableton Live tutorial video |
| 22:29.17 | leifmadsen | atis_home: mmmm, I drank my last one last night. Perhaps I will sip on a glass of wine. |
| 22:29.52 | atis_home | you can still buy some.. i can't |
| 22:34.43 | kpfleming | seanbright: do you mind making the same menuselect changes for the agi/ subdir? most people don't use that stuff, it can be defaulted to not build |
| 22:39.08 | snuff-work | would like 2 things build related.. 'no constant regen of embedded rules' every time make is run.. same with 'building doc' |
| 22:39.58 | kpfleming | we accept patches |
| 22:49.48 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 22:57.42 | snuff-work | my makefile foo is non-existant :( |
| 22:58.12 | kpfleming | i am fixing the first one right now, it's fairly easy, actually |
| 22:58.46 | snuff-work | 2nd 1.. i cheat.. i just comment out the core-doc.xml in the all line |
| 23:00.11 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 23:00.11 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 23:02.29 | snuff-work | bbl |
| 23:14.42 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 23:24.13 | *** join/#asterisk-dev natlonehat (n=natloneh@202.170.42.67) |
| 23:44.41 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@212.179.75.202) |
| 23:44.41 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 23:49.37 | *** join/#asterisk-dev snuff-work (n=aaa@120.19.48.25) |
| 23:49.37 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |