| 00:12.12 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:12.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:12.49 | mjordan | file: coreyfarrell: ping |
| 00:13.00 | file | pong |
| 00:13.26 | mjordan | so, I'm looking at the code I wrote this afternoon, and I've littered chan_sip with a lot of format_cap clearings and other things to make sure that I don't duplicate formats in a format_cap structure |
| 00:13.38 | mjordan | that's "okay", but I imagine we're going to run into this problem elsewhere as well |
| 00:14.08 | file | aye |
| 00:14.21 | mjordan | generally, our channel drivers don't want two formats to exist in a cap structure |
| 00:14.29 | mjordan | regardless of attributes, framing, etc. |
| 00:15.04 | mjordan | so that would mean ast_format_cap_append should drop duplicates |
| 00:15.43 | mjordan | but duplicates in this case is a bit different than how we're currently handling it - where two formats that have different attributes are not technically equal. In this case, we'd want to consider that they are |
| 00:15.46 | mjordan | so I'm not sure. |
| 00:16.25 | file | you want two formats with same codec = same regardless of attributes, and noop |
| 00:16.34 | mjordan | yeah, but I'm not sure |
| 00:16.41 | mjordan | if we had capabilities structures per media stream, I'd feel fine |
| 00:16.43 | mjordan | but we don't |
| 00:16.52 | mjordan | which is kind of why we're in this mess |
| 00:17.01 | file | down the road it would be easy to change that... add a flag for format cap creation to remove that logic for stuff that can support it |
| 00:17.33 | mjordan | i.e., ast_format_cap_alloc(ALLOW_DUPS) |
| 00:17.38 | file | sure |
| 00:19.48 | mjordan | I'll poke at that this evening. Hopefully that will negate most of this chan_sip patch |
| 00:20.23 | mjordan | also: Darkman is on IFC! Apparently Liam Neeson really needed work |
| 00:20.54 | file | Live TV. How quaint. |
| 00:21.55 | mjordan | best part: they invented 3d printers. OOoooo |
| 00:22.49 | file | I only do 4D printers |
| 00:23.39 | gtjoseph | All printers are 4D. They exist in 3D space plus time. |
| 00:25.46 | mjordan | gtjoseph: +1 |
| 00:31.31 | file | putnopvut, documentation?!? say what |
| 00:33.03 | putnopvut | "what" |
| 00:34.56 | file | very good |
| 01:21.05 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 01:39.57 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 02:50.06 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 03:14.58 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 03:14.58 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 03:16.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:18.18 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:18.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:35.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 03:55.13 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 04:13.54 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:30.50 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 05:59.19 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 06:24.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f0d0:cc55:5276:912) |
| 06:25.05 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:18.18 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 07:30.43 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:30.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:32.54 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 07:38.27 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:38.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:02.55 | *** join/#asterisk-dev stevePearPear (~stevePear@183.90.37.169) |
| 08:28.52 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 11:16.33 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:03.51 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:16.07 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:25.27 | *** join/#asterisk-dev Dovid (~Dovid@ool-6bbc11ba.dyn.optonline.net) |
| 12:38.50 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:43.05 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:50.58 | file | hrm hrm hrm |
| 12:56.07 | opticron | cripes...just ran face-first into a race condition in the bridging core |
| 12:57.09 | opticron | if the swap channel involved in a push gets out of the bridge and destroyed fast enough, the bridge subclass push function gets NULL instead of the swap channel's ast_bridge_channel |
| 13:17.46 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:17.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:27.14 | mjordan | things are supposed to be handled atomically - why is the channel's ref count not bumped during the process? |
| 13:51.04 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-wdbslxegqnucvovi) |
| 14:07.33 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:07.52 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-cjqapcxtnbfllyfu) |
| 14:11.32 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:15.27 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-obamuddkkideztfb) |
| 14:15.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:16.13 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:16.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.15 | opticron | mjordan, it holds a reference to the channel, just not the bridge channel |
| 14:17.02 | opticron | so when it goes to call the subclass push callback, it tries to find the swap channel's ast_bridge_channel, comes up empty, and passes NULL into the subclass push function as the swap ast_bridge_channel |
| 14:19.22 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:19.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:26.04 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-hyhpsowojtmvodgs) |
| 14:26.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:29.36 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-psjcrshcqnuczkty) |
| 14:40.39 | mjordan | hm. |
| 14:41.02 | mjordan | Does the ast_bridge_channel's lifetime get determined by its presence in the bridge? |
| 14:45.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:55.37 | opticron | I think that's the problem, but without some deep digging I'll have to talk to rmudgett when he gets in |
| 15:18.36 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:40.18 | hexanol | Hi |
| 15:40.22 | hexanol | I'm wondering if this bug |
| 15:40.24 | hexanol | https://issues.asterisk.org/jira/browse/ASTERISK-21737 |
| 15:40.31 | hexanol | is fixed in asterisk 12 |
| 15:40.43 | hexanol | i.e. I know that there is some changed between asterisk 11 and 12 in how channels are bridged |
| 15:41.06 | hexanol | and this bugs happens because there's a masquerade happening during a bridge (among other things) |
| 15:41.32 | hexanol | hum... wrong bug... |
| 15:41.41 | hexanol | sorry, this is the right link: https://issues.asterisk.org/jira/browse/ASTERISK-21316 |
| 15:47.21 | mjordan | hexanol: welp. Depends. |
| 15:47.38 | mjordan | the answer is "you are almost never going to hit in 12" |
| 15:48.38 | hexanol | well, this already is not happening that often in asterisk 11 |
| 15:48.48 | hexanol | so, relatively, it would be even less frequent in 12 ? |
| 15:49.26 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 15:49.58 | mjordan | the masquerade that happens in the backtrace that Ashley has occurs during an asyncgoto from a bridge. That wouldn't occur in 12, as we wouldn't masquerade the channel out of the bridge. We'd simply tell it where to go, and let the bridge evict the channel |
| 15:50.18 | mjordan | his scenario for reproducing it won't happen in 12 |
| 15:51.08 | mjordan | hm. |
| 15:51.25 | mjordan | Actually, if the cause of it is ast_channel_bridge forwarding the DTMF, then no, it won't happen in 12 |
| 15:52.07 | mjordan | if you're in the middle of a pickup operation, we won't forward the DTMF: the channel that got masqueraded is about to get hung up completely, so we wouldn't care |
| 15:52.35 | mjordan | same with an attended transfer from an application. we won't attempt to complete the DTMF on a zombie channel |
| 15:53.06 | mjordan | the bridging framework, by and large, makes things a *lot* more stable in the core. |
| 15:53.09 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-vdclrtowugmasvul) |
| 15:53.12 | mjordan | despite opticron' |
| 15:53.20 | mjordan | despite opticron's race condition right now :_) |
| 15:57.10 | hexanol | ok, looks interesting, thank you for the explanation |
| 15:59.14 | mjordan | hexanol: np. We pretty much killed 90% of masquerades in 12 - and when they do happen, you won't see them. |
| 15:59.23 | mjordan | That eliminated a lot of nasty race conditions. |
| 15:59.50 | mjordan | file: coreyfarrell: I'm proposing we kill off test_format_api. It's pretty much covered by test_format_cache, test_core_codec, and test_core_format |
| 16:00.13 | mjordan | I'd rather make sure those three cover the APIs then pull along the older unit test module that is attempting to test all three of those areas |
| 16:00.35 | file | aye |
| 16:32.09 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 16:32.22 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 16:34.44 | mjordan | file: any reason why there is no ast_codec_unregister function? |
| 16:35.23 | file | it would be unlikely they could ever unregister safely? |
| 16:37.31 | mjordan | so, take hypothetical module codec_foo.so, where 'foo' is not a builtin codec |
| 16:37.51 | mjordan | If I perform a module load codec_foo.so, followed by an unload, then a load, what should we expect to happen? |
| 16:37.59 | mjordan | If I unload it, I don't want the codec to stick around |
| 16:38.37 | file | the problem is that if it creates a codec internally and that gets used to construct formats... then those formats have a ref to the codec |
| 16:40.16 | mjordan | I kind of wish we just bit the bullet and said 'formats and codecs have to be hard coded' |
| 16:40.22 | mjordan | because that's the effect anyway |
| 16:40.38 | mjordan | format modules + codec modules just provide the glue that make them do things |
| 16:40.41 | file | it's not - you can extend things but you can't change the environment at runtime |
| 16:40.57 | file | that's a poor way of saying it |
| 16:41.12 | file | you can't alter the environment when things are in operation using it |
| 16:41.21 | mjordan | making modules unloadable generally feels like we've got a problem |
| 16:41.35 | file | un-unloadable |
| 16:41.47 | mjordan | yes :-P |
| 16:42.45 | file | you either put everything in the core so the idea of loading/unloading doesn't exist or you provide the ability to extend things outside but not have them be unloadable |
| 16:42.47 | mjordan | If nothing else, codec.c should release things during shutdown |
| 16:42.54 | file | otherwise... stuff may go nuts |
| 16:44.12 | file | that should be safe |
| 16:44.33 | mjordan | alas, I think the codec modules will still get hosed up, since module shutdown happens before cleanups |
| 16:44.47 | mjordan | but it would be a small start. |
| 16:45.38 | mjordan | this also means none of the core codecs unit tests can be run twice, which is kind of ugly |
| 16:45.47 | mjordan | well... some can :-) |
| 16:45.56 | mjordan | just not the ones that check the return of the registration function |
| 16:54.59 | *** join/#asterisk-dev sgriepentrog (~sgriepent@173.209.212.242) |
| 17:04.56 | *** join/#asterisk-dev docelmo (18354422@gateway/web/freenode/ip.24.53.68.34) |
| 17:06.40 | docelmo | So question.. I have been looking at the source code and it appears it copies over the X headers on a 302 redirect except that in my instance I am sending back an additional X header in the 302 redirect message. Is there anyway to tell asterisk to grab the X header and put it in the invite message for the redirect destination? |
| 17:24.46 | *** join/#asterisk-dev spditner (~simon@76-10-182-232.dsl.teksavvy.com) |
| 17:33.17 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 17:42.28 | *** join/#asterisk-dev ipengineer_ (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 17:44.31 | putnopvut | docelmo: Unfortunately, the channel drivers don't have any knowledge of what the higher-level application is going to end up doing with the 302. If you wanted to do something like that, you'd need to modify app_dial (or whichever application is doing the dialing) to do that. Potentially, you could do that by saving the X-headers as channel variables and then copying the values from the first called channel to the second ca |
| 17:44.31 | putnopvut | lled channel in do_forward(). Then you'd need to modify whichever SIP channel driver you're using to take those channel variables and apply them as X- headers. |
| 17:47.34 | docelmo | interesting.. Thanks for the info.. I will take a look see.. Im hitting a road block with my project and this will help me work though it. |
| 18:20.35 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 18:36.23 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-snupxfbgqmmqucwd) |
| 18:38.42 | coreyfarrell | mjordan: I'm fine with death of test_format_api. once we get the full testsuite going with coverage report, that will show us anything we're failing to test. as for the un-unloadable modules, I'd prefer they use ast_register_cleanup |
| 18:44.06 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 18:50.40 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 19:06.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-74-62-142-170.west.biz.rr.com) |
| 19:07.53 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-uitimnxasherhean) |
| 19:13.34 | mjordan | coreyfarrell: cool, I'll work on that |
| 19:13.45 | mjordan | coreyfarrell: I'm expanding test coverage right now on the format attribute work |
| 19:16.52 | coreyfarrell | personally I'm more interested in testsuite coverage, since this is "real" usage of Asterisk. |
| 19:17.42 | mjordan | that's fair. I consider unit tests as 'future proofing' |
| 19:17.49 | coreyfarrell | I know getting coverage for certain things are a lot easier with unit test over testsuite, but testsuite is still better in my opinion |
| 19:18.56 | mjordan | coreyfarrell: any objection to removing test_format_api right now in the branch then? I can then focus on the crashes, as the rest of the test modules compile |
| 19:19.09 | coreyfarrell | none |
| 19:19.27 | mjordan | kk |
| 20:02.10 | mjordan | so... all of our crashes in the unit tests thus far have come from unit tests that create channels without any read/write capabilities |
| 20:02.22 | mjordan | the question is: do we go around fixing all of Asterisk that uses a NULL format? |
| 20:02.27 | mjordan | of which is there is ... a lot. |
| 20:02.37 | mjordan | or, do we assert early on a channel without any read/write? |
| 20:04.27 | mjordan | another possibility would be to create channels always with a slin format capability as their default... |
| 20:08.40 | coreyfarrell | what about an ast_format_none? |
| 20:08.46 | mjordan | hm. |
| 20:08.50 | mjordan | intriguing |
| 20:09.17 | coreyfarrell | I'm concerned that setting slin by default could leak into the codec negotiation process for real calls |
| 20:09.34 | mjordan | one of the more dangerous places this is happening is when ast_format_get_sample_rate gets called, which is scary since that can lead to a division by 0. |
| 20:10.15 | mjordan | ast_format_none could be interesting, along with a 'codec none' that basically does ... nothing. Transcodes to nowhere, etc. |
| 20:10.18 | mjordan | file: what do you think? |
| 20:10.39 | file | I... like it. |
| 20:11.16 | mjordan | there's a lot of assumptions that a channel has a format, that would keep us from having to NULL check the hell out of the code |
| 20:11.22 | coreyfarrell | I like ast_format_none much better than putting NULL checks everywhere |
| 20:11.34 | mjordan | k, I'll go down that path |
| 20:11.37 | mjordan | shouldn't be too hard. |
| 20:11.50 | mjordan | I'll have to wait on the format attribute stuff before putting it up for review |
| 20:53.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:53.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:07.32 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 21:07.32 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 21:51.07 | mjordan | \o/ CDR unit tests stopped crashing |
| 21:56.18 | TazzNZ | Hey guys - does Asterisk implement RFC6665 ? |
| 22:02.42 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-exubldgawvwiwumi) |
| 22:16.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-motknheoxywypzrz) |
| 22:16.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 22:17.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 22:17.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:17.11 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ypwlxcbuaavrzmqr) |
| 22:17.52 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-fbccegyggtyhgoay) |
| 22:18.46 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-xblmwvkpkhveodfd) |
| 22:43.25 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-fbccegyggtyhgoay) |
| 23:05.20 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |