| 00:00.59 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:c01:4dce:b102:6c39) |
| 00:00.59 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 00:41.22 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@wsip-98-179-138-226.ri.ri.cox.net) |
| 00:41.22 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 00:57.32 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:f9d6:310e:20e5:e6b) |
| 00:57.32 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:07.11 | coreyfarrell | gtjoseph: I just created a ticket for re-implementing jenkins REF_DEBUG tests and assigned it to you. if you don't want it feel free to unassign yourself. |
| 01:07.47 | gtjoseph | no problem |
| 01:09.28 | coreyfarrell | my guess is as-is about 45% of tests/channels/pjsip would pass.. asterisk still needs a couple patches before we can get higher success. |
| 01:10.36 | coreyfarrell | BTW I think the shutdown delay might have to be 33 seconds (timer_t1 * 64 + 1 second). I tried reducing t1 but that caused some tests to fail. |
| 02:36.53 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 03:08.29 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 03:08.30 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 03:35.44 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 04:52.23 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 06:34.58 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 06:55.00 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:55.00 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:59.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:10.02 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:38.42 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:07.05 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 08:08.39 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 08:25.49 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 08:26.25 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 09:27.45 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 09:27.54 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 10:46.25 | *** join/#asterisk-dev stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 11:54.22 | tsearle | good afternoon all! |
| 12:04.20 | gtjoseph | hey tsearle! |
| 12:13.11 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:3461:8f27:ee76:90d3) |
| 12:13.12 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:14.06 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 12:30.37 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 12:45.30 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 12:47.12 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 12:54.41 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 12:59.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:05.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:08.35 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:19.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:41.33 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-dvcqacbrfzbnmxiu) |
| 13:41.33 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:50.31 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 13:50.31 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 13:58.55 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-eerwjaezyxjcfvnp) |
| 13:58.55 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:01.03 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 14:01.03 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:01.45 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:02.36 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-umihnmruxvsasgyh) |
| 14:02.37 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:14.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:24.30 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:26.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:27.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:28.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:35.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:39.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:41.24 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-zkoctavbzskpsapf) |
| 14:41.24 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:47.53 | coreyfarrell | file: if the sorcery or named_locks reviews fail jenkins I'd prefer we investigate / regate. I don't mind that you skipped regate for the ao2_weakproxy_find, that hasn't effected anything yet. |
| 14:48.26 | file | I look at the failures, there's certain ones that continually bounce and fail |
| 14:48.58 | file | but if you want to lead on that go ahead |
| 14:52.41 | coreyfarrell | if a chan_sip test fails I'll ask you to skip, but for any pjsip test I'll regate. |
| 15:17.19 | coreyfarrell | file: https://gerrit.asterisk.org/6743 has a failure unrelated to the patch being tested, but it was a segfault in tests/channels/pjsip/publish/asterisk_event_devicestate. |
| 15:18.10 | coreyfarrell | I'll open a JIRA ticket for that, do you want to +2 the change since it can't have anything to do with that failure? |
| 15:19.31 | file | That's due to the system shutting down |
| 15:19.50 | file | Your clean up the world at shutdown changes have caused a lot of that |
| 15:19.56 | file | From months ago |
| 15:20.38 | file | I'm walking down the street so can't touch it right now |
| 15:33.06 | file | done |
| 15:33.48 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 15:38.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:39.15 | AsteriskRoss | Hi All, I've been looking into the issue ASTERISK-27230, I think it has to do with realtime endpoints being removed from the database and the tasks persisting and the trying to access the endpoint data, which is no longer there |
| 15:41.00 | coreyfarrell | I suspect the shutdown failures are due to other leaks happening. unfortunately that test failed on my system last night (it didn't get any matching AMI events) so I'm not sure if it leaks when the test actually runs. |
| 15:42.16 | coreyfarrell | file: about the changes to clean up the world, are you talking about months ago when I tried to get res_pjsip to shutdown? or something I did to the asterisk core? |
| 15:42.44 | file | I believe changes when you tried to get res_pjsip to shutdown, but I don't recall precisely |
| 15:44.08 | coreyfarrell | so if that was a problem before a couple days ago then it isn't the cause.. the circular loop between res_pjsip and res_pjsip_session prevented the module_unload from ever running. |
| 15:44.45 | file | it's too long ago for me to remember |
| 15:47.58 | AsteriskRoss | When tasks are fired, do they require a valid contact? At present we do not remove any contacts from the sorcery cache, so in theory the task could see the contact and then act on it even though the endpoint has been removed. The contact should however expire based on the standard timers |
| 15:50.13 | file | tasks keep references to things underneath so they can't go away, and the backtraces you've provided don't show anything like that - the backtraces show a PJSIP timer being executed that has been destroyed |
| 15:51.39 | AsteriskRoss | Oh, that's not good |
| 15:52.21 | AsteriskRoss | The task appears to return but asterisk crashes when accessing ret = std->fail; |
| 15:52.35 | file | none of the backtraces on the issue show anything like that |
| 15:53.25 | AsteriskRoss | ok, that's whats on line res_pjsip.c:4207 |
| 15:54.17 | file | ok? |
| 15:54.53 | file | that doesn't actually match with the backtrace, fyi |
| 15:55.22 | file | line 4207 in the backtrace is in the monitor_thread_exec function |
| 15:56.27 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 15:58.15 | AsteriskRoss | It looks like i was looking at the latest commits and not the one that is running, your correct of course. |
| 15:59.02 | AsteriskRoss | If the task has been destroyed, what could make it run? |
| 15:59.12 | file | it's not a task |
| 15:59.14 | file | it's a PJSIP timer |
| 15:59.54 | file | it was scheduled to execute at some time, but was seemingly destroyed already when it ran |
| 16:00.03 | file | what the timer was for, why it wasn't removed, dunno |
| 16:00.19 | file | well - based on the function it executed you can tell what it was for, it was a transaction timer |
| 16:00.34 | file | (at least in some of them) |
| 16:01.10 | AsteriskRoss | ok, its causing multiple asterisk servers to crash multiple times a day. is there anything I can do to gather more information and get the issue resolved? |
| 16:02.17 | file | adding more information wouldn't alter getting the issue resolved, unless you found interest from someone to actively work on it or hired someone |
| 16:03.29 | AsteriskRoss | I'm happy to offer a bounty |
| 16:03.57 | file | the process for offering a bounty is on the wiki |
| 16:04.46 | AsteriskRoss | Thank you for your help, I've updated the issue tracker. Fingers crossed I can find someone to work on it! |
| 16:08.47 | seanbright | kharwell: re: 6670 |
| 16:09.22 | seanbright | well, maybe i understand |
| 16:09.41 | seanbright | session->save_from_hdr is the pre-anonymized URI? |
| 16:09.56 | kharwell | yeah |
| 16:09.58 | seanbright | and i assume somewhere we copy that back? |
| 16:10.01 | seanbright | on rx? |
| 16:11.26 | kharwell | I don't think it gets copied back. If I recall it's used later for pai stuff |
| 16:12.24 | seanbright | gotcha |
| 16:12.25 | seanbright | ok |
| 16:14.29 | file | seanbright: *cough* I just abandoned DUNDi IPv6 |
| 16:22.13 | kharwell | file: should the other patches in a similar situation (>=1 month with findings and no response) also be abandoned? |
| 16:22.39 | file | yes, unless they're small findings and we want to just do the change |
| 16:26.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 16:27.10 | kharwell | 6307 sounds easy enough (just a blurb in CHANGES) if we're all fine with no test |
| 16:28.57 | gtjoseph | seanbright: do you think you'll be able to spend any time on the ephemeral patch in the next few days? We're gonna be cutting rc1's for all 3 branches in the next few day. |
| 16:29.24 | file | I'd rather we try to not cram even more stuff into these releases |
| 16:29.47 | kharwell | ya hoping to do the rc1 either later today or tomorrow at the latest |
| 16:30.14 | file | to provide context: 13.17.0 tagged July 12th |
| 16:30.22 | file | that's... awhile ago... |
| 16:30.24 | gtjoseph | ok, was just trying to get a feel |
| 16:30.51 | gtjoseph | since the patches were already up |
| 16:30.56 | file | we'll hopefully be back on track so it won't take as long for stuff to trickle in |
| 16:31.33 | file | dreams the dreams |
| 16:47.26 | seanbright | gtjoseph: today? no. the next few days? probs. |
| 16:47.52 | gtjoseph | ok, will have to wait for next go around then. |
| 16:48.05 | seanbright | k |
| 17:23.43 | rmudgett | wonders if https://gerrit.asterisk.org/#/c/6765/ and https://gerrit.asterisk.org/#/c/6766/ should be squashed together or not since they logically should be the same change. https://gerrit.asterisk.org/#/c/6766/ is an arbitrary extraction to try to shrink the larger review. |
| 17:24.31 | rmudgett | gtjoseph: file: Opinion? ^^ |
| 17:24.48 | gtjoseph | looks |
| 17:27.05 | gtjoseph | i think they're fine. 6766 has 6766 as its parent so no sense in messing with them. |
| 17:27.16 | gtjoseph | oops 6766 has 6765 |
| 17:49.20 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00bcdcbb5073083d27.ipv6.abo.wanadoo.fr) |
| 17:51.26 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 17:51.26 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 17:52.19 | seanbright | ohhh, cdr optimizations <3 |
| 17:58.34 | rmudgett | I didn't get as much as I thought adding the new party b keyed container. I got more by not setting the stringfields and fixing the dnid, callingsubaddr, and calledsubaddr CDR variables. |
| 17:59.50 | coreyfarrell | rmudgett: are those patches not in a series? gerrit saying they conflict. |
| 18:00.12 | rmudgett | They are in a series. |
| 18:01.34 | rmudgett | I've been dribbling out the other CDR patches I didn't want in the series all week. :) |
| 18:54.33 | JunK-Y | in ast_rtp_read(), if we pass the if block `if (ast_rtp_instance_get_bridged(instance) && !bridge_p2p_rtp_write(instance, rtpheader, res, hdrlen)) {` is that what is considered as transcoding, since the local bridge can't happen? |
| 18:55.14 | file | no, transcoding does not happen within res_rtp_asterisk |
| 18:55.30 | file | p2p bridging is just an internal optimization to reduce the amount that the packet is touched |
| 18:56.06 | JunK-Y | and that optimization appeared in *-11? |
| 18:56.22 | file | I don't recall how long ago, but maybe |
| 18:59.37 | rmudgett | It was in v1.4 maybe earlier. |
| 19:00.15 | rmudgett | That is the local bridge. |
| 19:01.25 | rmudgett | For RTP, you can have frames going through the core, locally bridged in RTP code, or remotely bridged between devices. |
| 19:01.51 | rmudgett | The remote bridge is direct media. |
| 19:04.03 | rmudgett | Only the core transcodes media to other codecs. |
| 19:04.05 | JunK-Y | yes, i got that part. im looking at the optimization (local bridge) |
| 19:04.33 | JunK-Y | whats the path from ast_rtp_read() to the transcoding? |
| 19:05.26 | file | frames are read using ast_read, which calls into the channel driver, which calls into RTP to read a frame, before ast_read returns it can transcode the returned media into a different format |
| 19:05.49 | file | same goes for ast_write, it can transcode before passing it to the channel driver |
| 19:09.59 | seanbright | rmudgett: what are the specs of your slow test box? |
| 19:11.13 | rmudgett | Its a 10 year old Dell Vostro 200. |
| 19:12.26 | seanbright | cores? |
| 19:12.30 | seanbright | ram? |
| 19:14.34 | rmudgett | 2 cores, 1G ram. don't remember clock, kubundu 10.4 |
| 19:14.54 | seanbright | good deal |
| 19:19.48 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 19:19.49 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:33.03 | JunK-Y | file: thanks. |
| 20:46.03 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 20:46.03 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:09.19 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:20ef:e802:71da:94d0) |
| 22:09.19 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:30.24 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-umihnmruxvsasgyh) |