| 01:23.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:23.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 03:17.07 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 04:19.16 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 04:19.16 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:36.26 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:36.32 | schmidts | good morning. TGIF!!!! |
| 06:39.01 | *** join/#asterisk-dev oej (~olle@office.ipvision.dk) |
| 06:39.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:39.33 | oej | Morning folks |
| 07:03.05 | schmidts | morning oej |
| 07:40.43 | oej | Hello Stefan! |
| 07:49.13 | schmidts | ;) |
| 07:49.28 | schmidts | very short question. is it save to do an pbx_builtin_setvar_helper after unlocking the channel? |
| 07:49.50 | schmidts | imho it should be done before releasing the lock so the chan will not go away in between, but i might be wrong about this |
| 07:51.05 | schmidts | forget it, setvar_helper will lock the channel itself |
| 08:27.18 | *** join/#asterisk-dev frawd (~francois@221.red-80-28-139.adsl.static.ccgg.telefonica.net) |
| 09:32.53 | oej | Yay! It compiled. |
| 09:33.05 | oej | Testing is overrated. |
| 09:33.14 | oej | runs to the airport before testing starts |
| 10:28.19 | schmidts | oej compiling is testing enough ;) |
| 10:31.42 | oej | Absolutely. If we get a binary, it works. All the rest is just user and configuration issues. |
| 11:16.04 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:16.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:16.15 | kpfleming | hello friday! |
| 11:23.48 | schmidts | good morning kpfleming ;) |
| 11:24.40 | mvanbaak | good mornin all |
| 11:24.45 | mvanbaak | TGIF !!!! |
| 11:24.47 | mvanbaak | \o/ |
| 11:25.09 | schmidts | +1 |
| 11:25.52 | mvanbaak | I can not wait to grab one of the icecold beers from my fridge |
| 11:26.25 | mvanbaak | until then: MOAR 0xC0FFEE |
| 11:39.13 | file | kpfleming, ummm |
| 11:39.41 | file | kpfleming, is jabber working? |
| 11:40.45 | kpfleming | not for me |
| 11:40.58 | file | and not for me |
| 11:41.32 | mvanbaak | who needs jabber when there's irc ? |
| 11:41.48 | kpfleming | it's our internal IM network |
| 11:41.50 | kpfleming | it's quite useful |
| 11:42.06 | mvanbaak | ah |
| 11:42.25 | file | it has decided as of late that it wants to go on vacation a lot, though |
| 11:42.47 | mvanbaak | it is linked to asterisk as well ? |
| 11:43.44 | file | not that fancy |
| 11:49.43 | mvanbaak | hhmm, will the apple timecapsule be fast enough to serve 1080p content over wireless ? |
| 11:49.50 | mvanbaak | time to test |
| 11:50.09 | mvanbaak | write speed of the internal harddisk is slow |
| 11:50.15 | mvanbaak | let's hope the read is faster |
| 11:52.12 | kpfleming | that depends on how (if) it is compressed |
| 11:52.44 | mvanbaak | the 1080p content is a 34GB mkv |
| 11:52.57 | mvanbaak | let's test it ;-) |
| 11:59.27 | kpfleming | what type of wifi are you using? |
| 12:01.00 | mvanbaak | wireless n |
| 12:01.20 | mvanbaak | without WPA or WEP |
| 12:01.52 | mvanbaak | all that encryption crap for wifi makes it damn slow |
| 12:02.14 | mvanbaak | my DHCP server knows mac addresses of my own devices, and gives them an ap in the LAN |
| 12:02.28 | mvanbaak | unknown clients get an ip in a seperate lan that can only browse the internetz |
| 12:02.39 | mvanbaak | ah, it works |
| 12:02.49 | mvanbaak | but you can't fast forward whehehehe |
| 12:09.46 | file | I prefer wired. |
| 12:09.54 | file | so all of my media playing devices are wired |
| 12:10.30 | file | also it looks like my lawn will be cleaned up today, yay! |
| 12:10.34 | mvanbaak | yeah, here as well, but since I do not have a TV in the bedroom yet, I have to use my mbp if I want to watch a movie in bed |
| 12:10.43 | mvanbaak | so wanted to test if it works over wireless |
| 12:11.04 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hzethhdhlxnknmhc) |
| 12:11.04 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:11.09 | mvanbaak | in the livingroom the appleTV and the timecapsule are connected with a 30cm UTP cable |
| 12:23.34 | file | nods to mjordan |
| 12:24.41 | kpfleming | this is quite an extended digium jabber outage this morning |
| 12:27.07 | opticron | yep.... |
| 12:27.15 | opticron | pokes schmidts |
| 12:34.15 | leifmadsen | huh, still jabber issues? |
| 12:34.19 | leifmadsen | sadness |
| 12:34.26 | opticron | yeah |
| 12:34.33 | mvanbaak | :( |
| 12:34.37 | leifmadsen | thought IT got that figured out... |
| 12:34.51 | opticron | it's like a weeble in that it wobbles, but this one does fall down |
| 12:35.09 | leifmadsen | so it's nothing like a weeble then :) |
| 12:35.20 | leifmadsen | that's the one defining characteristic of a weeble! |
| 12:35.37 | opticron | :) |
| 12:37.24 | kpfleming | weebles are make-believe |
| 12:41.26 | opticron | pffft, I've seen one |
| 12:41.36 | schmidts | opticron i am here |
| 12:42.05 | opticron | I just posted on the review instead for the calendar alarm fix |
| 12:42.19 | opticron | just checking to see if you had time to finish that off |
| 12:42.48 | schmidts | if not today then over the weekend but shouldnt be a problem |
| 12:42.49 | opticron | has been digging through stale-ish issues |
| 12:42.53 | opticron | cool |
| 12:44.17 | schmidts | oh as i just recognize i got a ship it from terry 1 week ago |
| 12:44.27 | schmidts | who said something about a bot with autosubmit function? |
| 12:50.23 | mjordan | schmidts: something tells me that an auto-commit bot would cause more problems then it would solve :-) |
| 12:51.43 | kpfleming | i am of the same opinion |
| 12:51.46 | schmidts | mjordan atleast you had to make sure that you only give a ship it for a code which is allready finished without anything left to do |
| 12:52.41 | russellb | we use something like that for openstack, and it works great... |
| 12:53.00 | mjordan | russellb: bah |
| 12:53.07 | kpfleming | russellb: you aren't managing multiple release branches, are you? |
| 12:53.15 | russellb | we are |
| 12:53.34 | kpfleming | oh, that's the multiple-code-review thing that pabelanger mentioned |
| 12:54.21 | mjordan | I think I could get behind that only if we could enforce a policy that a review has to have some number of reviewers sign off on it before it gets auto-committed. One - in some cases - is not enough |
| 12:54.27 | russellb | you submit a patch for each branch though, it's not automatically merging something into multiple branches |
| 12:55.21 | russellb | mjordan: and tighten down which 'ship it's count |
| 12:56.13 | mjordan | russellb: that'd be a controversial policy :-) |
| 12:56.23 | russellb | well yeah |
| 12:56.36 | russellb | but anyone who has an account probably isn't right either :) |
| 12:56.39 | schmidts | the only thing we want to get this is to finally change alaw to the first position through the night but this have to work even with a single ship it ;) |
| 12:57.10 | russellb | schmidts: that would break EVERYTHING |
| 12:57.18 | russellb | silly europeans |
| 12:57.18 | mjordan | schmidts: don't worry, in the morning we'll change it back to ulaw. |
| 12:57.24 | schmidts | :D |
| 12:59.22 | kpfleming | LPC-10 FTW |
| 12:59.55 | schmidts | +1 |
| 13:01.21 | elred_ | ~whatis 401 |
| 13:02.08 | russellb | wut |
| 13:02.14 | mjordan | I'm not authorized to comment on that :-) |
| 13:14.58 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yoporopcvsvcgcro) |
| 13:45.09 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:45.09 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:49.00 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:49.33 | *** join/#asterisk-dev DagMoller (~aguirre@unaffiliated/dagmoller) |
| 13:49.38 | DagMoller | hi |
| 13:50.13 | DagMoller | there is a way to remove a lot of useless "NoOp" messages produced by AEL extensions? |
| 14:03.18 | Gugge | set verbose to something lower :) |
| 14:05.46 | *** join/#asterisk-dev oej (~olle@95.209.176.8.bredband.tre.se) |
| 14:05.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:50.50 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:50.50 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:08.23 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:08.23 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:11.46 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:55.45 | Kobaz | df |
| 15:56.18 | Kobaz | is there an early-hangup hook you can tie info for getting a callback on channel hangup |
| 15:56.43 | Kobaz | like, i have a datastore callback for .destroy |
| 15:56.45 | Kobaz | but that's too late |
| 15:57.47 | Kobaz | i guess i can add in a .hangup to ast_datastore_info. i don't see anything around like that |
| 15:59.02 | file | that's sorta overloading the purpose of datastores |
| 16:16.30 | kpfleming | yow... if ast_tvdiff_ms() was broken, that could be a factor in a lot of weird problems |
| 16:17.08 | Kobaz | file: not really... i want some things in my datastore to go away on channel hangup |
| 16:17.39 | file | you want a hook to be executed on channel hangup, the result of which would allow you to cause the datastore to go away |
| 16:17.56 | file | storing that hook as part of the datastore is just an easy way to do it, but imo, is overloading the underlying purpose of datastores |
| 16:20.47 | mjordan | kpfleming: yup :-( |
| 16:22.55 | kpfleming | mvanbaak: https://wiki.asterisk.org/wiki/display/~kpfleming/Asterisk+Release+Branches%2C+Tags+and+Certified+Asterisk |
| 16:24.40 | Kobaz | hmm |
| 16:24.56 | Kobaz | file: would you rather a general purpose channel hangup callback then |
| 16:25.24 | file | yes, but generic enough so other hooks that may be applicable could be added |
| 16:26.57 | Kobaz | yeah |
| 16:27.00 | Kobaz | makes sense |
| 16:27.18 | Kobaz | i was thinking that but then i was thinkng the easy way would be another datastore callback |
| 16:27.22 | Kobaz | but yeah |
| 16:27.37 | file | that is indeed the easy way, but it does not make it the 'right' way |
| 16:27.45 | Kobaz | hah yeah of course |
| 16:28.00 | Kobaz | but i have a module that's crashing on access of a cleaned up channel |
| 16:28.15 | file | is a bit protective of stuff he has designed |
| 16:28.43 | Kobaz | but what's weird, is i have a big lock around all the module functions |
| 16:29.08 | Kobaz | so, theoretically there should never be a case where a channel is gone but hasn't run through that |
| 16:29.29 | Kobaz | but it's happening |
| 16:29.49 | Kobaz | i think it's an inherit/masq or something that doesn't run the fixup |
| 16:30.10 | Kobaz | i need more debugging is what i need |
| 16:35.53 | Kobaz | what's a good way to check if a channel (by pointer) still exists and is valid |
| 16:36.28 | Kobaz | probably would have to traverse the master channel list |
| 16:42.32 | mvanbaak | kpfleming: niiiice :) |
| 16:42.50 | Kobaz | i think it supports iax |
| 16:42.51 | Kobaz | er |
| 16:43.41 | mvanbaak | kpfleming: now if someone read that and still doesn't understand ... they are beyond help |
| 16:43.44 | mvanbaak | ;-) |
| 16:59.36 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.142.176) |
| 17:21.49 | opticron | Kobaz, did you ever find out if fixing that reference leak with Replaces transfers fixed your problems? |
| 17:30.49 | *** part/#asterisk-dev DagMoller (~aguirre@unaffiliated/dagmoller) |
| 17:30.49 | mjordan | Kobaz: put a patch on ASTERISK-19727 that should fix the local channel / MixMonitor problem |
| 17:57.18 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:12.29 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 18:12.29 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:15.08 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:15.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:28.28 | philipp64|laptop | what configuration in sip.conf controls how an OPTIONS message gets handled? and is it work having an optionscontext as we have regcontext and subscribecontext? |
| 19:29.03 | philipp64|laptop | I could trace through the source, but... |
| 19:29.28 | kpfleming | i don't think there are any options specific to handling incoming OPTIONS requests, they are treated the same as INVITEs, which is what the RFC says a SIP UA is supposed to do |
| 19:32.13 | Qwell | Also that type of question would be more appropriate for #asterisk |
| 19:34.33 | mjordan | elguero: thanks for testing that for me |
| 19:35.14 | elguero | mjordan: no problem, anytime |
| 19:36.53 | philipp64|laptop | I asked on #asterisk and no one seemed to know. |
| 19:37.16 | leifmadsen | philipp64|laptop: that's not entirely true as I saw the correct answer |
| 19:37.38 | leifmadsen | allow the OPTION to match the dialplan via a NoOp() and then it'll respond with 200 OK |
| 19:38.25 | philipp64|laptop | that would involve creating a valid default context, which I've deliberately avoided. |
| 19:39.05 | kpfleming | it means having a context that a corresponding INVITE would go to |
| 19:39.27 | kpfleming | if you are accepting OPTIONs requests from another endpoint, do you also accept INVITEs from it? if not, there's no harm in returning a 404 response |
| 19:40.19 | philipp64|laptop | I'm accepting invites from them when they arrive to a valid extension. |
| 19:40.39 | kpfleming | if they send an OPTION to an invalid extension, then a 404 is the correct response. |
| 19:40.45 | kpfleming | s/OPTION/OPTIONS/ |
| 19:40.47 | philipp64|laptop | the Taqua seems to want to generate sip:ping@n.n.n.n as the To: field on OPTIONS. |
| 19:40.55 | kpfleming | nothing wrong with that |
| 19:41.07 | kpfleming | although the To: header is not relevant, the Request-URI is |
| 19:41.36 | leifmadsen | from what I've seen most end points are just looking for a response, and are happy with a 404 or a 200 |
| 19:41.47 | kpfleming | that's what they are supposed to do, eys |
| 19:41.48 | kpfleming | or yes |
| 19:41.51 | leifmadsen | :) |
| 19:41.52 | kpfleming | if i could type and stuff |
| 19:41.57 | philipp64|laptop | the URI is the same. |
| 19:41.59 | leifmadsen | then most devices I've used seem to operate correctly ;) |
| 19:42.52 | philipp64|laptop | ok, so one doesn't need to match a context and extension, and indeed a 404 should be fine... although I've noticed that the Taqua isn't very RFC conformant. |
| 19:43.01 | philipp64|laptop | it regularly sends me 500 responses. Sigh. |
| 19:43.34 | mvanbaak | hitting it with a very heavy object may help |
| 19:47.36 | jsmith | Taqua... makes me want to break out a sledge hammer or a shotgun |
| 19:49.05 | philipp64|laptop | well, the company that operates it had a Siemens and then a Coppercom before it. |
| 19:49.31 | kpfleming | having a history of bad choices doesn't help :-) |
| 19:50.00 | mvanbaak | whehehehe |
| 19:58.07 | philipp64|laptop | yeah, wasn't going to say it... |
| 19:58.25 | philipp64|laptop | what is the gold standard of carrier class VoIP switches, anyway? |
| 20:01.46 | mvanbaak | asterisk |
| 20:03.55 | philipp64|laptop | of course. |
| 20:12.54 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 22:00.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 22:08.32 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hzethhdhlxnknmhc) |
| 22:29.23 | otherwiseguy | Oh, Friday. Why did you leave me so much to get done? |
| 22:34.48 | kpfleming | otherwiseguy: hey... i have a thought for you |
| 22:35.32 | kpfleming | but i think you've already addressed it without realizing it, so never mind :-) |
| 22:35.43 | otherwiseguy | but now I'm curious! |
| 22:36.20 | kpfleming | it was emitting the file name of the file that a variable came from during config parsing. a friend was trying to debug a config with dozens of included files, and just having a line number was not useful. |
| 22:36.38 | kpfleming | but your new code's error/warning messages include the file name, so good. |
| 22:36.55 | otherwiseguy | ah, yes. rmudgett let me know about that. :-) |
| 22:38.42 | otherwiseguy | kpfleming: you have been peeking at my config stuff... |
| 22:39.11 | kpfleming | just watching reviewboard comments fly by |
| 22:39.19 | kpfleming | and saw the ast_log messages |
| 22:41.01 | otherwiseguy | I am apparently getting more attached to certain design decisions than I used to. But, I feel pretty strongly that we should definitely not reload data when we know for a fact that there is "something" wrong with the data. Better, IMHO, to make someone fix things than for things to "mostly work" and just throw a warning that they may never see because they are running Asterisk as a daemon, etc. |
| 22:41.13 | kpfleming | agreed |
| 22:41.36 | kpfleming | you mistyped 'secret', so now your peer has no password, as an example. |
| 22:42.32 | kpfleming | which probably wouldn't even result in your system being *broken*... just vulnerable |
| 22:43.16 | otherwiseguy | yep. we can't catch everything that a silly user would do, but if we do catch something…make them fix it. |
| 22:43.51 | otherwiseguy | res_mindreader.so hasn't been written yet |