| 00:24.58 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:24.58 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 02:48.11 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@be.celya.fr) |
| 03:24.24 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.53) |
| 06:06.10 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:41c0:87d9:904f:8ace) |
| 06:17.09 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:17.09 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:53.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:41c0:87d9:904f:8ace) |
| 07:31.51 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 07:31.51 | *** mode/#asterisk-dev [+o wdoekes] by ChanServ |
| 11:25.10 | gtjoseph | tsearle: did you see my comment on the pjproject deadlock patch? |
| 11:25.40 | tsearle | yeah, thanks, will need to re-check the pcap |
| 11:26.26 | tsearle | part of the issue I think is the sdp version of the 183 uptream sends to asterisk bumps the sdp version number |
| 11:26.40 | tsearle | so I don't know if that will make your suggestion more complex |
| 11:26.47 | gtjoseph | but the cseq is the same yes? |
| 11:26.53 | tsearle | yeah |
| 11:27.10 | tsearle | is there a way to upload a pcap to a jira & not have it public? |
| 11:27.23 | file | no |
| 11:27.38 | tsearle | ah well |
| 11:40.30 | tsearle | and ref your proposal |
| 11:41.02 | tsearle | what if, instead of fixing it in the asterisk level, since this is a fundamental issue with pjproject |
| 11:41.26 | tsearle | change pjproject to instead do nothing if you try sending a response when one has already been sent |
| 11:42.20 | tsearle | so that pjproject will never try to send inv->last_sent |
| 11:42.22 | file | define "sending a response" |
| 11:42.42 | file | because you can't stop responses, you could do a 603, or a busy here, or transition to a 180 |
| 11:43.14 | tsearle | I mean in this specific case where pjproejct session layer is trying to send inv->last_response |
| 11:43.48 | tsearle | will have to re-look at the code, but if you are trying to send a new error response then persumably it won't be trying to use that tdata |
| 11:44.52 | tsearle | ha no, lookng at the bactrace nvm |
| 11:45.13 | tsearle | it's actually asterisk that asking pjsip for a reference to inv->last_response |
| 11:45.15 | tsearle | then sending it |
| 11:53.31 | tsearle | acutally I don't think your suggestion will work |
| 11:53.49 | tsearle | <PROTECTED> |
| 11:54.05 | tsearle | that line there is what give chan_pjsip the tdata reference |
| 11:54.33 | tsearle | but it's also the method that will call pjsip_dlg_modify_response |
| 11:55.10 | tsearle | which will always have a risk of causing a retransmittion timer going into an infinite loop |
| 11:57.07 | gtjoseph | coreyfarrell: ping me when you get a chance about postgresql startup. |
| 11:57.10 | tsearle | <PROTECTED> |
| 11:57.45 | file | goes to read what gtjoseph said in the issue |
| 11:59.36 | file | tsearle: are you referring to a different response code being sent while it is sending the previous response again? |
| 12:00.22 | file | if not then you need to be more clear of the specific scenario and details instead of going directly to code, or else we'll be lost |
| 12:00.33 | tsearle | in this case I don't think the response code changing matters |
| 12:00.58 | file | his comment on the review was - don't even call pjsip_inv_answer if a 183 was already sent |
| 12:00.58 | tsearle | indicate calls ses_inv/pjsip_inv_answer |
| 12:01.24 | tsearle | ok |
| 12:01.57 | tsearle | but if indicate is called with a different status code |
| 12:02.24 | tsearle | pjsip_inv_answer will modify the existing tdata still |
| 12:04.29 | tsearle | so you prevent the race condition of the destination sending asterisk a 183 after 60 causing a race condition |
| 12:04.44 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 12:04.46 | tsearle | but if the carrier sends a different response code after 60 seconds, then the issue can still happen |
| 12:06.14 | tsearle | the only way I can see pjsip_inv_answer ever being safe to call is if you make sure there are no active retransmisison timers |
| 12:06.34 | tsearle | (or have indicate kill all existing retransmission timers) |
| 12:07.28 | tsearle | am I making any sense? |
| 12:07.45 | file | more sense than you were when you didn't provide enough context ^_^ |
| 12:07.52 | file | but yes |
| 12:17.27 | tsearle | ok so I can call pjsip_tsx_stop_retransmit(session->inv_session->invite_tsx) in indicate before doing pjsip_inv_answer |
| 12:17.43 | tsearle | then the tsx group lock won't be held at the same time as the dialog lock |
| 12:19.21 | coreyfarrell | gtjoseph: ping |
| 12:19.32 | gtjoseph | hey |
| 12:20.16 | gtjoseph | so for postgresql, because of the differences between redhat and ubuntu postgresql packages, there's no simple way to initialize it. |
| 12:20.28 | gtjoseph | i can start it if it's there and ready |
| 12:20.35 | file | tsearle: that seems more palatable |
| 12:21.01 | tsearle | I think it will still be determind |
| 12:21.20 | tsearle | think there is still in theory a race condition between the transaction timeout timer and indicate() |
| 12:21.30 | tsearle | but I think killing the timeout timer is probably a bad idea, heh |
| 12:22.08 | gtjoseph | coreyfarrell: also can you suppress the jansson build output like we do for pjproject? |
| 12:22.20 | coreyfarrell | gtjoseph: I'm using Fedora 28 for my CI image. I've installed postgresql-server. |
| 12:22.30 | coreyfarrell | sure I'll patch that soon |
| 12:22.56 | gtjoseph | the problem is that just installing the package doesn't initialize the environment |
| 12:23.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:41c0:87d9:904f:8ace) |
| 12:24.27 | gtjoseph | coreyfarrell: look in /var/lib/pgsql |
| 12:24.40 | gtjoseph | is there a data directory and does it have a PG_VERSION file in it? |
| 12:25.48 | coreyfarrell | the data directory is empty |
| 12:25.52 | gtjoseph | yeah |
| 12:26.54 | gtjoseph | and it's different for ubuntu |
| 12:27.38 | gtjoseph | the docker setup stuff we use has different scripts depending on distro |
| 12:28.55 | gtjoseph | So, I _could_ include all that stuff in CI but is it worth it? I could also just include samples and docs to set up the docker environment youself and just have CI strt postgres |
| 12:29.31 | coreyfarrell | once I figure out how I hope to have the Dockerfile initialize /var/lib/pgsql |
| 12:29.42 | gtjoseph | ok, i can send you what we do. |
| 13:21.02 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 13:50.19 | *** join/#asterisk-dev seanbright (~sean@asterisk/community-developer/seanbright) |
| 13:50.19 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 14:09.57 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-llemcoqngoakjkld) |
| 14:09.57 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:17.38 | tsearle | ERROR: Branch not suitable for integration as it does not merge cleanly: |
| 14:17.50 | tsearle | did I do something wrong, or is jenkins broke again? |
| 14:18.33 | file | I just rebased it on top, we'll see what happens |
| 14:18.48 | tsearle | thanks |
| 14:19.00 | file | dealdock :D |
| 14:19.29 | tsearle | ah, I did a typo in the commit message? |
| 14:20.11 | file | containging too |
| 14:22.00 | tsearle | can I just invent a meaning for those words? it worked for covfefe |
| 14:22.01 | tsearle | :-P |
| 14:22.56 | tsearle | fixed |
| 14:23.27 | tsearle | and I did a fresh git review -d first, so hopefully it didn't do anything evil like un-rebaseing |
| 14:28.21 | tsearle | hrm... why is gerrit mentioning a commit with a different change-id & topic as a "related change" ? |
| 14:29.32 | tsearle | https://gerrit.asterisk.org/#/c/asterisk/+/9477/ claims to be related to 9663 |
| 14:31.00 | file | dunno, would have to look into how Gerrit determines related changes |
| 14:37.27 | *** join/#asterisk-dev tzafrir (~quassel@lemon.tzafrir.org.il) |
| 14:37.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:43.59 | tsearle | @rmudgett are you here? |
| 14:47.08 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-pyhgmlbulslhviyu) |
| 14:47.08 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:59.34 | tsearle | ah well, I'm off, have a good day all! :-) |
| 15:12.20 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-gmqojlvlekfeapbf) |
| 15:12.20 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:17.00 | *** join/#asterisk-dev pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 16:16.22 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.173) |
| 21:26.13 | *** join/#asterisk-dev pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 21:35.46 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 23:11.05 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-llemcoqngoakjkld) |