| 00:03.31 | *** join/#asterisk-dev dandann00dle (uid120491@gateway/web/irccloud.com/x-ycwfldimpqmkumbw) |
| 00:47.48 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 02:58.57 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 04:03.46 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 04:56.10 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:01.46 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 05:51.28 | *** join/#asterisk-dev ksmutthu (~ksmutthu@106.51.241.133) |
| 06:07.49 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:07.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.32 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:50.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:52.37 | *** join/#asterisk-dev Suisso (~Suisso@110.167.63.81.static.wline.lns.sme.cust.swisscom.ch) |
| 06:57.38 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:57.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.12 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:22.04 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:31.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:34.10 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:34.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:51.37 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:12.49 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:32.13 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:42.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 08:51.35 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:41.42 | *** join/#asterisk-dev ksmutthu (~ksmutthu@106.51.241.133) |
| 12:05.45 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 12:35.38 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 13:15.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:15.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:17.26 | file | A wild putnopvut appears. |
| 13:18.54 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-uknfquhzevjeeiam) |
| 13:18.54 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:40.04 | file | gerrit seems to have survived the night |
| 14:07.53 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:07.53 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:09.24 | cresl1n | waves |
| 14:10.05 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-omuxygtcwsfknftu) |
| 14:17.24 | file | hola |
| 14:23.45 | cresl1n | file: does the bridging system have a callback or something to notify app_confbridge when a channel hangs up? |
| 14:24.14 | file | that's a silly question, of course it does :D |
| 14:24.22 | cresl1n | :-) |
| 14:24.23 | cresl1n | Thanks |
| 14:24.33 | cresl1n | I can't promise that my questions won't be silly |
| 14:24.36 | cresl1n | at least at first |
| 14:24.41 | cresl1n | but they'll improve with time |
| 14:24.46 | file | it's not exactly a callback though... although it may have something these days |
| 14:24.58 | file | but the channel is joined in a blocking fashion to the bridge, when the channel is hung up that returns |
| 14:25.07 | cresl1n | Ahhhh |
| 14:25.08 | file | or when it should leave the bridge |
| 14:25.25 | cresl1n | a la ast_bridge_channels() or whatever it used to be? |
| 14:25.36 | cresl1n | or ast_channel_bridge() |
| 14:25.40 | cresl1n | maybe that was it |
| 14:25.41 | file | ast_bridge_join |
| 14:26.11 | cresl1n | cool |
| 14:26.14 | cresl1n | that explains a lot |
| 14:26.32 | file | orly? |
| 14:26.44 | cresl1n | just for me understanding how confbridge works |
| 14:28.11 | cresl1n | I'm wondering if this only happens when the waitmarked-endmarked user leaves before teh endmarked user leaves |
| 14:28.38 | cresl1n | I need to check some successes on jenkins I think |
| 14:32.24 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:44.15 | coreyfarrell | in utils.h does anyone know why AST_INLINE_API is used for the allocators? does this really improve performance over normal functions? |
| 14:45.56 | file | no clue! |
| 14:48.02 | coreyfarrell | I was looking at that code last night to see if astmm.h could handle MALLOC_DEBUG on and off but the inline functions from utils.h use ast_log and other things that can't be available from astmm.h |
| 14:54.40 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 15:02.12 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:05.40 | *** join/#asterisk-dev raspberrypifan (~raspberry@cpe-69-204-233-226.nyc.res.rr.com) |
| 15:25.26 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-jdntrqtskgwquyio) |
| 15:45.07 | *** join/#asterisk-dev piling (~piling@unaffiliated/piling) |
| 16:04.42 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-15.wall.uls.co.za) |
| 16:31.18 | *** join/#asterisk-dev piling_ (~piling@unaffiliated/piling) |
| 16:56.36 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 18:13.27 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 18:26.33 | putnopvut | file: codec question. I'm testing codec_silk and am having crashes occur. The problem is happening in res_format_attr_silk.c. The silk_getjoint() function is pulling a NULL silk_attr structure from the passed-in format |
| 18:27.05 | putnopvut | I'm wondering what piece of the puzzle I'm missing in order for a format to end up with a silk_attr structure set as the format's attribute data? |
| 18:27.26 | file | attributes would have to be set on it if I remember right, if no attributes then no silk_attr |
| 18:27.34 | file | and no attributes you can assume to mean 'default' |
| 18:28.00 | putnopvut | when you say attributes would have to be set on it, do you mean like in the incoming SDP? |
| 18:28.31 | file | yeah, that should cause it to happen - the format attribute stuff would get called to parse, and would then need to create a new format with attributes on it |
| 18:28.40 | file | well - clone and set |
| 18:28.45 | putnopvut | hm, okay. |
| 18:29.09 | putnopvut | So I guess I just need to make silk_getjoint() NULL-tolerant, and to create some sort of "default" values for that case. |
| 18:29.21 | file | probably the safest bet! |
| 18:29.29 | putnopvut | And I guess making things NULL-tolerant, I guess that probably goes for other functions in that file. |
| 18:29.33 | file | you may also want to look at the SDP and see if there was anything to parse |
| 18:29.54 | file | although I suppose the built-in cached format would have no attribute |
| 18:29.58 | file | so yeah, NULL tolerant! |
| 18:34.16 | putnopvut | Yeah, the SDP had no fmtp stuff. It was just your typical rtpmap line. |
| 18:35.18 | file | ack ack |
| 18:54.21 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 19:03.00 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 19:34.43 | cresl1n | Hey everybody |
| 19:34.50 | cresl1n | waves |
| 19:35.35 | cresl1n | As far as procedures go, for someone to make a code contribution, is the procedure to open an issue on issues.asterisk.org and then create a code review on gerrit linking to it? |
| 19:35.49 | cresl1n | or can the issue be skipped and just create a code review on gerrit |
| 19:35.58 | cresl1n | pleasethanks. |
| 19:36.34 | cresl1n | Torrey was wondering about it |
| 19:38.18 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:45.13 | rmudgett | cresl1n: It is preferable to have an issue especially if it is fixing a bug or a new feature. Minor stuff doesn't necessarily need an issue. |
| 19:45.56 | rmudgett | Having an issue helps with code release announcements. |
| 19:47.53 | cresl1n | thanks rmudgett |
| 19:49.39 | rmudgett | cresl1n: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process |
| 19:50.58 | cresl1n | thanks rmudgett :-) |
| 19:57.34 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 20:27.53 | *** join/#asterisk-dev Gugge (gugge@92.246.2.105) |
| 20:28.42 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ecgvxggwzeycazer) |
| 20:31.30 | file | kharwell, never leave me again! |
| 20:36.11 | file | cries |
| 20:48.20 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-btvmlqhfgxjpsvnl) |
| 20:58.39 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:58.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:07.14 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ctnwjrhoeopxafnk) |
| 21:50.02 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 22:00.06 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 22:00.17 | file | cresl1n, we may be non-ABI compatible between 13.9 and 13.10 for codec modules |
| 22:00.42 | file | which is :( |
| 22:00.53 | cresl1n | what broke? |
| 22:01.01 | file | dunno! |
| 22:01.21 | file | well, I mean, loading a siren7 built on Malcolm's system on mine failed - as he built against 13.8-cert |
| 22:01.24 | file | and I was on 13 |
| 22:01.32 | file | which shouldn't fail |
| 22:01.49 | file | and a person filed an issue that his illegal codecs won't load under 13.10 rc |
| 22:01.59 | cresl1n | ooooh |
| 22:02.04 | cresl1n | classy with a 'k' |
| 22:02.13 | cresl1n | I don't know what might have broken it either |
| 22:02.14 | file | so we should try our g729 |
| 22:02.35 | file | gives cresl1n more work |
| 22:03.01 | cresl1n | your attempts can do nothing to the already huge pile of work that already have :-) |
| 22:03.07 | cresl1n | a mere drop in the ocean |
| 22:03.22 | cresl1n | s/that/that I/ |
| 22:03.27 | file | I'm sure I could... add more |
| 22:03.39 | file | accidentally volunteers cresl1n for marketing work |
| 22:05.06 | cresl1n | HOW DARE YOU! |
| 22:05.11 | cresl1n | Too late though |
| 22:05.31 | file | volunteers cresl1n for, uh, technical support |
| 22:05.45 | cresl1n | Been there and done that. Do your worst! |
| 22:06.37 | file | cresl1n, fine! YOU ARE HEREBY BANNED FROM TACO BELL |
| 22:06.45 | cresl1n | NOOOOOOOOOoooooooooooo! |
| 22:06.51 | cresl1n | Anything but that!!!!!!! |
| 22:07.04 | cresl1n | well played, btw |
| 22:07.50 | file | cresl1n, go home |
| 22:07.56 | cresl1n | how rude |
| 22:08.11 | cresl1n | sends file some spicy chicken nuggets in retribution |
| 22:08.18 | file | no thanks |
| 22:08.33 | file | you may consume on my behalf |
| 22:09.18 | rmudgett | Would loading a standard codec built on v13 into v13.8-cert be a valid test? |
| 22:09.32 | rmudgett | For your ABI issue? |
| 22:09.37 | file | it may or may not explode |
| 22:09.47 | file | it's another data point |
| 22:10.00 | rmudgett | It's something that can be diffed to see what changed. |
| 22:13.55 | cresl1n | in confbridge/conf_state_multi_marked.c, leave_marked() function |
| 22:14.18 | cresl1n | after a marked channel leaves the conference |
| 22:14.46 | cresl1n | and handling any endmarked channels |
| 22:15.11 | cresl1n | why would it add a waitmarked-endmarked channel to the waiting_list if it should just be kicking it anyways? |
| 22:16.05 | cresl1n | I think putnopvut ran from my quesiton |
| 22:16.07 | cresl1n | :-) |
| 22:16.31 | cresl1n | pokes rmudgett |
| 22:21.33 | rmudgett | Because that is a different user and it hasn't left yet. You just told it to leave. You didn't remove it. |
| 22:21.56 | cresl1n | pure endmarked users just get booted |
| 22:22.21 | cresl1n | they don't get added to the waiting_list |
| 22:22.48 | cresl1n | well, they both get the kicked flag set |
| 22:23.06 | cresl1n | it's just for combination waitmarked-endmarked users, they get moved back into the waiting_list as well |
| 22:23.14 | cresl1n | which seems orthogonal, but odd |
| 22:23.31 | cresl1n | if you're booting the channel anyways, who cares if it goes back on the waiting list |
| 22:24.20 | rmudgett | When that channel leaves it is going to remove itself from the waiting list. |
| 22:24.27 | cresl1n | ah... |
| 22:24.35 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 22:24.37 | cresl1n | didn't realize that was the expectation |
| 22:25.16 | rmudgett | You just told it to leave. It hasn't left yet. You are putting it into the state it was in when there were no marked users. |
| 22:25.42 | cresl1n | yeah, like I said, it seemed orthogonal for some reason, just odd that it mattered since it's leaving anyways |
| 22:25.48 | cresl1n | your explanation makes sense |
| 22:26.16 | seanbright | codec_g729a.so (the legal one) does crash latest 13 |
| 22:26.25 | cresl1n | osnap. |
| 22:26.29 | cresl1n | welp |
| 22:26.48 | seanbright | happened before Jun 13 |
| 22:27.03 | seanbright | because that is when i asked file: "any reason it would crash with 13 HEAD?" |
| 22:27.10 | seanbright | heh |
| 22:27.38 | file | yeah, Alexei determined the cause |
| 22:28.10 | seanbright | ah, ok cool |
| 22:28.42 | file | we'll figure out what to do |
| 22:28.58 | seanbright | i believe in you |
| 22:29.02 | seanbright | for the most part |
| 22:29.18 | file | seanbright, don't put all your belief in one person - that's what I always say! |
| 22:29.43 | seanbright | by 'you' i mean 'the wonderful digium and community developers' |
| 22:30.03 | file | I see how it is |
| 22:35.22 | file | offers seanbright a cookie |
| 22:49.16 | cresl1n | time to go |
| 22:49.19 | cresl1n | see you all laters |
| 22:49.24 | cresl1n | sends file a cookie |
| 22:49.30 | file | cheers |
| 23:06.22 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ctnwjrhoeopxafnk) |
| 23:24.08 | rmudgett | file: Looks like we're going to have to have a new internal ast_codec struct and an external ast_codec struct in order to hide the new format_name field. |
| 23:24.43 | file | LA LA LA NOT LOOKING TILL TOMORROW LA LA LA |