| 00:38.05 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:38.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:39.19 | leifmadsen | mjordan, are you working on the book? |
| 00:39.37 | mjordan | leifmadsen: zuul right now, but that's next :-) |
| 00:39.42 | leifmadsen | heh |
| 00:39.44 | mjordan | I _almost_ have it working |
| 00:40.01 | leifmadsen | a super smart person I worked with at TPN also gave up on zuul several times.... |
| 00:40.08 | leifmadsen | I have no idea how pabelanger got it working |
| 00:41.21 | file | mjordan, I still don't trust it |
| 00:41.30 | mjordan | leifmadsen: it's pretty complex |
| 00:41.34 | mjordan | honestly, the worst part was SSH |
| 00:41.43 | mjordan | paramiko likes to disconnect randomly |
| 00:41.55 | mjordan | or else there's something funky going on networking wise |
| 00:42.01 | mjordan | either way, infinite time suck of debugging |
| 00:44.42 | file | Thursdays are the best time for infinite time sucking |
| 00:46.22 | mjordan | file: \o/ |
| 00:46.43 | mjordan | have to fire up the vpn, brb |
| 00:46.56 | file | these people and their "Send all traffic through VPN" |
| 00:47.09 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:47.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:47.27 | file | mjordan, too soon |
| 00:48.01 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 00:48.08 | file | and now superscrat appears |
| 00:48.21 | file | disappears briefly though |
| 00:48.56 | superscrat | hello file |
| 00:49.50 | *** join/#asterisk-dev mjordan1 (mjordan@nat/digium/x-ozqnktybqjhocsrg) |
| 00:49.50 | *** mode/#asterisk-dev [+o mjordan1] by ChanServ |
| 00:50.24 | superscrat | hello mjordan1 |
| 00:50.31 | mjordan1 | hola |
| 00:51.57 | superscrat | How goes it with you this evening? |
| 00:52.48 | mjordan1 | well! |
| 00:53.07 | mjordan1 | little concerned that I had to restart the gearman plugin again in Jenkins. Apparently updating the Jenkins jobs makes it cranky. |
| 00:54.18 | superscrat | i took the baby swimming so she will sleep well while i fight my local git repo. i'm not certain what happened, but when i tried git reset --hard, it told me I was denied! like that's going to stop me. pfft. |
| 00:54.42 | mjordan1 | sudo git reset --hard --please? |
| 00:57.12 | mjordan1 | walks the dog |
| 00:58.44 | file | would walk the dog except she's afraid of the dark, and it's dark |
| 01:02.17 | superscrat | file, aww. my dogs are sleeping. zzzzz |
| 01:03.05 | superscrat | mjordan1, there won't be any 'please' to it! sudo git reset --hard --do-it-now-or-else |
| 01:55.57 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:55.57 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Hell hath frozen over: Asterisk is moving to Git -=- Follow on Twitter at @AsteriskDev |
| 03:23.56 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 04:07.41 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:12.19 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-ootxyvgbefmiydva) |
| 05:14.28 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 05:15.18 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 06:50.20 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:50.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:24.33 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:51.33 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:51.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:02.14 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:10.08 | *** join/#asterisk-dev esupra (~esupra@196.213.190.113) |
| 08:11.11 | esupra | ping |
| 09:23.27 | *** join/#asterisk-dev husanu4 (~husanu4@91.199.104.6) |
| 11:30.15 | *** join/#asterisk-dev fornax (~fornax@p5792394F.dip0.t-ipconnect.de) |
| 11:35.58 | *** join/#asterisk-dev mastahh (~mastahh@89.238.175.130) |
| 12:12.11 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 12:12.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:33.18 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hkvmwaefdiskyxba) |
| 12:33.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:36.41 | DivideBy0 | scrolls up, new book? |
| 12:37.03 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-kwmvrojjcrpcnmuz) |
| 12:51.51 | Marquis42 | DivideBy0: There's talk of a 5th Edition, so not *new* but significantly revised and with the addition of all the things that have been added to Asterisk in the interim (ARI, etc.). |
| 13:17.06 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:17.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:36.01 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-xaikzreooguolmwn) |
| 13:36.01 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:43.50 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-jbyvwzdfwimnbbzp) |
| 13:49.08 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-siieifawghirrmpz) |
| 13:50.53 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:05.10 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 14:08.11 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-adipscatailokwcl) |
| 14:08.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:16.15 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-anxpkqvsxgtbjhsa) |
| 14:17.32 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:17.32 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:17.51 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-imewkjfivpkfdcmr) |
| 14:18.39 | mjordan | so... |
| 14:18.50 | mjordan | rmudgett: we need to get your changes pushed in, at least those that are ready |
| 14:19.05 | mjordan | rmudgett: what's the right order for the patch set at this point? It appears as if there are still some conflicts between changes |
| 14:22.23 | rmudgett | The 686-688 and the corresponding master versions haven't had any comments. Those could get pushed in without a problem. |
| 14:23.35 | rmudgett | They should get pushed in from lowest number on up for each branch. |
| 14:25.18 | file | provided the relationships are right, it won't allow 'em in until all are submitted |
| 14:25.26 | file | well - or unless you do it in the right order |
| 14:28.49 | rmudgett | Well they went up as part of a series so gerrit should know that. :) |
| 14:29.26 | mjordan | rmudgett: it does. And it won't let things merge in unless it is in the right order. |
| 14:29.35 | mjordan | rmudgett: however, your own patch series conflicts with itself |
| 14:29.44 | rmudgett | ??? |
| 14:29.47 | mjordan | rmudgett: so, in order to avoid making it harder on you, it's nice to merge things in the right process |
| 14:30.07 | mjordan | rmudgett: https://gerrit.asterisk.org/#/c/686/3 |
| 14:30.15 | mjordan | look at the "Conflicts with" tab |
| 14:30.27 | mjordan | now, if it goes in the correct order, that probably won't matter |
| 14:33.57 | mjordan | go go go: https://jenkins.asterisk.org/jenkins/job/gate-asterisk/28/console |
| 15:01.02 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:01.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:10.15 | *** join/#asterisk-dev doome_ (~doome@apn-185-10-125-136.vodafone.hu) |
| 15:26.54 | jameswf | sits and waits for a strongly worded blog post |
| 15:26.59 | jameswf | eats popcorn |
| 15:27.09 | mjordan | what, about fax? |
| 15:27.57 | jameswf | :) |
| 15:29.45 | mjordan | lord |
| 15:29.57 | mjordan | if someone writes a strongly worded blog post defending fax ... |
| 15:32.55 | file | I would love to read that |
| 15:33.10 | file | I would write a satirical one except I couldn't pull it together |
| 15:33.18 | Qwell | file: slacker |
| 15:34.24 | file | Qwell, tacos |
| 15:44.53 | superscrat | file, ice cream |
| 16:33.56 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 17:00.42 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 17:01.06 | DivideBy0 | thanks Marquis42 |
| 17:55.19 | rmudgett | file: How about: Unload incomplete. Could not stop %d registrations. Try again later. |
| 17:55.28 | file | sure |
| 18:05.16 | file | can I get a "are you sure you want to do that?" on 725 and 726? |
| 18:05.58 | mjordan | whoa. |
| 18:06.10 | mjordan | I'm not sure that's the right answer. |
| 18:06.22 | mjordan | Should we be clearing the OUTBOUND flag instead? |
| 18:08.19 | file | the bridge stuff explicitly clears it in a few places |
| 18:09.31 | file | specifically for CDRs |
| 18:10.19 | mjordan | correct |
| 18:10.28 | mjordan | if you don't clear the OUTBOUND flag, then 'bad things' will eventually occur |
| 18:10.40 | mjordan | So should we just be clearing the flag in whatever situation resulted in the problem? |
| 18:11.01 | file | I don't understand the question |
| 18:30.32 | mjordan | so the patch currently is simply removing a check to answer a channel if the OUTBOUND flag is on the channel |
| 18:30.50 | mjordan | I would presume that at some point in time, the OUTBOUND channel is no longer outbound, and hence the Answer we are attempting to do on it fails |
| 18:31.08 | mjordan | however, rather than removing the check, can we instead fix the actual issue where the OUTBOUND flag is not being cleared appropriately? |
| 18:32.32 | file | it removes a check preventing the channel from being able to queue up that it has been answered |
| 18:33.50 | file | reverse direction - it's not being told to answer, it's telling other stuff that it has been |
| 18:33.55 | mjordan | ah |
| 18:34.00 | mjordan | Hm. |
| 18:34.17 | mjordan | which channel in the blonde transfer is this pertaining to? |
| 18:35.08 | file | https://issues.asterisk.org/jira/browse/ASTERISK-25171 |
| 18:35.18 | file | in that scenario, C |
| 18:36.25 | mjordan | right |
| 18:36.29 | mjordan | Hm. |
| 18:36.37 | mjordan | So C actually is still an outbound channel, unless it survives the bridge |
| 18:36.42 | mjordan | which means we shouldn't clear the flag yet |
| 18:36.45 | mjordan | ergo, the patch is correct. |
| 18:36.46 | mjordan | \o/ |
| 18:37.40 | file | technically it survived one bridge and got moved to another |
| 18:38.00 | mjordan | right |
| 18:38.04 | mjordan | well |
| 18:38.04 | mjordan | no |
| 18:38.07 | mjordan | not in a blonde transfer |
| 18:38.14 | mjordan | it was never bridged (technically) with party A |
| 18:38.24 | mjordan | "early bridge" kind of doesn't count ;-) |
| 18:39.46 | file | LA LA LA :P |
| 19:00.31 | *** join/#asterisk-dev BakaKuna (~BakaKuna@82-169-251-128.ip.telfort.nl) |
| 19:08.15 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-sdvgjeyjilzlwmyx) |
| 19:38.08 | *** part/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 19:47.41 | seanbright | what's the word on the street with res_timing_timerfd? is there really a benefit to using res_timer_dahdi over it if you don't have any dahdi hardware? |
| 19:50.47 | newtonr | Hmm, https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces |
| 19:50.56 | newtonr | Looks like Asterisk prefers res_timing_timerfd.so |
| 19:51.04 | newtonr | for the load priority |
| 19:51.12 | newtonr | not sure if that means it is better or not |
| 19:52.08 | seanbright | ah. well then. |
| 19:53.27 | newtonr | seanbright, I don't know anything! I promise. |
| 19:54.08 | seanbright | i'm kinda pissed you just linked me to some documentation |
| 19:54.17 | seanbright | like i'm supposed to do independent research |
| 19:54.19 | seanbright | fuck you man |
| 19:54.20 | seanbright | heh |
| 19:58.23 | newtonr | http://abyss.uoregon.edu/~js/images/rtfm.jpg |
| 19:59.16 | seanbright | i know i know |
| 19:59.24 | seanbright | the docs are always up to date |
| 19:59.26 | newtonr | It's okay I'm probably the worst about not checking the wiki first and I write wiki pages every month |
| 19:59.38 | newtonr | I have no room to talk |
| 20:32.52 | rmudgett | file: res/res_pjsip_t38.c:t38_interpret_parameters() line 326. Does the then clause for !max_ifp make sense to you. |
| 20:33.37 | rmudgett | It looks like the t38 state change should be part of the then clause of the if T38_PEER_REINVITE test. |
| 20:33.37 | file | yes? |
| 20:33.55 | file | hrm, maybe |
| 20:34.04 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:34.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:34.25 | rmudgett | t38_change_state sets the state to T38_REJECTED. We then go and test it for T38_PEER_REINVITE |
| 20:34.42 | file | yeah |
| 20:34.58 | file | the old state should be stored and examined |
| 20:38.05 | rmudgett | There is similar code about 30 lines later. However, I think that code is how it should do it. Check then set and resume the reinvite. |
| 21:04.41 | putnopvut | Some previous PJSIP NAT tests are failing after my Record-Route change. This is because I updated the condition for rewriting contact so that the contact is not rewritten if the dialog's route set is frozen. |
| 21:05.36 | putnopvut | As it turns out, when receiving a 200 OK, the route set is marked frozen before our NAT code gets a chance to inspect things. So it turns out that on an incoming 200 OK, we will not rewrite the contact now. This was not my intention. |
| 21:06.11 | file | blah |
| 21:06.12 | putnopvut | What I want is not to rewrite the contact once the route set has been established, so that on something like an incoming ACK, we don't end up rewriting the contact if there is a route set that has already been establised. |
| 21:06.43 | putnopvut | I'm thinking that what I need to do is rewrite the contact if the dialog has an empty route set. |
| 21:06.55 | file | I think you are correct |
| 21:06.56 | putnopvut | I think that might accomplish the same thing. |
| 21:16.46 | putnopvut | Review is up now for it. |
| 22:19.43 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-adipscatailokwcl) |
| 23:02.23 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 23:02.23 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:53.06 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
