| 01:30.09 | file | la la la |
| 02:13.02 | *** join/#asterisk-dev leedm777 (~textual@50-81-28-152.client.mchsi.com) |
| 02:48.19 | *** join/#asterisk-dev leedm777 (~textual@50-81-28-152.client.mchsi.com) |
| 03:53.37 | *** join/#asterisk-dev klow (~textual@c-67-161-106-89.hsd1.wa.comcast.net) |
| 04:18.23 | *** join/#asterisk-dev klow (~textual@c-67-161-106-89.hsd1.wa.comcast.net) |
| 05:11.47 | *** join/#asterisk-dev snuff-work (~snuff-wor@203.87.61.22) |
| 05:11.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:47.57 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-gbndliwleiuwjtkg) |
| 06:04.47 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:25.25 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:26.23 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 06:57.46 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 07:10.02 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:18.23 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:25.47 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 07:33.09 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:33.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:38.33 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 08:02.07 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 08:09.42 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:50.22 | *** join/#asterisk-dev stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 10:58.20 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 12:02.26 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:e059:1dac:6198:844e) |
| 12:02.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:35.44 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.182.47) |
| 12:41.42 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:41.42 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 12:59.43 | file | moo |
| 13:02.52 | *** join/#asterisk-dev kharwell (~kharwell@2606:4100:3880:2520:dc24:fe07:8e13:8c2) |
| 13:14.53 | file | hrm hrm hrm |
| 13:21.24 | cresl1n | ? |
| 13:21.29 | cresl1n | waves |
| 14:12.39 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:e059:1dac:6198:844e) |
| 14:12.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:27.05 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-czfrcrhwmtacgrgd) |
| 14:55.42 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-zsnvzksjqwxjcmjl) |
| 15:08.49 | *** join/#asterisk-dev oej (~oej@132.177.252.151) |
| 15:08.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:16.57 | file | I have a problem. I haven't found any new bugs today. |
| 16:18.35 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 16:33.09 | Marquis42 | file: LOL, "problem" eh? ;) |
| 16:33.39 | file | Marquis42, yes |
| 16:38.43 | Marquis42 | To be fair, you're in the right place where you'd prefer to be finding bugs/interoperability issues. But it's just funny to hear someone say they didn't find a bug. :) |
| 16:39.19 | *** join/#asterisk-dev kharwell (~kharwell@2606:4100:3880:2520:dc24:fe07:8e13:8c2) |
| 16:39.59 | file | Marquis42, I found bugs - just not in our stuff |
| 16:40.56 | Marquis42 | haha |
| 16:48.38 | X-Rob | Damn pjsip, stop being so correct. |
| 16:49.28 | X-Rob | file: Do you guys have some sort of test queue_log? Something log, annoying, complex, and filled with edge cases? I'm writing something to make it more human readable, and I don't want to have to recreate the wheel i fyou guys already have one somewhere |
| 16:49.38 | X-Rob | something LONG, annoying... |
| 17:04.36 | file | X-Rob, anything would be in the testsuite |
| 17:04.48 | X-Rob | file: yeah, there's not. Ah well |
| 17:13.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0068187bc1ab520b59.ipv6.abo.wanadoo.fr) |
| 17:26.23 | *** join/#asterisk-dev newtonr (~newtonr@173-21-146-94.client.mchsi.com) |
| 17:26.23 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:33.23 | file | UDP is lame. |
| 17:38.33 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:994f:fa08:239b:ce33) |
| 17:38.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:05.59 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-iftfagewnciikbcw) |
| 18:07.46 | DivideBy0 | UDP doesn't acknowledge you |
| 18:07.49 | file | rmudgett, you can't add/update that |
| 18:07.57 | Marquis42 | DivideBy0: lol |
| 18:07.58 | file | rmudgett, the first payload in the SDP is the one that is allowed |
| 18:08.07 | file | that's what they prefer |
| 18:08.54 | rmudgett | And if its 100 when they have 96 after? |
| 18:09.09 | file | I don't understand the question, you'll need to be specific |
| 18:09.16 | rmudgett | I put the example in the finding. |
| 18:09.40 | file | in a re-invite? |
| 18:09.52 | rmudgett | The current SDP processing. |
| 18:10.04 | file | that doesn't answer the question |
| 18:10.11 | file | are you referring to an initial INVITE, or a re-invite afterwards? |
| 18:11.25 | rmudgett | We are processing the SDP. Whether it is the initial or reinvite doesn't matter because we are creating a new tx mapping. |
| 18:11.39 | file | yes. |
| 18:11.39 | rmudgett | They prefer 100 first before they prefer 96 |
| 18:11.43 | file | yes. |
| 18:12.20 | file | when the 96 is processed the codec ID would match, the payload value would not match, and it would return as a payload mapping existing |
| 18:13.20 | rmudgett | You need to take both findings together. |
| 18:13.50 | file | why... |
| 18:18.41 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:3979:3391:8ae:8c18) |
| 18:18.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:20.22 | rmudgett | Is it allowable to specify 96 twice? |
| 18:20.36 | rmudgett | m=... 100 96 96 |
| 18:20.40 | file | no |
| 18:21.05 | rmudgett | Is the case caught? |
| 18:22.41 | rmudgett | Or repeating a=rtpmap: 96 opus and later a=rtpmap: 96 alaw ? |
| 18:23.32 | file | we wouldn't answer twice, I don't know if the SDP validator would allow that in PJSIP land, the second would replace the first |
| 18:25.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@136.61.225.198) |
| 18:26.13 | rmudgett | Is a=rtpmap: 100 supposed to appear before a=rtpmap: 96? |
| 18:26.37 | file | doesn't matter |
| 18:27.10 | rmudgett | It will when we are creating the tx mapping. |
| 18:27.29 | rmudgett | With m=.... 100 96 |
| 18:27.57 | rmudgett | If a=rtpmap: 96 appearing first it would get in the table first and block 100 |
| 18:28.40 | rmudgett | Or does our code look for the rtpmap 100 first because the m= line put it first. |
| 18:30.15 | file | it looks for rtpmap explicitly when processing the format list |
| 18:38.03 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-vjrrdrgjksbjwzky) |
| 18:39.33 | rmudgett | Looks like chan_sip may get tripped up by the a=rtpmap ordering. |
| 18:41.44 | *** join/#asterisk-dev oej (~oej@132.177.252.151) |
| 18:41.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:42.30 | file | yay. |
| 18:42.51 | file | as long as we're not broken like now :P |
| 18:44.03 | rmudgett | Part of that may be because we removed the static dynamic payload type assignments. |
| 18:48.36 | rmudgett | How about m=... RTP/AVP 0 96 with a=rtpmap:0 opus a=rtpmap:96 ulaw ? |
| 18:50.12 | rmudgett | Make that m=...RTP/AVP 96 0 with a=rtpmap:96 ulaw and a=rtpmap: 0 opus |
| 18:52.39 | file | ... |
| 18:52.56 | file | k, so, I have no idea what opus with 0 would do because that is outside the scope of this change |
| 18:54.38 | rmudgett | Looks like it would work in pjsip and get chan_sip confused |
| 19:04.15 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:04.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:07.13 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:b8c2:5393:762a:f03b) |
| 19:07.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:07.36 | *** join/#asterisk-dev kharwell (~kharwell@132.177.252.51) |
| 19:09.42 | rmudgett | file: Updated review |
| 19:10.42 | file | I'll fix it when I'm not in the middle of adding oppurtunistic DTLS-SRTP support |
| 19:10.48 | file | unless you want to :P |
| 19:22.00 | X-Rob | MOAR SECURITY |
| 19:22.38 | X-Rob | file: please do the needful |
| 19:27.00 | rmudgett | kharwell: You and I stepped on each other |
| 19:27.15 | file | :D |
| 19:28.56 | kharwell | rmudgett: oops! |
| 19:31.50 | rmudgett | +1ed now |
| 19:36.05 | acidfu_ | is there a way with the asterisk CLI to lookup the realtime peer backend ? to print some info on the cli ? |
| 19:36.07 | acidfu_ | THANKS |
| 19:36.09 | acidfu_ | oups, thanks |
| 19:55.39 | *** join/#asterisk-dev oej (~oej@132.177.252.151) |
| 19:55.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:05.06 | *** join/#asterisk-dev oej (~oej@2606:4100:3880:2520:d9b7:6301:6fe1:1b85) |
| 20:05.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:31.07 | *** join/#asterisk-dev oej (~oej@132.177.252.151) |
| 20:31.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:47.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:47.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:56.45 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-urzekxcryucsefit) |
| 22:13.26 | coreyfarrell | rmudgett: ping |
| 22:13.41 | rmudgett | coreyfarrell: pong |
| 22:14.42 | coreyfarrell | for the backtrace on invalid ao2 object, I was thinking of making __ast_assert_failed always compile, and create a macro like ast_assert_always() |
| 22:15.37 | rmudgett | Assertions are debugging statements. They should not always be active. |
| 22:15.47 | coreyfarrell | that way instead of ast_assert(0) for the places in ao2 where we want backtrace, we end up running ast_assert_failed for the FRACK logger message and backtrace |
| 22:16.52 | coreyfarrell | ast_assert would still only be for --enable-dev-mode |
| 22:17.25 | rmudgett | I was just suggesting that log_bad_ao2() call ast_log_backtrace() and then it should usleep(1) like ast_assert_fail |
| 22:21.23 | rmudgett | The bad ao2 would always provide a backtrace because NULL ao2 objects or bad ao2 objects usually need a backtrace to make sense when they happen. |
| 22:21.23 | coreyfarrell | in almost all cases that log_bad_ao2 is run we also end up running ast_assert(0), I was just thinking we shouldn't make dev-mode print each backtrace twice |
| 22:23.16 | rmudgett | I don't think the assert is always done if the log_bad_ao2() is called. |
| 22:24.15 | rmudgett | The calls are separated by different locations in the code. |
| 22:26.16 | rmudgett | What you are thinking would take some code rearangement to avoid the duplicated backtraces due to the bad ao2 call and the assert. |
| 22:35.11 | coreyfarrell | the cheap/lazy solution would be to call ast_log_backtrace() from log_bad_ao2() only when !defined(AST_DEVMODE). |
| 22:37.04 | coreyfarrell | since the most important code paths do call ast_assert(0) after log_bad_ao2 is called, we can add it where it's missing & desirable. |
| 22:38.02 | rmudgett | Most of the places where the check is done but an assert isn't is with the weak proxy code. :) |
| 22:38.53 | rmudgett | That conditional sounds ok to me. |
| 22:39.48 | coreyfarrell | I have no objections to adding asserts to weak proxy code. but back to my original point we could easily just call __ast_assert_failed from log_bad_ao2, get rid of the ast_assert(0) from callers. |
| 22:40.11 | rmudgett | __ao2_ref doesn't call the assert until after it has logged an invalid reference attempt. |
| 22:42.26 | coreyfarrell | crazy thought, if we hit log_bad_ao2 with user_data != NULL why don't we log the invalid reference attempt there? it's still an invalid reference from __ao2_lock |
| 22:44.42 | rmudgett | I think removing the assert and moving it to log_bad_ao2() is ok. The __ao2_ref logging would still happen only if the assert doesn't abort asterisk. |
| 22:46.12 | rmudgett | If the assert aborts asterisk, the invalid logging to the ref log isn't that critical anyway. |
| 22:46.13 | coreyfarrell | and if DO_CRASH is enabled then coredumps should also be enabled so that invalid to ref log wouldn't be that important. |
| 22:47.08 | rmudgett | We seem to be on the same page now. |
| 22:48.12 | coreyfarrell | thanks for the talk, I'll get something together for this in the next day or two. |
| 22:49.09 | rmudgett | I think this should happen for v13+ as v11 is about to go into security fix only mode. |
| 22:49.35 | coreyfarrell | good I really didn't feel like dealing with 11 :) |
| 22:50.04 | coreyfarrell | one more question, what is the purpose of printing p->priv_data.magic when we know p is an invalid pointer? |
| 22:50.23 | coreyfarrell | in log_bad_ao2.. |
| 22:51.12 | rmudgett | With MALLOC_DEBUG the magic number would be 0xdeaddead |
| 22:51.23 | rmudgett | likely be |
| 22:52.22 | rmudgett | If it is deaddead then you know that the object has been destroyed. If it is something else then you have some random pointer. |
| 22:52.54 | rmudgett | Its just a potential useful bit of information. |
| 22:54.12 | coreyfarrell | got it thanks |
| 22:58.33 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-hrmhknwpnlntbued) |
| 23:17.11 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-pchrjkwstiizswqn) |