| 00:18.23 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:18.23 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- 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 |
| 04:08.06 | *** join/#asterisk-dev jkroon (~jkroon@41.115.115.125) |
| 06:16.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:20.22 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:40.42 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:44.59 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:36.34 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 09:59.58 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 10:16.50 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 11:46.19 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 11:49.47 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:41.01 | tsearle | https://www.youtube.com/watch?v=1ANk_fzUKzM |
| 12:41.08 | tsearle | we all love garbage :D |
| 13:00.16 | file | seanbright: was that someone posting an ad on JIRA? |
| 13:00.39 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 13:00.48 | seanbright | it looked that way, yes |
| 13:00.54 | seanbright | i don't see how it related to the issue |
| 13:01.02 | seanbright | if i overstepped i apologize |
| 13:02.32 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 13:11.07 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 13:21.17 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-143-192.dialup.adsl.anteldata.net.uy) |
| 13:31.17 | *** join/#asterisk-dev scgm11__ (~scgm11@r186-49-60-145.dialup.adsl.anteldata.net.uy) |
| 13:48.01 | tsearle | hello, is there currently an equivelent of "opportunistic encryption" for outbound pjsip call legs? |
| 13:48.26 | file | the option enables it for outbund |
| 13:48.33 | tsearle | e.g. asterisk proposes dtls, 488 gets received, it sends an offer w/o crypto |
| 13:48.41 | file | oh you mean with DTLS |
| 13:48.41 | file | no. |
| 13:49.07 | tsearle | you mean SDES would send a new invite on 488? |
| 13:49.59 | tsearle | anyhow, I assum if I want to implement that, I need to make it a new flag like "opportunistic_encryption_outbound" |
| 13:50.52 | file | SDES does not send an INVITE with crypto as a requirement |
| 13:50.58 | file | so it would not get a 488 |
| 13:51.08 | file | opportunistic in general does not support DTLS |
| 13:52.00 | tsearle | it works find for inbound.... e.g. asterisk will not reject an unencrypted call |
| 13:52.27 | file | right, but it's not fully flushed out or supported |
| 13:52.27 | tsearle | it's only the outbound calling that has issue as far as my testing can tell |
| 13:53.05 | file | so such functionality would be DTLS in general, fully flushing it out in general |
| 13:53.13 | file | and there was a time where inbound did reject it |
| 13:53.53 | tsearle | my team may have been responsible for changing the inbound behaviour, heh |
| 13:54.34 | tsearle | any objections to implementeing the 488 reinvite outbound flow behind a new flag? |
| 13:55.05 | file | I'd check to see if there are actually RFCs first for the behavior to see how people recommend it is done first? |
| 13:55.23 | file | then otherwise a new flag is probably fine |
| 13:55.47 | tsearle | there are rfcs |
| 13:56.21 | file | I think there's already an ASTERISK issue too for this, so reaching out on -dev and it to see if it would work for the others interested would be good |
| 14:01.04 | tsearle | https://tools.ietf.org/html/rfc5479 |
| 14:01.10 | tsearle | A.5.3 |
| 14:02.33 | tsearle | the mention some more sophisticated alternative options |
| 14:03.03 | tsearle | but the do mention INVITE SAVP (rejected) INVITE AVP |
| 14:03.15 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-49-28.dialup.adsl.anteldata.net.uy) |
| 14:08.17 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 14:09.35 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-cbzwjhgpakweagvk) |
| 14:09.35 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:20.59 | file | *nod* |
| 14:25.50 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-hpfmsbpbaoczhsxk) |
| 14:25.50 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:09.40 | *** join/#asterisk-dev jkroon (~jkroon@41.115.3.125) |
| 15:31.57 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-49-28.dialup.adsl.anteldata.net.uy) |
| 15:54.07 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-49-28.dialup.adsl.anteldata.net.uy) |
| 16:36.32 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-49-28.dialup.adsl.anteldata.net.uy) |
| 16:55.14 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-49-28.dialup.adsl.anteldata.net.uy) |
| 17:04.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 17:36.15 | coreyfarrell | rmudgett: any objection if the NO_REF_DEBUG ao2_alloc option is for 16+ only? no part of that patch applies cleanly to 13. |
| 17:36.47 | rmudgett | no. I'm meh on backporting that change. |
| 17:39.45 | coreyfarrell | at this point I'm mainly backporting for 16/17 to avoid creating diff in main/astobj2* between branches but that ship has already sailed for 13 |
| 17:42.34 | coreyfarrell | rmudgett: outside astobj2 container nodes are you aware of any other places where reference logging was disabled with a NULL tag? |
| 17:42.54 | rmudgett | no |
| 17:43.26 | rmudgett | The logging was disabled on the container nodes because that is an internal implementation detail |
| 17:44.05 | *** join/#asterisk-dev Corydon76 (~quassel@96.69.98.139) |
| 17:44.05 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 17:48.10 | coreyfarrell | yes also container nodes actually see a huge amount of reference action. I think I tried making them enabled at one point, it made the refs log much larger and significantly increased time for refcounter.py to execute. |
| 17:51.44 | *** join/#asterisk-dev Corydon76 (~quassel@96.69.98.139) |
| 17:51.44 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 18:01.52 | rmudgett | All that logging for no benefit because the ao2 code "has no bugs". :D |
| 18:20.09 | coreyfarrell | anyone have an idea on https://gerrit.asterisk.org/#/c/asterisk/+/12903/? the frack looks like an unrelated module shutdown race. also not sure about the other failures, is testing normally stable these days? seems odd that I got different failures on 13 vs 16. |
| 18:20.36 | file | testing is wonky, sporadic repeated test failures |
| 19:45.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lfbn-1-9707-146.w86-236.abo.wanadoo.fr) |
| 19:46.42 | *** join/#asterisk-dev jkroon (~jkroon@41.115.113.120) |
| 19:50.52 | kharwell | coreyfarrell: I've seen that shutdown one before. Went ahead and created an issue for it: https://issues.asterisk.org/jira/browse/ASTERISK-28552 |
| 19:52.01 | coreyfarrell | kharwell: thanks.. have you ever seen it in 16+? |
| 19:56.37 | kharwell | I don't recall |
| 20:00.18 | coreyfarrell | only reason I ask is because 16+ is more aggressive than 13 with holding references to modules.. it's possible 16 could enforce a better unload order to prevent this. |
| 20:04.26 | kharwell | possibly, but after glancing at the res_pjsip_mwi code it looked like the only way that problem could have occurred is if during unload of that module it was still trying to send notifies |
| 20:07.51 | kharwell | Not sure about the other crash though on shutdown from master |
| 20:07.54 | kharwell | the one from https://gerrit.asterisk.org/c/asterisk/+/12902 |
| 20:08.22 | kharwell | don't think it's related to the change, but don't recall if I've seen that one |
| 20:18.08 | kharwell | issue created for that frack as well |