| 00:43.10 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 05:29.08 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-114-57-249.dhcp.davl.vt.charter.com) |
| 05:29.08 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 06:05.17 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.99) |
| 06:15.40 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.99) |
| 06:45.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.99) |
| 07:06.41 | *** join/#asterisk-dev electronic_eel (~quassel@HSI-KBW-46-223-65-185.hsi.kabel-badenwuerttemberg.de) |
| 07:12.19 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:29.34 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:34.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@92.184.100.66) |
| 07:45.48 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@249-47.206-83.static-ip.oleane.fr) |
| 08:27.24 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.62) |
| 10:02.03 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 10:10.56 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:58.12 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 11:12.56 | *** join/#asterisk-dev offbeatwitch (~offbeatwi@2001:bc8:4400:2300::1a:f05) |
| 11:17.52 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 11:17.52 | *** mode/#asterisk-dev [+o gtjoseph] by moon.freenode.net |
| 11:18.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@249-47.206-83.static-ip.oleane.fr) |
| 11:18.36 | *** join/#asterisk-dev electronic_eel (~quassel@HSI-KBW-46-223-65-185.hsi.kabel-badenwuerttemberg.de) |
| 11:18.36 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-114-57-249.dhcp.davl.vt.charter.com) |
| 11:18.36 | *** mode/#asterisk-dev [+o coreyfarrell] by moon.freenode.net |
| 11:19.05 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 11:19.05 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 11:22.51 | *** join/#asterisk-dev skrusty (~skrusty@88.150.145.104) |
| 11:22.51 | *** mode/#asterisk-dev [+o skrusty] by ChanServ |
| 11:56.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:21.51 | seanbright | why is the message channel change going into an RC? |
| 13:22.04 | seanbright | it's not a regression as far as i can see |
| 13:23.13 | seanbright | or is this one of those times where we ignore the rules because switchvox needs something? |
| 13:26.01 | file | we're cutting a certified off of 16.8, gjoseph proposed including the messaging change due to the low impact to ensure that things start out in sync already |
| 13:26.37 | file | due to the low impact of it and that it is backwards compatible, it seemed okay |
| 13:27.06 | seanbright | low impact and backwards compatible describes many of the changes that are made |
| 13:28.21 | file | we can undo it and put it into certified when it gets cut |
| 13:28.24 | file | gtjoseph: ^^^ |
| 13:28.41 | seanbright | either we stick to the policy or we change the policy |
| 13:29.20 | seanbright | but the fact that the lion's share of the exceptions are based or sangoma's business needs, it leaves a bad taste in my mouth |
| 13:30.46 | file | stabs commit length |
| 13:34.32 | seanbright | there is an errant quote at the end of the first line of the commit message in: https://gerrit.asterisk.org/c/asterisk/+/13752 |
| 13:35.11 | file | yeah I'm trying to fix it |
| 13:35.18 | seanbright | k |
| 13:40.05 | file | seanbright: thanks for your opinion! |
| 13:40.29 | seanbright | well you know what they say about opinions... |
| 13:41.50 | file | tastes like chicken? |
| 13:42.36 | seanbright | so then you don't know what they say about opinions :D |
| 13:42.46 | file | needs more oregano! |
| 13:57.07 | coreyfarrell | for what it's worth I agree with seanbright though I would not be in favor of changing the policy for what can go into the release branches (13.x / 16.x / 17.x), restricting to regression or security fixes only seems best to me. |
| 13:57.42 | file | it's worth plenty! I'll crack down on it and ensure it doesn't happen again |
| 14:00.38 | file | I'm losing the state of a stream and I don't know where... so odd |
| 14:03.52 | file | oh. |
| 14:04.38 | seanbright | coreyfarrell and i agree, this shit must be serious |
| 14:05.09 | coreyfarrell | seanbright: every once in a while you're correct :P |
| 14:05.22 | file | don't panic! |
| 14:05.38 | file | also: has anyone else noticed that the SDP attributes for stream state are all 8 characters? |
| 14:19.42 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 14:29.13 | file | reverted and gtjoseph is sorting out le releases |
| 14:31.09 | gtjoseph | you guys were hash, but correct. :) |
| 14:43.19 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:43.19 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:44.46 | cresl1n | waves |
| 14:46.38 | file | waves to cresl1n |
| 14:46.46 | cresl1n | file!!!!! |
| 15:27.04 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-kplitzaypbauuweu) |
| 15:27.04 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:30.31 | seanbright | question that i am sure i can get from reading code: |
| 15:30.52 | seanbright | when sorcery processes a configuration and 'applies' it - does the sorcery config object stick around in memory? |
| 15:31.29 | seanbright | that might be a non-sensical question |
| 15:31.57 | seanbright | i guess the configuration _is_ the sorcery object |
| 15:32.03 | seanbright | so the answer would be yes |
| 15:32.19 | file | depends on which you are referring to |
| 15:32.30 | gtjoseph | i think it depends on what the backend is |
| 15:32.40 | gtjoseph | as well |
| 15:32.58 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 15:34.31 | seanbright | i'll do a bit of experimentation and come back with questions |
| 15:35.21 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-kbisushkizqrncum) |
| 15:35.21 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:45.50 | file | seanbright: sorcery itself just handles the serialization/deserialization and provides a defined API, by itself it doesn't persist or keep things in memory |
| 15:45.56 | bford | looking at a backtrace for 13.28.1, but the arguments to a function in it are not matching up with the arguments in 13.28.1. only 2 things i could think of is the backtrace is not from 13.28.1, or they have a custom patch. anyone know of any possibilities i'm not thinking of? |
| 15:46.57 | gtjoseph | bford types or arguments or number of arguments? |
| 15:47.40 | kharwell | type of arguments. I went back and looked. The channel is null being passed in, but one/two of those functions haven't taken a channel parameter since before 13 |
| 15:48.18 | gtjoseph | that's odd. |
| 15:48.26 | kharwell | I too am perplexed at how that backtrace was obtained using the latest version of Asterisk |
| 15:49.08 | bford | just for reference: |
| 15:49.08 | bford | backtrace: #10 0x00007fdc00510dbc in local_attended_transfer (p=0x7fdc5030dee8, req=0x7fdbe7ffe090, seqno=4, nounlock=0x7fdbe7ffe038) at chan_sip.c:26854 |
| 15:49.08 | bford | 13.28.1: static int local_attended_transfer(struct sip_pvt *transferer, struct ast_channel *transferer_chan, uint32_t seqno, int *nounlock); |
| 15:49.58 | kharwell | Here's the issue with the bactrace if anyone else wants to look: https://issues.asterisk.org/jira/browse/ASTERISK-28721 |
| 15:50.06 | gtjoseph | i can look |
| 15:50.33 | kharwell | If one does a "core show version" and they are running a custom patched version that would show in the output right? |
| 15:51.04 | bford | if it doesn't, that would be a handy feature :D |
| 15:51.16 | file | it would |
| 15:51.24 | file | it adds a character to the version string to indicate it is modified |
| 15:54.03 | gtjoseph | just fyi guys... better backtraces only helps when we're generating a backtrace ourselves (a FRACK) |
| 15:54.24 | gtjoseph | no help at all when the OS generates it as a result of a SEGV, ABRT, etc. |
| 15:54.58 | file | odd |
| 15:57.02 | *** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/matrix.org/x-nrbfszvgqstlkasl) |
| 15:57.02 | *** mode/#asterisk-dev [+o danjenkins] by ChanServ |
| 15:57.12 | rmudgett | That's because gdb is generating the backtrace files not asterisk generating the assert backtrace. |
| 15:57.56 | gtjoseph | i'd push back on the reporter for this one. |
| 15:58.33 | gtjoseph | i'd also push back since it's chan_sip unless it's a regression. |
| 15:59.39 | coreyfarrell | for gdb DONT_OPTIMIZE could help |
| 15:59.49 | danjenkins | hello? |
| 16:00.15 | danjenkins | i should really stop using Riot/Matrix for IRC |
| 16:00.16 | file | hello |
| 16:00.43 | danjenkins | do i appear as danjenkins |
| 16:00.49 | danjenkins | or do i appear as some random |
| 16:00.55 | coreyfarrell | you are danjenkins |
| 16:00.57 | file | you appear as danjenkins |
| 16:01.20 | danjenkins | haha i remember this from last time..... riot makes it look like youre saying my proper username |
| 16:01.23 | danjenkins | but i still have no idea |
| 16:01.34 | danjenkins | nevermind... you know who i am |
| 16:01.39 | file | you are d-a-n-j-e-n-k-i-n-s |
| 16:01.59 | danjenkins | thanks file ! |
| 16:02.02 | danjenkins | how is everyone? |
| 16:03.03 | danjenkins | I do have a question regarding sending media back to asterisk via External Media.... are there docs somewhere that I missed on how much data I can send back at a time etc? |
| 16:03.30 | seanbright | 0 < amount of data you can send < infinity |
| 16:03.40 | file | I don't know if it's explicitly mentioned but it's an RTP stream, so it wants a stream - thus a timed stream |
| 16:03.43 | seanbright | i guess that first one should be <= |
| 16:03.53 | file | not a blob all at once |
| 16:03.57 | file | like a file |
| 16:04.29 | danjenkins | right, so i should send back x bytes at a time until my buffer is empty |
| 16:07.21 | file | right, generally a 20ms interval with 20ms payload in each is what most things do |
| 16:07.52 | danjenkins | thank you! |
| 16:08.42 | danjenkins | almost got my demo working for itexpo |
| 16:09.25 | danjenkins | seems like my udp forwarder doesnt forward the media back to asterisk... which is a slight problem |
| 16:09.38 | danjenkins | time to move the app to somewhere with an external ip |
| 16:16.00 | danjenkins | https://pasteboard.co/IT8ZCYF.png |
| 16:16.20 | danjenkins | progress |
| 16:16.28 | danjenkins | my loop is obviously completely wrong |
| 16:17.09 | seanbright | image not found |
| 16:17.12 | danjenkins | https://pasteboard.co/IT904wK.png (without a public ip in it) |
| 16:17.55 | *** join/#asterisk-dev jkroon (~jkroon@mail.ksm.co.za) |
| 16:18.20 | danjenkins | I had some code that did a similar thing for freeswitch/nexmo's Websocket interface |
| 16:22.23 | danjenkins | the SSL warning is confusing though |
| 16:23.27 | file | the payload is such that the demultiplexing is detecting it as DTLS sometimes |
| 16:25.16 | danjenkins | aahh ok |
| 16:38.31 | *** join/#asterisk-dev tmoore (~tmoore@2600:1702:4110:3d10:c14d:45f1:68b:a846) |
| 16:53.38 | tmoore | Hey Asterisk Dev's i'm working on updating an asterisk module to use astobj2.h and i'm wondering what work flow y'all use for debugging asterisk modules. Is there a way I can attach gdb to asterisk at the module execution? |
| 17:02.32 | kharwell | yes you can attach gdb to Asterisk, and it can be useful for some debugging scenarios. However, given that Asterisk multi-threaded, and in many places timing dependent you might have better luck adding extra logging. |
| 17:06.18 | tmoore | thanks for the respose, I think i'll start with valgrind and go from there |
| 17:12.51 | coreyfarrell | tmoore: if you are concerned about astobj2 leaks then enabling refdebug can give better info than valgrind. |
| 17:14.16 | tmoore | thanks for the advice corey, i'll try that first |
| 17:40.05 | danjenkins | well ive figured out i really dont know much about RTP internals |
| 17:43.51 | danjenkins | but i mean we all knew that anyway |
| 18:34.58 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 19:01.57 | *** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/matrix.org/x-nrbfszvgqstlkasl) |
| 19:01.57 | *** mode/#asterisk-dev [+o danjenkins] by moon.freenode.net |
| 19:02.05 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-kbisushkizqrncum) |
| 19:02.05 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 19:02.05 | *** mode/#asterisk-dev [+oo bford gtjoseph] by moon.freenode.net |
| 19:38.58 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.100) |
| 22:02.26 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 22:07.53 | tmoore | been pulling my hair out trying to track this bug down in my asterisk module.. `FRACK!, Failed assertion bad magic number 0x7fe` .. `# 0: asterisk(__ao2_unlock+0x75)`` |
| 22:09.08 | tmoore | am i just not understanding ao2_unlock()? ast_alloc() -> gives an obj with some semaphore i can unlock / lock right? |
| 22:10.17 | file | ao2_alloc will allocate an ao2 object with a mutex lock |
| 22:10.41 | file | but reference counting has to be maintained, or else the memory will be freed |
| 22:13.25 | tmoore | i only have one ref to the ao2 obj, I am just passing the same one around |
| 22:14.05 | file | either it's being destroyed early or the memory is being overwritten |
| 22:16.22 | file | or you're unlocking after it is destroyed or unlocking something that isn't ao2 allocated |
| 22:32.11 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:995e:331c:c341:871) |
| 22:33.57 | tmoore | doing some further investigated but its likely being overwritten |
| 23:31.48 | tmoore | are the write read locks mutually exclusive on ao2 objects? for instance, can i ao2_rdlock() and ao2_wrlock() before unlocking? |
| 23:36.44 | rmudgett | You have to create the ao2 object with rwlocks for ao2_rdlock/ao2_wrlock to work as read write locks. Otherwise they are just ao2_lock synonyms. rwlocks in asterisk are not reentrant. |
| 23:40.07 | tmoore | not seperate locks correct? like this: ao2_alloc_options(sizeof(struct stuff), NULL, AO2_ALLOC_OPT_LOCK_RWLOCK)) |
