| 00:21.37 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:21.37 | *** 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 |
| 06:45.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:3d86:580:8d29:7c8) |
| 06:47.15 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:47.15 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:36.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:27.31 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 10:51.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:56ee:75ff:fed4:f268) |
| 13:14.31 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 13:22.06 | tzafrir_laptop | Qwell: ping |
| 13:29.54 | jkroon | https://gerrit.asterisk.org/#/c/8933/ - it's a fix for AMI digest auth (http) - would really appreciate if someone can take a look. |
| 13:32.38 | file | everything that goes on gerrit gets reviewed |
| 13:37.55 | jkroon | so just wait :) |
| 13:55.55 | seanbright | just applied a firmware update to my coffee mug. we are living in the future. |
| 13:58.32 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.169) |
| 13:59.48 | file | seanbright: oh do you have the one that keeps things at a specific temperature? |
| 14:08.51 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-xgyremabzjgaiqmx) |
| 14:08.51 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:14.07 | seanbright | file: yes. the ember. |
| 14:14.13 | seanbright | wife got it for me for my birthday |
| 14:14.23 | seanbright | (i wouldn't have bought it for myself) |
| 14:17.56 | file | How is it? I linked kharwell it, and he said the same about not buying it for himself |
| 14:18.23 | seanbright | well, it's interesting. i drink a lot of coffee but i also drink it quickly. |
| 14:18.37 | seanbright | but it is nice to go to a meeting and for my coffee to stay warm |
| 14:18.56 | file | oic |
| 14:19.00 | kharwell | how about the size. 10oz seemed a little small? |
| 14:19.26 | seanbright | it's fine for me. i'm only a few feet from the coffee pot. |
| 14:30.23 | jkroon | gtjoseph, i see you picked up ASTERISK-27841, please refer https://gerrit.asterisk.org/#/c/8933/ |
| 14:30.50 | file | he's not working on it |
| 14:30.51 | file | he just triaged it |
| 14:31.05 | gtjoseph | yep i assigned ASTERISK-27841 to you. |
| 14:31.10 | jkroon | not sure what i did wrong that jira didn't pick up on the review. |
| 14:31.33 | file | you didn't set the topic of the review to the ASTERISK id |
| 14:31.35 | jkroon | ah :) sorry about that. been a long day here. |
| 14:31.37 | file | so it doesn't know they're related |
| 14:32.00 | gtjoseph | i just fixed that |
| 14:32.48 | jkroon | is there a way to set that via commit or do i manually need to set it after git review ? |
| 14:33.11 | gtjoseph | when you do "git review" you can add the -t option to set the topic |
| 14:33.26 | jkroon | thank you, i'll keep that in mind for future. |
| 14:33.38 | gtjoseph | or you can name the branch you're working in to the topic and it will automatically use that |
| 14:34.30 | jkroon | eg 'ASTERISK-27841 manager-digest-auth' ? any way to set the branch at "git review" time too? |
| 14:35.47 | file | the name of the git branch that you create is what is used by default, so it'd just be ASTERISK-27841 |
| 14:36.41 | gtjoseph | yeah. when you start working locally, create a new branch from the main branch... For instance,... git checkout 13 |
| 14:36.55 | gtjoseph | then git checkout -b ASTERISK-27841 |
| 14:37.21 | gtjoseph | do all your work, then do "git review 13" |
| 14:37.29 | gtjoseph | where 13 is the base branch yoiu started from |
| 14:38.01 | gtjoseph | the topic will automatically be set to ASTERISK-27841 |
| 14:41.43 | *** join/#asterisk-dev m0bius (~mobius@178-21-210.static.cyta.gr) |
| 14:42.44 | m0bius | Hi ppl. I've been told on jira that I should bring this up here so here goes. This is about ticket ASTERISK-26894 with regards to asterisk handling tel: uri in the chan_pjsip |
| 14:44.03 | m0bius | I've added a small patch that removes checking only for sip/sips: uri in the pjsip_message_filter and allows tel: as well via the PJSIP_URI_SCHEME_IS_TEL() |
| 14:45.28 | m0bius | What conserns me the most with this one, is not just that asterisk does not handle tel: but that it silently drops the call with a 416 without any WARNING or NOTICE. You can only get a warning if you enable AST_DEVMODE and have debug on |
| 14:48.40 | gtjoseph | Asterisk normally doesn't emit warnings or errors in situations where a normal SIP response can be sent |
| 14:49.46 | m0bius | if it drops the call with a 416 and no warning how will the user ever know that a call was received and dropped? |
| 14:50.08 | m0bius | it gives warnings on non-matching codecs, on non-matching extensions |
| 14:50.27 | gtjoseph | yeha but that's after asterisk has already entered the dialplan |
| 14:50.39 | gtjoseph | in this case, it's like a 401, not authorized |
| 14:51.03 | m0bius | doesn't asterisk warn also in case of wrong password? |
| 14:51.08 | m0bius | or 404 on register? |
| 14:51.38 | gtjoseph | not on incoming calls |
| 14:51.51 | gtjoseph | although 401's are recorded as saecurity events |
| 14:52.13 | m0bius | I am under the assumption that 404s are also recorded but not entirely sure |
| 14:52.27 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:52.27 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:53.29 | m0bius | in any case, I argue that a LOG_NOTICE like the one you are getting on invalid extension is much more appropriate that just dropping the call |
| 14:57.34 | coreyfarrell | m0bius: I'm unsure the order of processing but LOG_NOTICE would be inappropriate if "tel:" is rejected early (like before endpoint matching). if unauthenticated SIP traffic could trip that condition then it would allow an attacker to spam the asterisk logs even and the admin could not prevent it (beyond firewall blocking of the source address). |
| 14:59.11 | m0bius | coreyfarrell: isn't a similar case when you get a brute force attack to guess a user's password via REGISTER or via digest authentication and you get the Wrong password notice? |
| 15:00.06 | m0bius | one could argue both ways on this |
| 15:00.26 | coreyfarrell | that would record to the security log, tools exist to monitor seceurity log and auto-ban. |
| 15:00.44 | m0bius | fail2ban could work on 416 as well |
| 15:09.18 | coreyfarrell | I will defer to others who are more invested in chan_pjsip, my opinion is that LOG_NOTICE is excessive for "tel:" rejections. I wouldn't argue against ast_debug, that way an admin can enable debug to troubleshoot those rejected calls. |
| 15:12.02 | m0bius | coreyfarrell: my initial attempt was to try and add tel: URI support to asterisk, as you can see from the patch. The notice/warning is the icing on the cake |
| 15:15.39 | gtjoseph | m0bius: your patch removed the check that prevents tel URIs from being accepted. What would we do with a tel: URI? |
| 15:16.41 | m0bius | gtjoseph: pjsip handles the tel: URIs. a call with a To: tel: URI after the patch is applied enters the dialplan in a similar fashion as a sip/sips URI |
| 15:17.10 | file | PJSIP may parse and provide the tel: URIs, but there is code in places in Asterisk which goes to get a URI and has to explicitly know what it is |
| 15:17.26 | file | every place like that has to be written correctly to handle the tel: scenario, or else it may crash |
| 15:17.46 | gtjoseph | not "may" but "will" :) |
| 15:17.53 | gtjoseph | that's why the checlk for tel: was added. |
| 15:17.59 | file | so while just removing the check may work for your configuration, that's not to say every place does it correctly |
| 15:19.48 | m0bius | file: do you have something specific in mind? because from what I've seen so far, asterisk handles the call as any other |
| 15:20.01 | file | not off the top of my head, but it has to be audited |
| 15:20.19 | file | just turning it off isn't acceptable without that because then you leave yourself open to a potential security vulnerability if one is missed |
| 15:20.29 | cresl1n | We had a security issue in the last year or so that caused that code to be added |
| 15:20.37 | m0bius | fair enough |
| 15:21.42 | m0bius | however from what I've seen so far, the only thing that's strange after applying the patch is that it quotes the ascii characters in the Remote-Party-Id and the P-Asserted-Identity if any |
| 15:21.43 | cresl1n | Somebody would need to go through, audit all the potential cases, and write tests for them for the testsuite, IMHO, to get that line removed |
| 15:21.57 | file | cresl1n: agreed |
| 15:22.09 | cresl1n | We don't like security issues :-( |
| 15:22.25 | m0bius | cresl1n: I'm glad you don't like them :) |
| 15:23.45 | m0bius | I agree it's the right way to go, sure. Do you remember the security issue you had that caused the tel: uri to be blocked? |
| 15:23.57 | cresl1n | not off the top of my head |
| 15:25.07 | gtjoseph | i did that one, just a sec. |
| 15:29.27 | gtjoseph | m0bius: https://issues.asterisk.org/jira/browse/ASTERISK-27152 |
| 15:30.49 | gtjoseph | https://downloads.asterisk.org/pub/security/AST-2017-007.html |
| 15:30.57 | m0bius | gtjoseph: ah wait, I noticed this as well. My first attempt was to allow tel uri in the is_sip_uri() method which caused asterisk to crash because the pjsip_sip_uri and the pjsip_tel_uri have the other_param on different places on their struct |
| 15:31.12 | gtjoseph | exactly |
| 15:31.35 | m0bius | my patch handles this properly and sanitize_tdata works propely on the other_param of pjsip_tel_uri |
| 15:32.02 | gtjoseph | how about the x-ast-txp parameter? |
| 15:32.21 | m0bius | gtjoseph: well in theory it should remove it from the other_param if it finds it there even in tel: uris |
| 15:32.57 | gtjoseph | you can test by turning on symmetric_transport on endpoints. |
| 15:33.43 | m0bius | gtjoseph: I will |
| 15:33.48 | coreyfarrell | cresl1n: allowing "tel:" will require also special consideration of future changes. auditing existing code is relatively easy compared to adding a new thing to worry about in future reviews. |
| 15:34.00 | cresl1n | Yep |
| 15:34.01 | file | indeed |
| 15:34.03 | cresl1n | this is true |
| 15:36.03 | m0bius | from my limited knowledge on pjsip however it seems that the authors of pjsip try to make the SIP/SIPS/TEL uri interchangable |
| 15:36.10 | coreyfarrell | I'd almost say that at most it should be possible to configure 'allow_tel_uri=1' and that the option would be disabled by default. I worry that "tel:" will never get enough exposure/testing to be more than an experimental feature. |
| 15:36.33 | file | they are not interchangeable in code |
| 15:37.16 | m0bius | coreyfarrell: well, here tel: weirdly is used by the largest operator on call forwarding (...) |
| 15:37.59 | m0bius | and I think it is common on softphones as well |
| 15:38.37 | file | I've rarely seen anyone talk about it |
| 15:38.48 | cresl1n | it comes up 1-2 times a year I think |
| 15:39.14 | cresl1n | that being said, if you would like to do the work to get it in m0bius, I have no problem with it :-) |
| 15:39.16 | m0bius | I didn't know that it was a case either, but found out the worst way |
| 15:39.37 | cresl1n | Just understand that there will be high expectations for tests and proof of non-crashiness in the code review process |
| 15:39.52 | cresl1n | if there's a way that it can be disabled by default, that would probably be desired as well |
| 15:40.23 | file | left out the "r" in proof and was amused |
| 15:40.33 | cresl1n | ha! |
| 15:41.02 | m0bius | I guess I could give it a go, it's been quite some time since I last touched asterisk codebase and alot have changed since :) |
| 15:41.11 | cresl1n | :-) |
| 15:41.49 | cresl1n | Go for it! |
| 15:44.09 | coreyfarrell | is res/res_pjsip/pjsip_resolver.c new to Asterisk 15 or was the code moved from another location? trying to apply a patch to 13. |
| 15:44.35 | file | it doesn't exist in 13 |
| 15:49.31 | coreyfarrell | thank you |
| 16:29.43 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:40.03 | jsmith | Is there a way from the CLI to check to see if res_resolver_unbound is being used as the DNS resolver, or is it used simply because it has been loaded? |
| 16:50.12 | file | there's a priority order, it spits it out at startup and you can deduce what is being used - but if it's loaded then it is used |
| 19:00.57 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-11898-144.w90-93.abo.wanadoo.fr) |
| 19:01.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-11898-144.w90-93.abo.wanadoo.fr) |
| 20:45.37 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LFbn-1-11898-144.w90-93.abo.wanadoo.fr) |
| 20:46.39 | *** join/#asterisk-dev GameGamer43_ (sid5533@gateway/web/irccloud.com/x-cazauhvbsvmualpi) |
| 20:46.40 | *** join/#asterisk-dev dan_j_ (sid21651@gateway/web/irccloud.com/x-kjnwopoiawkngyfv) |
| 20:56.23 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 20:56.23 | *** 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 |
| 23:27.22 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-xgyremabzjgaiqmx) |