| 00:19.21 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 00:19.21 | *** 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 |
| 15:00.10 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:00.10 | *** 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 |
| 15:02.15 | file | rmudgett: https://issues.asterisk.org/jira/browse/ASTERISK-27094?filter=12936 ouchy |
| 15:18.50 | rmudgett | file: What about the issue? |
| 15:19.35 | file | Do you know where the problem is? |
| 15:22.58 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 15:31.31 | rmudgett | file: That backtrace is almost useless. Its missing line numbers and most function parameters to match up with a deadlocking thread. However, I think I see a deadlock potential between bridges. The first call to ast_indicate() in bridge_channel_internal_join() has the bridge locked. Since he is using a local channel with the fax call we try to reach across a bridge. |
| 15:32.03 | file | Yeah |
| 15:32.16 | file | Such fun |
| 15:32.21 | rmudgett | I cannot be certain since I don't know which threads are deadlocked. |
| 15:32.57 | file | Can you triage it and ask for anything extra? |
| 15:33.38 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:33.53 | rmudgett | About the only thing we would need is a better backtrace at a minimum. A core show locks would be better of course. |
| 15:52.05 | rmudgett | file: Ok. Put a comment on the issue and requested feedback. |
| 15:56.01 | file | merci |
| 15:56.10 | file | I was on a bus at the time |
| 16:04.05 | kharwell | file: these changes I am making for the FIR stuff seem gross. I'm wondering now if there is another way or if I am putting the tracking field in the wrong place. |
| 16:04.50 | file | suspects wrong place |
| 16:04.54 | kharwell | I currently have a new field on the ast_rtp_payload_type struct called rtcp_fir |
| 16:05.30 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-248-133.hsd1.co.comcast.net) |
| 16:05.31 | kharwell | basically that specifies if the rtcp fir feedback has been negotiated for that payload type |
| 16:05.40 | file | yup |
| 16:06.49 | kharwell | that's required me to create a set of get/set functions that require looping over the codecs structure each time |
| 16:07.21 | kharwell | and in the case of "set" searching, cloning and then replacing the old value |
| 16:08.03 | file | why iterating? |
| 16:08.44 | kharwell | whoops yeah I misspoke. It just does a vector get |
| 16:09.22 | file | that's what I expected you'd end up with |
| 16:09.59 | kharwell | okay cool. I'll continue down that path then |
| 16:17.32 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 16:53.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 17:21.27 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 18:02.01 | *** join/#asterisk-dev newtonr (~newtonr@99-104-129-136.lightspeed.brhmal.sbcglobal.net) |
| 18:02.01 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:02.21 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-kxpefxjqedolotxg) |
| 18:02.22 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:37.49 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.166) |
| 18:55.45 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ydsxvdzsfsfbiuwm) |
| 18:55.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:35.50 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-vptntrlfmnsxljws) |
| 19:35.51 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:43.17 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 19:58.35 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 20:01.21 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 20:10.31 | bford | currently working on https://issues.asterisk.org/jira/browse/ASTERISK-27036, there's a crash when PJSIP tries to parse a "from_user" field with certain characters (@, ^, {, etc.) when making calls via trunk |
| 20:10.39 | bford | it returns null and we pass it through our code |
| 20:11.01 | bford | i have a fix for it, but does anyone feel strongly about a certain way to fix this? |
| 20:11.40 | bford | implemented a null check and another check when we parse the "from_user" field in the configuration |
| 20:21.31 | kharwell | I don't. Although instead of validating against what is not allowed in the from user it might be easier/more advantageous to validate against what is allowed |
| 20:25.29 | bford | I'll change it to a valid character check |
| 20:27.02 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:27.59 | kharwell | check out section 25 in rfc3261 for what constitutes a valid user in a sip uri |
| 21:24.50 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-mahoauloyiwkkvpo) |
| 21:52.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 21:52.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:35.17 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ubkhfbiqrzvavecr) |