| 00:15.10 | file | meep meep |
| 00:37.09 | TazzNZ | <insert sound the road runner made? |
| 00:37.13 | TazzNZ | doh - fail |
| 01:27.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:42.57 | *** join/#asterisk-dev stevePearPear (~stevePear@nusnet-228-27.dynip.nus.edu.sg) |
| 02:12.24 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.87.131.147) |
| 03:04.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:40.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 04:37.25 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 05:15.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:26.00 | *** join/#asterisk-dev stevePearPear (~stevePear@nusnet-75-9.dynip.nus.edu.sg) |
| 05:38.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:48.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 06:32.48 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 06:32.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:33.58 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4cc8:bc12:c902:c861) |
| 07:22.00 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 07:22.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:26.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 07:29.48 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 07:29.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:31.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:31.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:32.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 07:53.43 | *** join/#asterisk-dev tgu (~tgu@host-212-68-194-46.brutele.be) |
| 08:32.22 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 09:33.32 | *** join/#asterisk-dev stevePearPear (~stevePear@nusnet-142-146.dynip.nus.edu.sg) |
| 11:15.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 11:19.56 | file | la la la |
| 11:48.27 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-kryvysbohzznhske) |
| 12:14.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 12:24.07 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:24.45 | *** join/#asterisk-dev oej (~Adium@host-95-195-147-174.mobileonline.telia.com) |
| 12:24.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:24.51 | oej | Hello folks |
| 12:37.51 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:39.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 12:54.58 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 12:54.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:47.46 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-zeoftdxqfyjnisgw) |
| 13:48.03 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 13:48.43 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:48.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:50.59 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:50.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:52.29 | *** part/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:110e:b5d:7dfd:e460) |
| 13:52.45 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:110e:b5d:7dfd:e460) |
| 14:20.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-vkkowwpdbzvshogc) |
| 14:20.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:21.04 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:21.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:56.11 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-svsogzdyofwmxrsm) |
| 15:07.23 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:42.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 15:44.24 | mjordan | Qwell: taco truck at 11:30? |
| 15:44.39 | jsmith | mjordan: I'm totally jealous |
| 15:44.49 | mjordan | they are very good tacos |
| 15:45.21 | Qwell | mjordan: I can do that. |
| 15:47.17 | opticron | putnopvut, RE: ASTERISK-23941 do you know the "correct" way to get the channel (or a snapshot) that will be swapping into the bridge on an app attended transfer? it isn't in the stasis attended transfer message |
| 15:47.59 | putnopvut | looks |
| 15:48.25 | opticron | in the case that I have reproduced, the message contains the channel that's going away and the *other* half of the local channel that I want |
| 15:49.08 | putnopvut | Can you pastebin the whole message? |
| 15:49.37 | opticron | http://pastebin.com/3CBcfDzV |
| 15:51.37 | putnopvut | is trying to digest everything |
| 15:53.02 | putnopvut | So, if this is an app attended transfer, the information you have there is what you would need. The channel in the bridge is moving out of the bridge and will be taking the place of the local channel in whatever app the local channel is currently running. |
| 15:53.40 | putnopvut | The local channel half that is reported in the message is the local channel half that is currently running the Echo application |
| 15:54.16 | putnopvut | There is no channel that is swapping into the bridge on such a transfer. |
| 15:54.51 | opticron | I must be reading the logs wrong, then |
| 15:57.21 | opticron | you've cast doubt on my grasp of what's going on, I'll double check things |
| 15:58.23 | putnopvut | Okie-dokie |
| 16:00.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 16:09.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:09.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:18.58 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:18.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:30.48 | seanbright | so here is what i am trying to do... i've asked 1000 variations of this before but i might as well ask again |
| 16:31.54 | seanbright | i have a call that is being sent to asterisk from a third party and they are sending and expecting to receive g729 |
| 16:32.29 | seanbright | when a call comes in to asterisk, i want it to immediately transcode to slinear |
| 16:33.06 | seanbright | but i don't want to accept slinear from the third party |
| 16:33.08 | seanbright | does that make sense? |
| 16:33.25 | jsmith | No, but go on :-p |
| 16:33.32 | seanbright | that's basically it |
| 16:33.41 | jsmith | (I mean, I understand *what* you're trying to do, but not why) |
| 16:33.52 | seanbright | forget the why |
| 16:33.54 | seanbright | :-) |
| 16:34.30 | jsmith | Well, the why is very much relevant to the transcoding piece... the audio will almost certainly get transcoded to slinear (or something similar) if you put the call in a bridge, etc. |
| 16:34.57 | seanbright | because inside asterisk i am doing several separate things that involve looking at the audio (mixmonitor, confbridge, etc) and i don't want multiple transcoders to be used |
| 16:35.30 | jsmith | seanbright: So put into a bridge, and then look at the audio, on the other channel in the bridge :-p |
| 16:35.44 | seanbright | i don't want to do that |
| 16:35.56 | seanbright | i want to just translate the audio on the way in and the way out |
| 16:36.14 | jsmith | No way to do that with the current set of tools, from what I know |
| 16:36.21 | seanbright | and i don't want to have to run through an application that doesn't buy me anything other than transcoding |
| 16:36.24 | seanbright | ok |
| 16:36.45 | file | yeah stuff isn't built to quite work like that |
| 16:36.48 | jsmith | Is doing things through a bridge that hard? |
| 16:36.57 | jsmith | Because that's the most elegant solution I could think of... |
| 16:37.10 | jsmith | ... unless file has a trick up his sleeve that I didn't come up with |
| 16:37.22 | file | I have no sleeves. |
| 16:37.37 | seanbright | so the call comes in and we want to record it |
| 16:37.45 | seanbright | two options |
| 16:38.00 | seanbright | start a mixmonitor on a channel and then send it into a bridge |
| 16:38.11 | seanbright | send it into a bridge and record the bridge |
| 16:38.25 | seanbright | in either case we are transcoding at least twice |
| 16:38.43 | file | why are you transcoding twice? |
| 16:38.53 | jsmith | I don't see how you're transcoding twice in the second instance |
| 16:39.08 | seanbright | have you looked at how confbridge does recording? |
| 16:39.19 | seanbright | find_app("MixMonitor") |
| 16:40.34 | file | oh silly core |
| 16:40.50 | file | did I do that... |
| 16:41.19 | seanbright | could i just write an application that sets up a translation path? |
| 16:41.33 | seanbright | or is it not that trivial? |
| 16:41.39 | file | you can't force it because actions taken afterwards can change it |
| 16:41.58 | seanbright | what actions taken afterwards? |
| 16:42.26 | file | ummm anything that reads/writes media, including bridging |
| 16:42.40 | seanbright | if i force it to slinear, what would change it to another else? |
| 16:42.48 | file | you can't force it to slinear |
| 16:42.52 | seanbright | bridging would change it to match the other party? |
| 16:43.12 | file | you are only guaranteed that the read or write translation path will remain what it is while in your application |
| 16:43.35 | file | and it could, I'd have to go back in time and check |
| 16:43.52 | seanbright | well |
| 16:43.55 | seanbright | that blows |
| 16:44.19 | file | given the MixMonitor / Bridge scenario do you know where your transcodes are happening exactly? |
| 16:44.31 | file | and what version? |
| 16:44.38 | seanbright | 11 |
| 16:44.56 | seanbright | and yes... in MixMonitor and briding...? |
| 16:45.19 | seanbright | mixmonitor uses audiohooks, ConfBridge uses the bridging api |
| 16:45.39 | file | let's see here... |
| 16:45.43 | seanbright | heh |
| 16:46.48 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 16:47.15 | seanbright | i guess i could throw another asterisk box in the middle that just transcodes but that seems really dumb |
| 16:47.36 | file | hush |
| 16:47.55 | file | I'm reading old code |
| 16:48.07 | seanbright | heh |
| 16:48.35 | seanbright | there should be a "do_not_try_to_be_smart" configuration flag |
| 16:48.51 | file | it's more complicated than that |
| 16:48.55 | file | but, hush :P |
| 16:49.45 | seanbright | and i get it... if there was a company out there that generated revenue based on transcoder licenses in another piece of software that they developed, they wouldn't make it easy to reduce the number of transoder licenses... |
| 16:49.49 | seanbright | hypothetically speaking... |
| 16:49.50 | seanbright | :P |
| 16:49.59 | file | fine |
| 16:50.13 | file | you'll never know what I'm doing then |
| 16:50.14 | seanbright | <3 |
| 16:50.14 | file | :P |
| 16:50.24 | seanbright | i'm just busting balls, settle down |
| 16:50.31 | file | la la la |
| 16:51.51 | seanbright | if i say i'm sorry will you tell me what you're doing? :) |
| 16:52.32 | file | nope |
| 16:52.34 | file | I told you to hush |
| 16:52.37 | file | you didn't :P |
| 16:52.37 | seanbright | damn |
| 16:52.39 | seanbright | ok |
| 16:52.40 | file | there are consequences |
| 16:52.41 | seanbright | thanks |
| 16:52.49 | file | BUT |
| 16:52.57 | file | it's potentially good |
| 16:53.06 | file | it's just complicated and will take me a bit |
| 16:53.57 | seanbright | i was just picking brains... i wasn't expecting you to actually _do_ something |
| 16:54.04 | seanbright | but i won't complain if you make my life easier |
| 17:01.01 | file | taps as it compiles |
| 17:04.53 | file | http://rho.jcn-network.com/patches/move-audiohook-writes-around.diff |
| 17:04.54 | file | try that |
| 17:05.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 17:05.41 | seanbright | will give it a whirl |
| 17:05.45 | seanbright | thank you, sir. |
| 17:06.01 | seanbright | another question which i believe i already know the answer to |
| 17:06.21 | file | I don't have a transcoder card so I can't confirm behavior in an environment such as that (it does matter) but I think it should be okay |
| 17:06.48 | seanbright | i initiate a SIP call to another party indicating that i accept g729 and ulaw but i prefer ulaw, the respond in kind and g729 is chosen |
| 17:07.14 | seanbright | can the codec change mid-call? is that possible with asterisk? |
| 17:07.39 | file | Asterisk won't initiate codec changes at this time. |
| 17:07.49 | seanbright | got it |
| 17:08.07 | seanbright | will give your patch a try and let you know |
| 17:08.20 | file | I offer no warranty. |
| 17:08.27 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:08.33 | seanbright | it's ok. i'm just rolling it out to 100 or so production servers. |
| 17:08.37 | file | is that all? |
| 17:09.00 | seanbright | yeah, this is one of the smaller centers |
| 17:32.44 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4565:9628:8eff:a854) |
| 17:32.52 | file | tempts fate by using a printer |
| 17:34.10 | Marquis42 | What is this "printer" thing of which you speak? |
| 17:34.20 | file | Marquis42, a device made of pure dark magic |
| 17:34.35 | Marquis42 | lol |
| 17:52.48 | opticron | "ink plotter" |
| 17:54.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 18:18.56 | leifmadsen | Marquis42: when I read that originally, I read that as "pointer" |
| 18:20.12 | opticron | putnopvut, double checked it, initial conditions: originated local channel goes to Echo() and Stasis(), incoming PJSIP call bob-0 goes into Stasis(), incoming PJSIP call bob-1 goes into Echo() |
| 18:20.30 | opticron | bob-0 sends a REFER to start the attended transfer |
| 18:20.52 | opticron | transfer code creates local channel pair |
| 18:20.52 | Marquis42 | leifmadsen: Well, pointers are made of pure dark magic. ;) |
| 18:21.03 | leifmadsen | exactly |
| 18:21.09 | leifmadsen | mmmm... pure dark chocolate |
| 18:21.46 | opticron | local;2 gets masqueraded into bob-1 to steal Stasis() |
| 18:22.29 | opticron | local;1 gets swapped with bob-0 (bob-0 is currently in a bridge with originated channel in Stasis()) |
| 18:22.45 | opticron | *to steal Echo() |
| 18:23.16 | opticron | it's the tests/rest_api/bridges/attended_transfer test |
| 18:24.20 | opticron | so the attended transfer message references bob-0 and local;2 (masquerade with bob-1 has already happened) |
| 18:26.56 | putnopvut | context switches |
| 18:31.31 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 18:32.24 | putnopvut | Okay, it sounds like the conclusion here has to be reached by reading several messages, each of which should tell you about changes in the state of the bridge. |
| 18:32.48 | putnopvut | I'm still reasoning through it at the moment. |
| 18:33.04 | opticron | ok, that's the method I was thinking I'd have to take at this point |
| 18:35.08 | mjordan | That's unfortunate |
| 18:35.16 | opticron | that's also what I was thinking |
| 18:35.28 | mjordan | what channels would we want to know about? |
| 18:35.47 | mjordan | local;2 and local;1 I would think |
| 18:35.48 | putnopvut | Yeah, my big question with the procedure is why the transfer code is creating a local channel pair in the first place... |
| 18:36.09 | mjordan | I'd guess "multi-party bridge may be getting transferred" as the answer |
| 18:36.20 | mjordan | but we shouldn't be doing that unless we absolutely have to |
| 18:36.26 | putnopvut | But I thought there was a case built-in for transferring a single party. |
| 18:36.57 | mjordan | I thought so too |
| 18:37.16 | opticron | putnopvut, how else is the transfer code going to get control of the application on the other channel than by masquerading it with a local channel that can be put into a bridge? |
| 18:37.18 | putnopvut | It seems like the transfer code is taking the difficult approach |
| 18:37.31 | putnopvut | To me, the bridge in this case could just die. |
| 18:37.43 | putnopvut | Move the channel bridged to bob-0 out of the bridge and masquerade it into bob-1 |
| 18:37.47 | opticron | the bridge can't die, it's ARI-controlled |
| 18:37.59 | putnopvut | Okay, not die, but be emptied then. |
| 18:38.52 | opticron | I don't think you can't reach to the other side of the ARI-controlled bridge, either |
| 18:38.56 | putnopvut | Bridge has bob-0 and the transferee in it. Transfer causes transferee to get removed and masqueraded into bob-1's channel. bob-0 hangs up as part of the transfer operation. The bridge is now empty, and the transferee has taken bob-1's place in the dialplan. |
| 18:38.59 | file | ARI bridges are very restricted in moving stuff around |
| 18:39.11 | putnopvut | ah |
| 18:40.21 | putnopvut | Okay, so instead, we're going with the approach of creating a local channel, masquerading one end into bob-1's channel and placing the other end in the bridge. What I'm not 100% sure on is if, when performing that code, if the local;1 half swaps bob-0 out of the bridge when it enters. I assume it does, but I'm not certain. |
| 18:40.33 | file | we can unrestrict, but we have to seriously think and explore the consequences and such |
| 18:40.35 | opticron | it does |
| 18:40.48 | opticron | the bridge enter message has the ;1 uniqueid as the swap |
| 18:40.57 | putnopvut | Okay, so yeah, multiple messages, unfortunately :( |
| 18:42.48 | putnopvut | The problem is, if the masquerade is happening before the transfer completes, then the actual channel running the application is the local;2 channel, not bob-1. To report bob-1 in the stasis message would be inaccurate since, presumably anyway, a previous message has stated that the local;2 channel moved into bob-1's place and bob-1 hung up. |
| 18:43.10 | opticron | putnopvut, the local;2 is being correctly reported in the stasis message |
| 18:43.26 | putnopvut | Correct. But it sounded like you wanted bob-1 reported instead, right? |
| 18:43.32 | opticron | no |
| 18:43.36 | putnopvut | oh. |
| 18:43.38 | putnopvut | what's the issue then? |
| 18:43.42 | opticron | I need to know that local;1 is taking bob-0's place |
| 18:44.06 | opticron | preferably before bob-0 leaves the bridge |
| 18:44.16 | putnopvut | Don't you get a BridgeEnter? |
| 18:44.22 | opticron | that comes later |
| 18:44.57 | putnopvut | So you specifically need local;1's snapshot at the time that the attended transfer is happening. |
| 18:45.08 | opticron | that would be best case scenario |
| 18:45.32 | opticron | or whatever happens to be taking bob-0's place in the bridge |
| 18:46.07 | opticron | in this specific scenario, that's probably always going to be a local;1 |
| 18:46.50 | putnopvut | It should be a local;1 in every ARI transfer to an application. |
| 18:48.00 | opticron | bridgeattendedtransfer bob-0/local;2 -> channelhangupreq bob-0 -> bob-0 leaves bridge -> bob-0 leaves Stasis() -> local;1 enters bridge |
| 18:50.05 | putnopvut | Yeah, it seems like the stasis messages for attended transfers to applications are lacking when the created local channel pair gets involved. The messages are pretty much telling you that the bridge bob-0 was in has been transferred to the application where the local;2 channel was. The problem is, the local;1 channel isn't in the bridge at that point. I wonder if it would be possible to delay the attended transfer message |
| 18:50.05 | putnopvut | until after all parties have entered bob-0's bridge... |
| 18:51.03 | opticron | another problem I'm about to have: local;1 isn't actually in Stasis() |
| 18:51.20 | putnopvut | Yeah, since the bob-1 channel called directly into Echo() |
| 18:52.10 | opticron | so the ARI user is having its in-Stasis() channel that it has control over being ripped away and replaced with this channel that it knows about but can do nothing with |
| 18:52.56 | opticron | that seems non-ideal |
| 18:55.35 | putnopvut | I mean, yeah, but it also seems like user error to do that. If you have one channel call into Stasis() and another not call into Stasis(), you can't expect that when the non-Stasis channel is placed into the bridge that you'll be able to control that channel. Solution is to not try to mix Stasis and non-Stasis channels in the same bridge. |
| 18:56.36 | putnopvut | Either that, or you make any channel that enters a stasis-created bridge controllable via Stasis as well...somehow? |
| 18:56.36 | putnopvut | Not sure about the logistics of that one. |
| 18:56.42 | opticron | erm...even if the other end WAS in stasis, this would still happen |
| 18:56.57 | opticron | unless the other end was bridged via Stasis() |
| 18:57.21 | opticron | I'm currently contemplating the logistics of that |
| 18:59.24 | opticron | if they were both bridged via Stasis()...you'd end up with an uncontrolled local channel pair linking two controlled bridges |
| 19:00.09 | coreyfarrell | file / mjordan: how do you feel about merging trunk (417056..417768) to media_formats-reviewed-trunk? I just did a dry-run and only have 3 conflicts (all in app_jack.c). I'm sure this is not an issue of if but when - before or after we finish the current reviews |
| 19:00.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:00.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:00.56 | putnopvut | opticron: looking at the code, the one thing I'm kind of surprised by is that the attended transfer message is being published before the bridge join for the local;1 and the bridge leave for bob-0. It looks like the ast_bridge_impart() call happens before publishing the attended transfer message. |
| 19:01.32 | opticron | the actual enter/leave don't happen on that thread |
| 19:01.35 | putnopvut | Hm, but I guess since ast_bridge_impart is asynchronous, you can't guarantee that the swap has occurred by the time the publication happens. |
| 19:01.38 | putnopvut | Yeah |
| 19:03.13 | putnopvut | Also, the local;2 channel is operating in a separate thread too. So there's a chance the masquerade won't happen before the attended transfer publication. |
| 19:06.03 | file | coreyfarrell, hum. |
| 19:08.57 | file | coreyfarrell, it's either potentially disturb the current open reviews, or wait and only have to inconvenience the person who does the merge ^_^ |
| 19:13.14 | coreyfarrell | file: I'm fine with finishing these reviews first, but I'm hoping we can merge trunk before any new reviews so the merge doesn't get too big/conflicted. trunk has some useful fixes for REF_DEBUG that I'd like to have, but I don't want to cherry pick and risk missing something / reverting it when we finally merge to trunk |
| 19:25.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.87.131.147) |
| 19:25.39 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:40.19 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-30-203.user.veloxzone.com.br) |
| 19:43.56 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 20:03.03 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-zntozjftmcrwmjhe) |
| 20:17.49 | ipengineer | file: nice |
| 20:20.01 | file | 'tis progress |
| 20:31.57 | ipengineer | Making more than we would have made for sure |
| 20:47.05 | mjordan | coreyfarrell: I'd merge now. I'll deal with the conflicts in the current naming review |
| 20:47.19 | mjordan | coreyfarrell: It's harder to keep pulling things out that I needed to verify that stuff worked |
| 20:47.46 | mjordan | coreyfarrell: at this point, I'd really prefer to get automerge enabled as well. That way when the remove deprecated modules patch goes in, the format work gets updated |
| 20:47.59 | mjordan | otherwise we're going to have to keep dealing with things that won't compile in chan_h323 and others |
| 20:49.11 | coreyfarrell | mjordan: automerge would fail when we remove deprecated modules |
| 20:49.27 | coreyfarrell | since those modules have been modified from trunk |
| 20:56.25 | coreyfarrell | file: your changes are smaller / less likely to conflict than mjordan's, so I'm going to merge to current unless you complain in the next few minutes (I just have to figure out the app_jack changes) |
| 20:56.33 | file | go ahead |
| 20:57.40 | file | ipengineer, https://reviewboard.asterisk.org/r/3705/ |
| 20:57.48 | file | and now I do nothing for the rest of the night |
| 20:58.45 | ipengineer | file: Thanks You! Question… Will this get merged into some nightly build? |
| 20:59.04 | file | once it gets a ship it it will be merged in. |
| 20:59.14 | ipengineer | Perfect |
| 21:09.04 | coreyfarrell | mjordan: so I just searched the patch that I'm applying from patch, the only match to "ast_format" was in app_jack, a module that I can't compile (I don't have jack). I think I fixed it but have no way to test. |
| 21:09.40 | coreyfarrell | err patch that I'm applying from trunk |
| 21:14.25 | mjordan | I think I can compile app_jack, I'll check it tonight |
| 21:15.36 | coreyfarrell | I just committed.. I'm pretty sure I got the patch fixed right. if not we'll catch it before release |
| 21:31.06 | coreyfarrell | file / mjordan: you want to both be on automerge-email? |
| 21:31.20 | file | throw me on all the things |
| 21:31.25 | file | except pointy spikes |
| 21:32.00 | file | ipengineer, George Joseph has confirmed it works for him! |
| 21:32.27 | coreyfarrell | ha |
| 21:33.07 | ipengineer | Great! I am going to pull it down and create a new instance this evening. |
| 21:34.10 | ipengineer | Since that is set to ship it will be built on the nightly tonight? If that is the case where can I download it first thing in the AM? That will assure I dont screw anything up trying to merge it in manually. |
| 21:38.22 | file | we don't do builds |
| 21:38.45 | file | at least, not like that - and I'll be waiting to get another set of eyes on it |
| 21:39.36 | ipengineer | Right but it gets merged into the latest source? Then it will have to be pulled down and compiled? |
| 21:40.02 | ipengineer | I guess the easy question is where did you download the version you built this against |
| 21:40.21 | file | this patch is against Asterisk 12 in subversion, but it would most likely apply cleanly to the latest release of 12 |
| 21:41.21 | coreyfarrell | ipengineer: if you use the 'patch' utility it will warn or fail if the patch doesn't apply cleanly. |
| 21:42.03 | file | I just pulled 12.3.2 and it applied |
| 21:42.16 | ipengineer | Ok. I will take a look at the patch utility |
| 21:42.53 | ipengineer | I think last time I manually diffed each file and moved everything over then compiled it… Shameful I know! |
| 21:43.54 | coreyfarrell | ipengineer: definitely use the patch utility.. manually |
| 21:44.13 | coreyfarrell | manually applying patches is just asking for a typo to mess things up |
| 21:45.39 | ipengineer | this look right? patch -p0 < patch-file |
| 21:45.51 | file | yes |
| 21:45.58 | file | provided you are in the asterisk directory |
| 21:46.03 | ipengineer | right |
| 21:46.27 | gtjoseph | and add --dry-run the first time. :) |
| 21:46.30 | ipengineer | The question is what is the patch-file? I see where I can download the Raw Diff |
| 21:46.44 | file | that is the patch file |
| 21:46.51 | gtjoseph | https://reviewboard.asterisk.org/r/3705/diff/raw/ |
| 21:46.53 | ipengineer | k |
| 21:46.55 | file | gtjoseph, there you are! I forgot what your IRC nick was |
| 21:47.19 | gtjoseph | were you looking for me for something? |
| 21:47.30 | file | no, I was going to joke about you being slow on testing my patch :P |
| 21:47.37 | gtjoseph | :) |
| 22:02.37 | file | wobbles |
| 22:02.44 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 22:11.13 | ipengineer | file: Im heading out. Will test that patch later tonight and let you know. Thanks again! Huge relief on this end |
| 22:33.10 | mjordan | coreyfarrell: how about ast_format_cap_append_from_cap instead of the existing ast_format_cap_append_by_type. Rationale is on the issue, but I'm starting to work through your findings and wanted your opinion before I started find/replacing |
| 22:33.44 | coreyfarrell | reading your response |
| 22:35.52 | coreyfarrell | mjordan: yes.. then loose the _all from ast_format_cap_append_by_type? |
| 22:36.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:37.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 22:37.55 | mjordan | yup |
| 22:38.49 | coreyfarrell | that's great. my main issue was that the _all had to go away to be consistent between append and remove. |
| 22:39.18 | mjordan | yup. The only reason I added the 'all' was to avoid the name conflict |
| 22:39.34 | mjordan | and I agree, 'all' is redundant in that function name |
| 22:40.15 | coreyfarrell | well the other function having not all was confusing to me |
| 22:41.15 | mjordan | :-) |
| 22:41.42 | mjordan | While you're here... I'm not sure what to do about the code duplication. I didn't like it either, but having the non-debug version of a function get forced into calling the ao2 debug variant explicitly felt bad |
| 22:41.58 | mjordan | and we have to call the ao2 debug variant explicitly so that we can hand it our file,line,function |
| 22:42.08 | coreyfarrell | static inline void internal_thistype_init(...); |
| 22:42.22 | mjordan | hm. |
| 22:42.30 | coreyfarrell | so the debug/non-debug functions do the right ao2_alloc, then call init |
| 22:43.01 | mjordan | for the alloc that isn't so bad, the get might be a bit trickier. I'll see what i can come up with. |
| 22:43.02 | coreyfarrell | I don't care if the object code is inlined, I just don't like that we're duplicating logic in source code |
| 22:43.11 | mjordan | yeah, I didn't like doing that either. |
| 22:45.45 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-zeoftdxqfyjnisgw) |
| 22:48.25 | mjordan | hm |
| 22:48.32 | mjordan | we don't actually use the flags passed into ast_format_cap_alloc |
| 22:48.58 | coreyfarrell | don't we only have one option? |
| 22:49.12 | mjordan | yeah. I was getting it mixed up with the media type enum. |
| 22:49.30 | mjordan | I'd have to ask file about what else could be passed there. Having it is harmless, and would probably be more intrusive to add something back in later.... |
| 22:49.46 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 22:49.46 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:49.50 | file | nothing presently, but I kept it for that reason |
| 22:50.47 | coreyfarrell | that's what I figured :) |
| 23:10.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:10.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:20.01 | mjordan | I am hopeful that we are nearing the end of these massive patches... |
| 23:20.50 | coreyfarrell | cool |
| 23:21.34 | coreyfarrell | once yours and file's are in we should tell bamboo to run again |
| 23:24.03 | mjordan | yup. Unit tests feel like the next thing to go knock out, which I'd be happy to do |
| 23:28.50 | coreyfarrell | you mean test_format_api? |
| 23:29.01 | mjordan | yeah |
| 23:29.18 | mjordan | plus whatever else may be failing or crashing in the unit tests. Pretty sure the CDR/CEL unit tests are profoundly unhappy |
| 23:29.26 | coreyfarrell | yeah.. I got about as far as I could on that one.. I sent you the patch |
| 23:29.27 | mjordan | they like to make channels with no capabilities |
| 23:29.30 | mjordan | yup |
| 23:29.32 | mjordan | I'll take it from there |
| 23:29.36 | coreyfarrell | gave up when I hit the format attributes stuff :) |
| 23:29.42 | mjordan | which file has up! |
| 23:30.01 | mjordan | two weeks to go from today... |
| 23:30.12 | file | never gonna give you up |
| 23:31.17 | mjordan | never gonna let you down |
| 23:31.28 | coreyfarrell | so is bamboo on automatic for media_formats? |
| 23:31.43 | mjordan | yup |
| 23:32.18 | mjordan | so we shall be scolded fiercely until the unit tests pass |
| 23:32.26 | mjordan | *motivation* |
| 23:32.32 | file | such an aggrivation |
| 23:33.26 | coreyfarrell | bamboo already complains every time I do a commit, why shouldn't it do so for media_formats |
| 23:51.20 | coreyfarrell | mjordan: it looks like we lost the changes to main/frame.c |