| 00:51.05 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 00:59.00 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:59.00 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:12.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:27.59 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:27.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:35.45 | file | mjordan, I was wondering when you'd appear |
| 01:40.20 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:58.37 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 02:12.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 02:17.25 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:17.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:57.07 | leifmadsen | file: I usually asssume tomorrow |
| 03:04.09 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gljzgoukyaklbqwu) |
| 03:04.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:38.23 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 04:08.49 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-gljzgoukyaklbqwu) |
| 05:31.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 07:57.26 | *** join/#asterisk-dev oej (~Adium@h87-96-222-88.dynamic.se.alltele.net) |
| 07:57.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:05.55 | oej | Morning folks |
| 08:06.31 | skrusty | morning |
| 08:06.57 | skrusty | oej: i will be in touch soon all being well, been away on holiday the last week |
| 08:07.33 | oej | Ok, skrusty! |
| 09:28.02 | *** join/#asterisk-dev kizoku (~whatever@ip-162-133-230-46.dialup.ice.net) |
| 09:55.52 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8c38:9977:d47e:f7fd) |
| 10:20.48 | skrusty | got my Ari dial function working! :) |
| 11:13.13 | *** join/#asterisk-dev dms1 (~dms1@c-68-59-23-92.hsd1.sc.comcast.net) |
| 11:46.00 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5600:4800:8cf8:991:167a:8b17) |
| 12:03.45 | *** join/#asterisk-dev oej (~Adium@h87-96-222-87.dynamic.se.alltele.net) |
| 12:03.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:19.34 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5600:4800:8cf8:991:167a:8b17) |
| 12:21.43 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 13:01.04 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:25.03 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 13:30.55 | *** join/#asterisk-dev oej (~Adium@h87-96-222-87.dynamic.se.alltele.net) |
| 13:30.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:40.11 | skrusty | quiet in here today |
| 13:40.39 | file | I blame Friday. |
| 13:40.55 | skrusty | i got my dial function working using ari |
| 13:41.13 | file | nice! |
| 13:41.14 | skrusty | few bugs to iron out |
| 13:41.55 | skrusty | i've created (wrong or right) a sort of replacement for fastagi using ARI |
| 13:42.09 | skrusty | i say sort of, because it's not the same, but seems on the surface similar |
| 13:42.31 | skrusty | lets you do things like this: http://pastebin.com/rGTKJmFi |
| 13:44.57 | file | oic |
| 13:46.00 | skrusty | ;] |
| 13:46.11 | file | why would that be a wrong thing? |
| 13:46.27 | skrusty | well, i always doubt myself that's why :) |
| 13:46.55 | file | rewrite the universe! |
| 13:47.01 | skrusty | :) |
| 13:47.45 | skrusty | i ran into a problem with my startup, we're using fastagi as a way of running scripts (edited via the web) - like twilio (but no ml based) |
| 13:48.00 | skrusty | but fastagi has some issues and i quickly found them masing up |
| 13:48.51 | skrusty | like, unless you monitor ami you don't know what the state of a call was if the caller hung up first |
| 13:49.37 | skrusty | of course, as ari doesn't allow exec, i've had to create my own dial and streamfile/getdata etc |
| 13:49.44 | file | yup |
| 13:49.58 | skrusty | but in the process added some nice new things too |
| 13:50.07 | skrusty | just a proof of concept right now though |
| 13:50.59 | skrusty | for example, the onAnswer lamda talks to the called channel |
| 14:01.30 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:01.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:37.59 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-frghvrhtrclfzfup) |
| 14:44.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uslwzvrltcjlupku) |
| 14:44.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:51.06 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ygeixjwhwuqxcbuu) |
| 14:51.06 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:51.34 | *** join/#asterisk-dev Navion (~Navion@rivendell/users/navion) |
| 14:52.44 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-oxcbqjleguwevipi) |
| 14:56.06 | *** join/#asterisk-dev abourget (~abourget@cable-12-101-36.b2b2c.ca) |
| 14:56.07 | Navion | Anyone ever have trouble resetting the admin password on a Polycom phone? I did the 4 finger initialize with the MAC address as the password but it comes up saying "SORRY PLEASE TRY AGAIN" |
| 14:57.19 | abourget | Asterisk 13 (running inside Docker) *exits* when I bridge two channels using the ARI |
| 14:57.33 | abourget | anyone experienced that before ? |
| 14:59.56 | opticron | by "exits", do you mean asterisk crashes? |
| 15:03.17 | jsmith | abourget: No, I haven't seen that |
| 15:03.24 | jsmith | waves to abourget |
| 15:04.56 | opticron | I have not seen that either |
| 15:06.03 | abourget | so it just exits, cleanly |
| 15:06.43 | abourget | "Asterisk cleanly ending (0)." |
| 15:06.47 | abourget | nothing in the messages log.. |
| 15:06.52 | opticron | that's...weird |
| 15:07.04 | opticron | does a debug log shed any light on it? |
| 15:07.22 | abourget | yeah, do you have a pointer to enabling heavy debug ? |
| 15:07.39 | opticron | in logger.conf, add debug to whichever output you want it on |
| 15:07.42 | abourget | ok |
| 15:07.53 | opticron | then on the console type "core set debug 5" |
| 15:07.58 | opticron | and "logger reload" |
| 15:08.10 | abourget | oh I'll just restart it.. it just crashed :P |
| 15:08.14 | opticron | :/ |
| 15:09.12 | abourget | ok, trying |
| 15:11.11 | abourget | http://vpaste.net/oJdrO |
| 15:11.20 | abourget | so that's the log from the moment I bridge |
| 15:11.42 | opticron | are you doing "asterisk -r" to attach to asterisk? |
| 15:12.08 | opticron | because that would show you the clean shutdown messages |
| 15:12.13 | opticron | I'm betting there's a crash |
| 15:12.45 | abourget | yeha I'm running through https://github.com/abourget/asterisk-docker/blob/master/run.sh |
| 15:12.52 | opticron | add -g to the command used to start asterisk so that it generates a core file |
| 15:12.56 | abourget | you have my full environment there, reproducible with Docker |
| 15:13.07 | opticron | then you can run gdb on the core file to get a backtrace |
| 15:13.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:13.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:13.30 | abourget | ok, wait a sec.. |
| 15:14.14 | abourget | is also currently building the latest * 12 to try the same thing |
| 15:15.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:16.58 | abourget | got it.. Segfaults |
| 15:17.48 | opticron | yep |
| 15:18.01 | opticron | do you know how to use gdb to get a backtrace from a core file? |
| 15:18.29 | abourget | yes.. I just don't find the core file :P |
| 15:18.36 | opticron | maybe in /tmp? |
| 15:18.56 | abourget | nah... isn't there |
| 15:19.02 | opticron | it is put wherever asterisk is run from |
| 15:19.07 | abourget | ran "ulimit -c unlimited" .. |
| 15:19.58 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:24.16 | abourget | gosh, can't get a dump |
| 15:24.22 | abourget | wondering if it's because it's running inside Docker.. |
| 15:26.58 | abourget | oh, ubuntu pipes that to "apport" |
| 15:28.02 | seanbright | just run it through gdb |
| 15:28.08 | seanbright | gdb /usr/sbin/asterisk |
| 15:28.13 | seanbright | run -ccccvvvvg |
| 15:29.17 | abourget | ok getting there ! |
| 15:29.18 | abourget | yeah, true |
| 15:31.43 | abourget | ok, hmm.. the backtrace only has addresses.. no symbol info it seems |
| 15:31.51 | abourget | it's been a little while since I've driven gdb though... |
| 15:32.19 | opticron | you might need to recompile with DONT_OPTIMIZE and BETTER_BACKTRACES |
| 15:32.42 | abourget | http://vpaste.net/l7RyF |
| 15:32.47 | abourget | not really interesting :) |
| 15:32.52 | abourget | ok.. |
| 15:33.02 | opticron | yeah, super useful! |
| 15:33.17 | opticron | a bunch of numbers specific to your machine :/ |
| 15:33.19 | abourget | this is my compilation process, can I simply add a line in there to enable those options ? https://github.com/abourget/asterisk-docker/blob/master/Dockerfile |
| 15:33.42 | abourget | it's in menuselect ? |
| 15:33.55 | opticron | yes |
| 15:34.19 | opticron | and it can be done via command line, but I can't quite recall the necessary commands |
| 15:34.23 | opticron | 1 sec |
| 15:34.46 | abourget | menuselect/menuselect --enable DONT_OPTIMIZE menuselect.makeopts ?? |
| 15:35.12 | opticron | that looks right |
| 15:36.33 | abourget | ok, rebuilding |
| 15:37.26 | abourget | thanks for the assistance :) |
| 15:37.32 | abourget | in the mean time, I'll try with * 12 |
| 15:39.28 | abourget | doesn't seem to crash in Asterisk 12 |
| 15:43.27 | abourget | ok, trying with Asterisk 13 |
| 15:47.35 | abourget | shoot.. I still don't have debug symbols.. |
| 15:49.07 | opticron | any chance you could jump into the build directory and run "make menuselect" to verify that those settings are enabled? |
| 15:49.31 | abourget | yes.. doing it now |
| 15:51.13 | abourget | trying again :) |
| 15:53.29 | abourget | MENUSELECT_CFLAGS=DONT_OPTIMIZE LOADABLE_MODULES BETTER_BACKTRACES BUILD_NATIVE OPTIONAL_API -> from menuselect.makeopts |
| 15:55.53 | abourget | hmm.. running through gdb, it stalls at the beginning |
| 15:59.11 | abourget | any command to see for a given binary the settings at compile time ? |
| 15:59.33 | abourget | Is that sequence ok ? http://vpaste.net/zFeIX |
| 16:00.06 | leifmadsen | abourget: seems ok |
| 16:00.29 | leifmadsen | although not sure I understand why you need menuselect twice? |
| 16:01.16 | abourget | nah.. don,t need it twice |
| 16:01.32 | abourget | :) |
| 16:03.01 | abourget | hmm.. I'm kinda stuck |
| 16:03.16 | abourget | running "gdb /usr/sbin/asterisk", then "run -ccccgvvvv" stalls |
| 16:03.41 | abourget | here: |
| 16:03.45 | abourget | [ Initializing Custom Configuration Options ] |
| 16:03.47 | abourget | <PROTECTED> |
| 16:09.27 | abourget | ok, that's a Docker issue, as permissions for SYS_PTRACE aren't automatically passed on |
| 16:10.44 | abourget | aaaahhhhhhhhhhhhhhhHH! got it :) |
| 16:13.47 | abourget | ok I get this in the host's syslog: http://vpaste.net/ZBcyz |
| 16:16.59 | abourget | ok, it might be Docker related.. but it seems pretty cryptic.. it stalled the Docker instance |
| 16:17.19 | abourget | but in the same environment, Asterisk12 works well.. |
| 16:17.53 | jsmith | abourget: Looking at that stacktrace, it seems related to AppArmor |
| 16:18.13 | abourget | I lifted apparmor's security with "aa-complain" .. |
| 16:18.41 | abourget | for "docker-default" that is.. |
| 16:18.49 | jsmith | The top three lines in the call trace all point toward AppArmor |
| 16:19.07 | abourget | true |
| 16:23.26 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-142-164.user.veloxzone.com.br) |
| 16:24.46 | jameswf | attempts to bleach 1989 workout video from brain.... |
| 16:29.27 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-nnzncurmywlyecex) |
| 16:30.01 | mjordan | so, looking at review board, this - https://reviewboard.asterisk.org/r/3980/ - should have been merged quite awhile ago. |
| 16:30.27 | mjordan | Since the documentation claims that column is in microseconds - even though it is in seconds - how does everyone feel about it going into 11? |
| 16:30.49 | mjordan | (it is in seconds currently) |
| 16:31.27 | abourget | jsmith, actually it seems that apparmor gives trouble when it tries to write the core dump file.. (see in the trace do_coredump) |
| 16:31.39 | abourget | so there might still be a reason why Asterisk itself would crash |
| 16:31.59 | jsmith | abourget: Perhaps -- it's not really clear :-/ |
| 16:33.29 | abourget | I'll try to get a nice core |
| 16:47.13 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-bhcqlmvszrlurwtn) |
| 17:42.43 | file | in a bizarre twist of reality... I entered pbx.c and survived |
| 17:45.16 | anonymouz666 | but did you touch in anything? |
| 17:45.42 | file | I did |
| 17:45.50 | file | I fixed a bug |
| 17:47.21 | anonymouz666 | the risk was for a good reason then! |
| 17:50.49 | file | well, I fixed the crash at least |
| 18:00.35 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-hrecmjdvwpzkdpuv) |
| 18:09.25 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:09.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:10.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 18:13.23 | *** join/#asterisk-dev nix8n82 (~AndChat56@2600:100e:b014:ec:e0c2:126:e36a:4ae3) |
| 18:20.48 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 18:32.53 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-hupyrxdgqpxhbktx) |
| 18:40.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:40.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:52.58 | mjordan | file: buckets. |
| 18:53.07 | file | full of water. |
| 18:54.17 | mjordan | so, I'm thinking through the media caching stuff |
| 18:54.27 | mjordan | generally, I want the core to provide the API that the rest of the system will use |
| 18:54.52 | mjordan | however, I'm starting to think that the core probably won't need to provide registration facilities itself, as the bucket API already does that |
| 18:55.18 | mjordan | that is, a 'res_http_media_cache' can register itself as a bucket provider for 'http' and 'https', which already gives it retieval callbacks |
| 18:55.29 | mjordan | and it can make all the logical decisions about populating the buckets. |
| 18:55.33 | file | currently there can be only one |
| 18:55.35 | mjordan | The core just needs to call the bucket API. |
| 18:55.37 | mjordan | Yes. |
| 18:55.40 | file | but yup |
| 18:55.42 | mjordan | That was my other concern |
| 18:55.55 | mjordan | can we foresee a need for multiple bucket providers for 'http'/'https'? |
| 18:56.14 | file | WELL |
| 18:56.34 | mjordan | hum. I do have one wrinkle that I'll come back to |
| 18:56.46 | file | I don't think so - provided the above encompasses all required logic |
| 18:57.03 | mjordan | I may go down the path of "there can be only one" until it's clear that's a bad idea |
| 18:57.08 | mjordan | so, the wrinkle! |
| 18:57.39 | mjordan | the HTTP bucket implementation generally should just make temporary files (or use a temp file name, that is) in the appropriate location. It doesn't have any knowledge about what the name of the file should be. |
| 19:00.18 | mjordan | However, that's not the case for the higher level API. Sometimes, we want to force that local file name to be something |
| 19:00.32 | mjordan | i.e., I am about to go request a sound file, but I know a video file is coming along next |
| 19:00.44 | mjordan | the bucket API doesn't really have a way to pass that information down through it |
| 19:00.54 | file | what do you mean? |
| 19:01.37 | mjordan | so, higher level API is where we start, that is non-bucket. That's what users call. They say - I want to download sound http://myserver.com/monkeys.wav and http://myserver.com/monkeys.h264 |
| 19:01.47 | file | yup. |
| 19:01.59 | mjordan | so, that's two separate requests |
| 19:02.05 | file | yup. |
| 19:02.06 | mjordan | the names of the local files that are created *must* be identical |
| 19:02.14 | mjordan | otherwise, playback is not going to work super well |
| 19:02.17 | file | sure |
| 19:02.39 | mjordan | you also can't use the resource name as the name of the local file |
| 19:02.52 | mjordan | as I could just as easily be asking for http://myserver.com/media=monkeys&format=wav |
| 19:03.03 | mjordan | and http://myserver.com/media=monkeys&format=h264 |
| 19:03.15 | mjordan | and I might get who knows what back from the server - it may generate a random name for the resource as well |
| 19:03.19 | mjordan | but locally, I have to name them the same |
| 19:03.32 | mjordan | which means the bucket API - which merely takes the URI - doesn't provide enough information to the implementation about this |
| 19:03.44 | mjordan | the higher level API is aware that 'oh, hey, this thing needs to be named the same' |
| 19:03.52 | mjordan | but doesn't have a way to provide that to the bucket implementation |
| 19:04.11 | file | right. |
| 19:04.37 | mjordan | this is the wrinkle: I can work around this by providing an api_provider struct and having the bucket implementations provide that to the core, and have it implement its own retrieve method |
| 19:04.42 | mjordan | it's just sad-making at that point |
| 19:05.00 | file | it's really only for cases where temp files are used |
| 19:05.03 | file | meh |
| 19:05.38 | file | you could reconcile it up above but that's duplicating the file |
| 19:06.00 | mjordan | yeah |
| 19:06.06 | mjordan | I thought about that as well. |
| 19:06.29 | mjordan | I may punt on thinking through this further until implementation happens, because I think it's hard to predict the right answer here |
| 19:07.54 | file | punt, punt, punt |
| 19:08.52 | mjordan | bucket objects aren't immutable, are they? |
| 19:09.10 | mjordan | (other than the URI) |
| 19:10.00 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:10.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:10.19 | file | they are not |
| 19:11.03 | mjordan | cool. Then the higher level API should probably just rename the file if it wants to. |
| 19:11.24 | skrusty | evening |
| 19:11.42 | file | you can |
| 19:12.11 | file | the thing being if you pull from a cache then you either want a symlink or a dupe |
| 19:12.24 | file | since you presumably don't want to change the cached name, unless you do |
| 19:12.35 | mjordan | the cached name kind of doesn't matter. |
| 19:12.42 | mjordan | it just has to be handed to the filestream APIs |
| 19:12.54 | file | yeah but I mean for the next time it's accessed |
| 19:13.06 | mjordan | define "accessed" - when it is re-pulled? |
| 19:14.28 | file | for caching you presumably have to store it on-disk with a name that is determinable via URI |
| 19:15.24 | mjordan | I'm not sure about that. |
| 19:15.42 | file | or do you mean caching the structure in memory associated with it and key on URI? |
| 19:15.52 | mjordan | yes |
| 19:16.08 | mjordan | the URI is immutable. The name of the file on disk should just be associated with the URI, but can be anything. |
| 19:16.23 | file | hrm - and if you restart Asterisk? |
| 19:16.27 | mjordan | AstDB |
| 19:16.30 | file | ah |
| 19:16.35 | file | then yeah |
| 19:16.38 | mjordan | I'm adding that to the wiki page now :-) |
| 19:16.38 | file | that's fine |
| 19:17.04 | mjordan | the only time the local file name matters is when we have multiple formats |
| 19:17.16 | mjordan | the URIs are still different |
| 19:17.23 | file | are you being clever? |
| 19:17.25 | mjordan | but the local file name has to be the same (minus the extension) |
| 19:17.26 | mjordan | yes |
| 19:17.31 | mjordan | YES I AM |
| 19:17.41 | file | are you implementing the bucket metadata interface for the HTTP one as astdb? |
| 19:17.46 | file | :P |
| 19:17.50 | mjordan | the whole "hey, don't tell me the extension, I'll figure it out for you!" is kind of annoying here |
| 19:18.03 | mjordan | file: actually, I think the core part will handle that |
| 19:18.10 | mjordan | since that way it will also work for, say, TTS |
| 19:18.41 | mjordan | I don't really care what the metadata is or anything, I just need to take the attributes from a bucket and store them in the AstDB, then have a magic way of re-creating the bucket when Asterisk starts. |
| 19:18.42 | mjordan | MAGIC |
| 19:18.42 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:18.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:18.54 | file | yup |
| 19:19.44 | mjordan | but it is a thought to do the metadata always in the AstDB... |
| 19:19.47 | mjordan | anywho. |
| 19:22.56 | file | mjordan, your reward is https://www.youtube.com/watch?v=Med2XipHJJM |
| 19:25.16 | mjordan | well. That exists. |
| 19:27.26 | Marquis42 | To paraphrase Strongbad: Japanese people are weird, man. |
| 19:29.16 | leifmadsen | haha |
| 19:30.25 | leifmadsen | I started watching it |
| 19:30.33 | leifmadsen | then it got too weird |
| 19:30.57 | leifmadsen | https://www.youtube.com/watch?v=zB92yoK242s |
| 19:31.02 | mjordan | I fast forwarded to where they were sushi, then when they were eating sushi, which made me think: are they eating themselves? |
| 19:31.14 | mjordan | this caused an existential crisis to kick in, and I shut down |
| 19:31.22 | Marquis42 | lol |
| 19:32.12 | file | leifmadsen, ohhhhhhh llamas with hats |
| 19:32.20 | file | Carlllllll |
| 19:32.31 | leifmadsen | file: exactly |
| 19:34.33 | mjordan | I have a rumbling in my tummy |
| 19:35.06 | Marquis42 | That only hands can satisfy. |
| 19:35.25 | leifmadsen | file: now we're both in the wrong |
| 19:56.36 | *** join/#asterisk-dev abourget (~abourget@cable-12-101-36.b2b2c.ca) |
| 19:56.50 | abourget | folks!! I finally got a backtrace ! |
| 19:57.04 | abourget | after filing a bug for Docker, another for AppAmor, another bug filed for the kernel by the apparmor guys |
| 19:57.08 | abourget | I,m really happy to have a stacktrace for you ! |
| 19:57.34 | opticron | hooray! |
| 19:57.37 | abourget | indeed :) |
| 19:58.01 | abourget | http://vpaste.net/RKjPt |
| 19:58.03 | abourget | that is the precious! |
| 19:58.22 | abourget | that,s running Asterisk 13.0.0 |
| 19:58.27 | opticron | "bt full"? |
| 19:58.43 | abourget | sorry :) heheh |
| 19:59.11 | abourget | http://vpaste.net/a6slB |
| 19:59.17 | abourget | is that better ? :) |
| 19:59.45 | abourget | but folks I gotta run... what should I do next ? |
| 19:59.46 | file | that's... |
| 20:00.01 | file | already filed |
| 20:00.05 | Qwell | declined to receive the rtcp report. |
| 20:01.03 | abourget | what is it ? |
| 20:01.07 | abourget | can I work around it ? have any link ? |
| 20:01.15 | mjordan | abourget: yup, there's a patch, hold on |
| 20:01.44 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-24498 |
| 20:01.57 | mjordan | ASTERISK-24498-13.diff on the issue |
| 20:02.11 | mjordan | Also, if you aren't using HEP, noload res_hep_rtcp. It doesn't really do much for you. |
| 20:03.23 | abourget | such a tiny patch :) |
| 20:03.26 | abourget | heehee.. |
| 20:03.32 | abourget | ok cool.. now I can automate the patching.. with Docker :) |
| 20:14.45 | *** join/#asterisk-dev otherwiseguy (~otherwise@24.27.227.0) |
| 20:26.26 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:29.04 | Marquis42 | Hrm, so does anybody happen to know what sip_peer.rt_fromcontact is even used for? Everywhere in the code that it's checked it's also checking for the value of a sip_settings.rtupdate so it seems entirely superfluous. The way it's being set, as well, seems wrong in that it prevents updating the realtime storage of a peer's contact information on a REGISTER with a zero expires values. Basically, as it stands, that update |
| 20:29.06 | Marquis42 | happens exactly every other time you un-REGISTER. |
| 20:29.22 | Marquis42 | This is chan_sip, BTW, in case that was somehow non-obvious. |
| 20:34.10 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:36.42 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:37.29 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:37.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:43.53 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5600:4800:8cf8:991:167a:8b17) |
| 20:44.42 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:50.48 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:52.49 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:58.39 | bklang | Is there a replacement for "qualify=yes" in chan_pjsip? I can't find it in the Asterisk wiki and the contrib script for converting sip.conf doesn't know either |
| 21:00.35 | *** part/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:00.38 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:00.38 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:00.47 | file | qualify_frequency, set on the AOR |
| 21:00.53 | bklang | Thanks |
| 21:02.25 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 21:05.03 | bklang | interesting, the converter script properly handles tlscafile but silently eats tlscertfile |
| 21:05.03 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 21:05.28 | bklang | is contrib/scripts something that you guys want bugs reported on? or are they "extended" support? |
| 21:07.51 | seanbright | no bug reports without patches |
| 21:07.54 | seanbright | it's a new policy |
| 21:08.31 | seanbright | also: friday! |
| 21:14.34 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5600:4800:8cf8:991:167a:8b17) |
| 21:15.27 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-hisvgizcngygrcfs) |
| 21:30.44 | mjordan | bklang: bugs for contrib scripts is fine |
| 21:30.55 | mjordan | extended != no fixes :-P |
| 21:31.02 | mjordan | Just that your mileage may vary (and patches help) |
| 21:45.24 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vbyfzmnvlgrnqgjv) |
| 22:06.15 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 22:06.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:07.15 | jameswf | will just leave http://pbxinaflash.com/community/index.php?threads/error-no-fax-modules-detected.15944/#post-103226 here... |
| 22:07.24 | jameswf | slowly turns and walks away |
| 22:07.51 | mjordan | oh snap, did you just drop the mike and walk away? |
| 22:08.30 | mjordan | huh. |
| 22:08.35 | jameswf | had to do something awesome in his FUBU outfit |
| 22:08.35 | mjordan | goes to look at something |
| 22:08.47 | mjordan | yup, res_fax_spandsp is still there. |
| 22:10.07 | mjordan | god speed tonyclewis |
| 22:12.18 | tonyclewis | mjordan: I will fall on the sword on this one. |
| 22:38.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:41.32 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 22:47.06 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:06.36 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uslwzvrltcjlupku) |
| 23:08.06 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-fhnchmpmzuisznay) |
| 23:40.46 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:50.36 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-frghvrhtrclfzfup) |