| 01:20.50 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:20.50 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 07:29.31 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:49.35 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:49.35 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:51.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:c86b:8f66:d279:238c) |
| 08:13.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:13.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:43.48 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:17.03 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-fyylswuoargebasu) |
| 09:20.12 | *** join/#asterisk-dev tsearle_ (~tsearle@37.19.10.33) |
| 09:20.12 | *** mode/#asterisk-dev [+o tsearle_] by ChanServ |
| 09:49.12 | *** join/#asterisk-dev tsearle__ (~tsearle@37.19.10.33) |
| 09:49.12 | *** mode/#asterisk-dev [+o tsearle__] by ChanServ |
| 09:50.26 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-mzbmlkprsmmeydkk) |
| 10:06.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:56ee:75ff:fed4:f268) |
| 12:53.04 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:389a:8c7f:ea54:c557) |
| 12:53.04 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:46.43 | seanbright | re: ASTERISK-27477 |
| 13:46.47 | seanbright | i don't see how that is a bug |
| 13:46.58 | seanbright | you can use the anonymous endpoint |
| 13:47.56 | gtjoseph | not following |
| 13:48.03 | seanbright | what is the bug? |
| 13:48.31 | gtjoseph | i think the bug is that chan_sip responds with 200 OK. |
| 13:48.39 | seanbright | so chan_sip is broken |
| 13:49.09 | seanbright | chan_pjsip is behaving as expected |
| 13:50.01 | gtjoseph | is it? |
| 13:50.25 | file | OPTIONS is supposed to be reponded to in the same fashion as an INVITE |
| 13:50.29 | file | or responded |
| 13:50.35 | seanbright | https://tools.ietf.org/html/rfc3261#section-11.2 |
| 13:50.42 | seanbright | The response to an OPTIONS is constructed using the standard rules |
| 13:50.42 | seanbright | for a SIP response as discussed in Section 8.2.6. The response code |
| 13:50.42 | seanbright | chosen MUST be the same that would have been chosen had the request |
| 13:50.42 | seanbright | been an INVITE. That is, a 200 (OK) would be returned if the UAS is |
| 13:50.42 | seanbright | ready to accept a call, a 486 (Busy Here) would be returned if the |
| 13:50.44 | seanbright | UAS is busy, etc. This allows an OPTIONS request to be used to |
| 13:50.47 | seanbright | determine the basic state of a UAS, which can be an indication of |
| 13:50.49 | seanbright | whether the UAS will accept an INVITE request. |
| 13:51.01 | gtjoseph | true, i'm just pointing out that the issue was in the context of parity with chan_sip. |
| 13:51.23 | seanbright | right, but it is feature parity, not bug parity |
| 13:51.34 | seanbright | it's dumb to introduce a bug in pjsip |
| 13:51.36 | gtjoseph | yep |
| 13:54.16 | gtjoseph | i'm just thinking from a chan_sip user perspective. if i migrate to chan_pjsip and I start getting issues because I'm sending 401s instead of 200s it's an admin mess. |
| 13:55.13 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 13:56.22 | seanbright | well that's going to happen no matter what |
| 13:56.36 | gtjoseph | the mess? :) |
| 13:56.40 | seanbright | yes |
| 13:56.49 | seanbright | we aren't going to make the broken behavior the default |
| 13:57.00 | seanbright | so you would need to add an endpoint option to enable it |
| 13:57.10 | gtjoseph | no but we might entertain an option to allow easier migration |
| 13:57.19 | gtjoseph | yep |
| 13:57.41 | seanbright | so lamesies |
| 13:59.43 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ixoltycxfjuzuasu) |
| 13:59.43 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:59.59 | gtjoseph | depends on your point of view. if you're a service provider a major behavior change like this could be a big deal. |
| 14:00.50 | seanbright | agree to disagree |
| 14:00.51 | AsteriskRoss | If I can add a little background, we are in the process of migrating to PJSIP and moving trunks to Asterisk 13. A lot of endpoints do not authenticate when requested and therefore asterisk raises a security event that causes the trunk to be blocked even if it is registered. |
| 14:00.51 | gtjoseph | yes it wasn't the correct behavior, but that's what it was for years. |
| 14:00.52 | seanbright | :P |
| 14:01.35 | seanbright | well, if we mitigate with an endpoint option, it should be ugly and embarassing |
| 14:01.51 | seanbright | i_migrated_to_chan_pjsip_and_all_i_got_was_this_lame_options = true |
| 14:02.09 | seanbright | i_like_buggy_software = yes |
| 14:02.11 | seanbright | heh |
| 14:02.31 | AsteriskRoss | The main offender appears to be Asterisk chan_sip btw |
| 14:03.02 | file | doesn't care that much |
| 14:06.51 | file | responding 200 OK to an OPTIONS all the time, while incorrect per spec, doesn't matter in the grand scheme of thing |
| 14:11.17 | AsteriskRoss | The option in chan_sip was 'auth_options_requests = yes/no' |
| 14:14.31 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-cvhucdgdldyrojsz) |
| 14:14.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:52.21 | seanbright | file: gtjoseph: is this too naive? http://paste.ubuntu.com/=HW2TVMXTWV/ |
| 14:52.53 | file | hum |
| 14:53.05 | seanbright | hmm |
| 14:53.17 | seanbright | i guess doing the check at digest level is too deep? |
| 14:53.31 | file | yes |
| 14:53.34 | gtjoseph | yeah a little |
| 14:53.52 | file | I'm just pondering the repercussions of it |
| 14:53.53 | seanbright | k |
| 14:53.53 | gtjoseph | we're also going to have to clarify what the aor authenticate_qualify option does |
| 14:54.11 | seanbright | hmm |
| 14:54.16 | seanbright | didn't know that existing |
| 14:54.18 | seanbright | existed* |
| 14:54.19 | seanbright | looking |
| 14:54.52 | file | 'tis for outbound |
| 14:55.37 | file | seanbright: I think the idea of doing it that way is fine |
| 14:56.00 | seanbright | ok, now it's fixed |
| 14:56.01 | seanbright | http://paste.ubuntu.com/=mfK5rRCPJK/ |
| 14:56.05 | seanbright | heh |
| 14:56.22 | file | (of just disregarding auth like that and letting the rest go like normal) |
| 14:56.40 | gtjoseph | i'd make it "authenticate_inbound_options" on aor to keep it consistent. |
| 14:56.57 | seanbright | k |
| 14:57.04 | seanbright | will figure out how to lookup aors |
| 14:57.05 | gtjoseph | s/options/qualifyh/ |
| 14:57.16 | file | argh |
| 14:57.19 | gtjoseph | s/qualifyh/qualify/ |
| 14:57.22 | file | that incurs a penalty. |
| 14:57.37 | seanbright | ok... how would either of you do this? |
| 14:57.40 | gtjoseph | yeah but that's our fault |
| 14:58.16 | file | personally to me it's an endpoint option, AORs are unrelated in the situation |
| 14:58.30 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:58.30 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:58.57 | seanbright | how about: authenticate_requests = !options |
| 14:59.02 | seanbright | :D |
| 14:59.03 | gtjoseph | technically yes but to a user? |
| 14:59.32 | file | I don't think users would get confused over this |
| 15:00.03 | file | it also means you're forcing an AOR on the endpoint to set the option |
| 15:00.18 | gtjoseph | having 2 "authenticate qualify/options" options, one in endpoint, one in aor? No that's not confusing at all. |
| 15:00.59 | file | I've given my opinion |
| 15:01.38 | seanbright | can't take the heat. |
| 15:01.49 | seanbright | i think i'll let someone else take this one |
| 15:02.33 | gtjoseph | wise decision |
| 15:02.50 | seanbright | heh |
| 15:02.55 | seanbright | ... thanks? |
| 15:03.07 | seanbright | gtjoseph: so you would put the option on the AOR, correct? |
| 15:03.11 | seanbright | i will give that a shot |
| 15:03.38 | gtjoseph | That would be my choice. |
| 15:03.55 | seanbright | and i can't let someone else take this |
| 15:04.00 | seanbright | because no one else appears to be interested |
| 15:04.21 | seanbright | and there is all this (apparently) trivial work out there that no one else can bother themselves to do |
| 15:04.24 | seanbright | oh well |
| 15:15.10 | seanbright | how does one get a struct ast_sip_aor * from an ast_sip_endpoint? |
| 15:16.09 | seanbright | nothing in res_pjsip.h seems to return one |
| 15:16.24 | gtjoseph | look at res_pjsip_registrar and see who it does it |
| 15:16.33 | gtjoseph | s/who/how/ |
| 15:17.07 | file | it doesn't, the code is in the options file |
| 15:17.38 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-rqsqwpfekcgsbvcf) |
| 15:17.38 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:17.44 | seanbright | oh dear |
| 15:19.32 | seanbright | yikes... are we sure we need this on the aor? |
| 15:19.39 | seanbright | what a waste |
| 15:19.51 | gtjoseph | sigh |
| 15:19.52 | seanbright | esp. for a temporary hack |
| 15:20.02 | seanbright | ? |
| 15:20.07 | seanbright | can you be less douchey please? |
| 15:20.42 | gtjoseph | fine. put it on endpoint but make sure it's named authenticate inbound_something |
| 15:21.14 | gtjoseph | i guess something can be options |
| 15:21.48 | seanbright | no, i'll do it your way |
| 15:22.04 | seanbright | but i'll wait for 7710 to land |
| 15:22.11 | gtjoseph | you do know that a puppy dies every time we do something that makes sense to us but not a user right? |
| 15:22.45 | seanbright | same thing happens when we presume what does and does not make sense to a user |
| 15:23.02 | seanbright | i don't think AsteriskRoss gives a flying fuck where the option is |
| 15:23.14 | seanbright | as long as it does when he needs it to |
| 15:23.29 | seanbright | s/when/what/ |
| 15:23.55 | gtjoseph | yeah but he asked for it. what about the schmuck who's scratching his head wondering what all these options do? |
| 15:27.16 | file | I don't think that's a valid question in regards to where the option lives. It would be documented as to what it does. For someone who needs it they'd likely search for "options" and find it. |
| 15:36.35 | seanbright | ok... so here's a serious question, with 100% less snark |
| 15:37.21 | seanbright | i am chan_pjsip, there is an upstream asterisk that sends me calls and is qualifying me |
| 15:37.35 | seanbright | i never call that upstream asterisk |
| 15:37.49 | seanbright | would i need to add a type=aor just to enable this option? |
| 15:38.05 | file | seanbright: if it's on an AOR, yes |
| 15:38.10 | seanbright | ok |
| 15:39.04 | seanbright | will think on it |
| 15:42.43 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:42.43 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:48.56 | cresl1n | Hey guys, gonna abandon the ipv6 dundi review |
| 15:49.01 | cresl1n | anybody want to stop me? |
| 15:49.14 | cresl1n | no response in a few weeks |
| 15:49.15 | gtjoseph | not i |
| 15:50.16 | file | cresl1n: nope |
| 15:50.17 | seanbright | can we switch it do a 'git rm' review? |
| 15:50.24 | cresl1n | No! |
| 15:50.30 | cresl1n | Lots of people use DUNDi still |
| 15:50.41 | seanbright | just aircraft manufacturers |
| 15:50.44 | cresl1n | And it generally just works |
| 15:50.52 | cresl1n | Hush you. |
| 16:12.13 | seanbright | gtjoseph: sorry for being a dick |
| 16:12.32 | seanbright | it' |
| 16:12.36 | seanbright | s just the way i was raised |
| 16:12.41 | cresl1n | heh |
| 16:12.42 | gtjoseph | Ha! |
| 16:12.55 | seanbright | so blame mr. & mrs. bright |
| 16:13.20 | file | perhaps you just need a Snickers bar |
| 16:13.25 | seanbright | mayhaps |
| 16:26.11 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:40.29 | *** join/#asterisk-dev Amnesia (~Amnesia@unaffiliated/amnesia) |
| 16:40.44 | Amnesia | question, when asterisk should authenticate with a LDAP server using TLS, what's the best way to set the client certificate/key, since the daemon's ran by a user, that doesn't have a homedir? |
| 16:41.07 | Amnesia | (I need to set TLS_[KEY|CERT], which is usually done through ~/.ldaprc) |
| 16:41.14 | Amnesia | I'm thinking of changing the OS's systemd service file, to add an ENV var, but that's kinda nasty.. |
| 16:43.11 | seanbright | under what circumstances is asterisk talking to an ldap server? |
| 16:43.14 | seanbright | res_config_ldap? |
| 16:47.47 | seanbright | Amnesia: what version of asterisk? i can probably come up with a patch |
| 16:47.56 | gtjoseph | <PROTECTED> |
| 16:48.10 | gtjoseph | depends on the packager though |
| 16:50.51 | Amnesia | seanbright: Asterisk 13.18.5 (debian), and it indeed is res_config_ldap. |
| 16:51.25 | seanbright | there's no built-in support to setting those options. |
| 16:51.30 | seanbright | so we'd have to patch |
| 16:51.33 | Amnesia | initially it's started as root, but setuid($UnprivilegedUID) is executed |
| 16:51.53 | seanbright | unless the lib is looking for .ldaprc under the hood, but i doubt it |
| 16:52.11 | Amnesia | well, there's https://github.com/asterisk/asterisk/blob/c86ed5a69d4837f9d9cf6c2463adb987d6225bed/configs/samples/res_ldap.conf.sample#L21 |
| 16:52.49 | seanbright | oh, ok cool |
| 16:52.53 | seanbright | so ldap.conf |
| 16:53.21 | seanbright | i see the dilemma |
| 16:53.42 | Amnesia | ldap.conf for the CA, and ~/.ldaprc for the client key/crt (and to override the system default CA) |
| 16:54.38 | gtjoseph | You know can add an override service file with just the parameters you want to add? /etc/systemd/system/asterisk.service.d/10-env.conf with just an Environment setting. |
| 16:55.08 | seanbright | well, you could use /etc/ldap/ldap.conf or $CWD/ldaprc |
| 16:55.24 | seanbright | i don't know where asterisk chdir's to though |
| 16:55.28 | seanbright | maybe |
| 16:55.32 | seanbright | / maye |
| 16:55.34 | seanbright | GAH |
| 16:55.40 | seanbright | / MAYBE |
| 16:55.58 | Amnesia | TLS_KEY & TLS_CERT in /etc/ldap.conf are ignored, since it're user specific variables (man 5 ldap.conf) |
| 16:56.58 | seanbright | sure enoug |
| 16:57.00 | seanbright | enough* |
| 16:57.08 | seanbright | you would need to patch res_config_ldap then i guess |
| 16:57.37 | seanbright | or do what gtjoseph suggested |
| 16:57.48 | Amnesia | hm ok, thanks gents |
| 17:00.28 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ezksgutiqixrkqve) |
| 17:00.28 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 17:21.24 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-icbbrsfysvsusdne) |
| 17:21.24 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:48.22 | *** join/#asterisk-dev KingDavid_ (~KingDavid@ip184-191-66-74.dc.dc.cox.net) |
| 17:52.46 | *** join/#asterisk-dev csavinovich (~KingDavid@ip184-191-66-74.dc.dc.cox.net) |
| 18:09.25 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 18:09.25 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:16.59 | coreyfarrell | anyone have an opinion on https://gerrit.asterisk.org/8181 ? one thing I hadn't realized "dnf whatprovides *bin/fetch" has no results in fedora so maybe it can't even impact Linux users? |
| 18:19.14 | file | I wouldn't realistically expect it to impact Linux users |
| 18:34.32 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:34.32 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 18:52.41 | Amnesia | is there anyone with experience with res_config_ldap over here, if so, mind to help me through something? |
| 19:08.34 | seanbright | Amnesia: does it have to do with setting your client certs? |
| 19:08.54 | Amnesia | no, I'm trying it plain text first |
| 19:18.39 | Amnesia | when I'm using the 'sipusers' as family name, it isn't even attempting to do ldap requests:/ |
| 19:18.58 | Amnesia | while it does do so when I make use of sippeers |
| 19:44.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00152bfa212642f65f.ipv6.abo.wanadoo.fr) |
| 19:45.26 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 19:45.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:54.12 | Amnesia | it's fscking confusing |
| 20:16.42 | coreyfarrell | rmudgett: about ASTERISK-27656 (the cdr leak) how prevalent is that bug? should cherry-picks to 13.19 and 15.2 be considered? |
| 20:17.45 | rmudgett | It leaks for every CDR. |
| 20:19.31 | rmudgett | REF_DEBUG wouldn't catch it because the CDR's are released when the container is released on shutdown. |
| 20:28.37 | jpsharp | What's the best way of chasing down a deadlock in AO2 containers? If I run with lock debugging, the system runs so slow it never locks. |
| 20:32.22 | cresl1n | Build with symbols enabled, maybe DONT_OPTIMIZE (but not lock debugging enabled). When it dead locks, connect with gdb and figure out what code paths are involved |
| 20:32.29 | cresl1n | That's the old school method :-) |
| 20:33.23 | coreyfarrell | rmudgett: seems like a serious enough issue that I'm adding the patch to my asterisk-13.19.0 RPM and rebuilding.. |
| 20:37.11 | seanbright | re: https://issues.asterisk.org/jira/browse/ASTERISK-23172 |
| 20:37.20 | seanbright | how do we feel about letting users set/override 'standard' params? |
| 20:37.21 | coreyfarrell | jpsharp / cresl1n: it's possible DONT_OPTIMIZE could change timing enough to avoid the deadlock as well. if that doesn't work you may have to use the exact build options that originally exposed the issue. it would make the gdb output less useful but better than nothing. |
| 20:37.33 | seanbright | ttl, maddr, lr, etc |
| 20:38.45 | jpsharp | I see which container is deadlocked, but I'm not sure how to find the guilty party that held the lock but never released it. |
| 20:39.06 | file | cresl1n: thoughts on regression release re CDR issue that coreyfarrell mentioned? |
| 20:39.27 | file | seanbright: did chan_sip restrict? |
| 20:39.37 | seanbright | file: that's an invalid question |
| 20:39.39 | seanbright | checks |
| 20:40.06 | file | seanbright: mirroring its behavior is just easiest and we know it has worked for people |
| 20:40.27 | seanbright | it appends |
| 20:40.42 | seanbright | which is invalid in and of itself |
| 20:40.45 | seanbright | so yeah |
| 20:41.00 | file | jpsharp: you generally have to look at the backtrace and decipher what is going on, failing that looking at the over all flow of stuff to understand the code paths |
| 20:43.12 | jpsharp | Well, foo. |
| 20:44.19 | cresl1n | file: yes? |
| 20:44.29 | cresl1n | wrt regression release. |
| 20:44.32 | file | good answer! |
| 20:44.38 | file | you should make a JIRA |
| 20:44.47 | cresl1n | invokes the powers of JIRA |
| 20:45.34 | cresl1n | creates an issue on file's private JIRA |
| 20:45.41 | file | you would |
| 20:46.21 | cresl1n | assigns it o file |
| 20:46.25 | cresl1n | *to |
| 20:46.26 | cresl1n | :-) |
| 20:46.42 | file | Permission Denied. |
| 20:46.47 | cresl1n | Awww snap |
| 21:10.53 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 21:10.53 | *** mode/#asterisk-dev [+o ChanServ] by verne.freenode.net |
| 21:20.54 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 21:33.14 | rmudgett | coreyfarrell: One of the reasons app_meetme wasn't deprecated before is because it has Shared Line Appearance support that ConfBridge doesn't |
| 22:05.35 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 22:05.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:34.43 | coreyfarrell | rmudgett: thanks, removed app_meetme from that patch and the JIRA issue. |
| 22:41.51 | coreyfarrell | not that it matters, I'm going to have to redo it for the CHANGES and UPGRADE.txt |
| 23:09.14 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |