| 00:37.48 | *** join/#asterisk-dev file (sid178970@asterisk/developer-and-muffin-lover/file) |
| 00:37.48 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 00:41.49 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 02:08.14 | *** join/#asterisk-dev zerohalo (sid288136@gateway/web/irccloud.com/x-penbadeteimiqclt) |
| 03:30.00 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-olbfjmvsnfkhpphk) |
| 03:30.00 | *** mode/#asterisk-dev [+o csavinovich] by ChanServ |
| 03:33.38 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 06:53.10 | *** join/#asterisk-dev zerohalo (sid288136@gateway/web/irccloud.com/x-nhbmeridsxfusdqc) |
| 06:57.39 | *** join/#asterisk-dev tuxd00d (sid401305@gateway/web/irccloud.com/x-dkucxrkqrjnoxzkq) |
| 06:58.43 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-iunekzfqlitsqiiu) |
| 06:58.43 | *** mode/#asterisk-dev [+o GameGamer43] by ChanServ |
| 06:59.19 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-hpgivilnsnwkujha) |
| 07:07.03 | *** join/#asterisk-dev file (sid178970@asterisk/developer-and-muffin-lover/file) |
| 07:07.03 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 07:07.46 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-lqvvynsztspbjrfv) |
| 07:11.13 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:21.29 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-fhhygnhabgmuuawq) |
| 07:21.30 | *** mode/#asterisk-dev [+o csavinovich] by ChanServ |
| 07:22.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@126.185-60-37.rdns.acropolistelecom.net) |
| 07:34.50 | *** join/#asterisk-dev jkroon (~jkroon@41.113.34.204) |
| 07:45.02 | *** join/#asterisk-dev jkroon (~jkroon@41.113.34.204) |
| 07:49.25 | *** join/#asterisk-dev jkroon (~jkroon@41.113.34.204) |
| 10:53.58 | *** join/#asterisk-dev greenlight (d924ef26@host217-36-239-38.in-addr.btopenworld.com) |
| 10:54.53 | greenlight | Hi there. I'm wondering if there's a reason a delay of 200ms is added to many stasis requests, via "#define MAX_WAIT_MS 200 |
| 10:56.31 | wdoekes | seanbright: ouch, that's one cynical contributor :) |
| 10:57.46 | greenlight | I've changed in the source to 50ms with has reduced the delay in calls being bridged and stopped the first word spoken getting chopped, but that feels hacky... |
| 10:58.38 | wdoekes | I suspect no one uses minmemfree with any reasonably high number, or there would've been more reports |
| 11:32.42 | file | wdoekes: first time I've ever seen anyone use it |
| 11:33.11 | file | greenlight: I don't think there was an explicit reason David chose that except that it felt fine |
| 11:33.40 | file | going lower just increases the amount of thread execution when no frames come in |
| 11:34.35 | greenlight | Yea, i guess its a balance. But in the case of bridging a call that's been answered, 200ms causes audible chopping of the first word spoken |
| 11:34.56 | greenlight | Would you be open to changing it to 50ms? |
| 11:35.36 | file | I'd probably explore using pthread_kill instead when there's activity on the control queue to instantly wake up that thread |
| 11:36.34 | greenlight | That would be even better, yes |
| 11:37.15 | file | otherwise nothing comes to mind dropping it to 50, but during review others may think of something |
| 11:40.31 | greenlight | I'm not very familiar with the stasis parts of the source code, but will have a poke around and see where about I'd need to make changes to wake it up instantly |
| 12:17.19 | *** join/#asterisk-dev jkroon (~jkroon@41.113.88.193) |
| 12:22.36 | *** join/#asterisk-dev jkroon (~jkroon@41.113.88.193) |
| 12:24.32 | *** join/#asterisk-dev jkroon (~jkroon@41.113.88.193) |
| 12:42.25 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 13:08.11 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 13:27.48 | seanbright | wdoekes: really rubs me the wrong way, frankly. |
| 13:28.35 | seanbright | i wrote about 10 different responses before settling on that one. |
| 13:38.45 | seanbright | i would argue that if you have 14GB of free memory sitting in filesystem cache that you probably don't need the minfreemem option at all |
| 13:40.28 | file | seanbright: you dabbled in realtime between 16.6.2 and 16.7.0 didn't you? |
| 13:40.50 | seanbright | define dabbled |
| 13:40.54 | seanbright | "broke something?" |
| 13:40.58 | file | maybe? |
| 13:41.01 | file | https://issues.asterisk.org/jira/browse/ASTERISK-28694 |
| 13:41.37 | file | I guess Kevin could have broken it too with the lgtm change |
| 13:42.23 | file | phoneprov specific change for that isn't that suspect or fancy... |
| 13:42.48 | seanbright | i don't know what i changed between those two versions, i can diff it and see if anything looks interesting |
| 13:44.38 | file | nothing that exciting... interesting |
| 13:52.37 | seanbright | 518b6bfb5c370a015d5ddd0b67d53bb6da67a5f7 maybe |
| 13:56.06 | file | hrm! |
| 13:56.25 | seanbright | but i don't touch that module there |
| 13:56.29 | file | yeah |
| 13:56.41 | file | I don't see how that would do it |
| 14:26.36 | wdoekes | `*prev = replacement;` <- is that correct? |
| 14:29.04 | wdoekes | oh, missed the assigment in in the for(), never mind |
| 14:39.10 | *** join/#asterisk-dev sahmed (~sahmed@66.64.44.146) |
| 14:43.09 | gtjoseph | @seanbright: +1 to your responses to kevin :) |
| 14:43.46 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-bnjtxrauypbrqdnh) |
| 14:43.46 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:44.27 | file | https://issues.asterisk.org/jira/browse/ASTERISK-28698 thoughts? |
| 14:54.29 | *** join/#asterisk-dev sahmed (~sahmed@66.64.44.146) |
| 14:59.34 | Corydon76 | 128/1.44 |
| 14:59.38 | Corydon76 | argh |
| 15:04.11 | kharwell | file: for that function does "1" equate to an error? Usually 0 is success no? |
| 15:04.58 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-izsxlycfimqvehup) |
| 15:04.58 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:05.10 | kharwell | if 1=error I don't see a problem there really. Just use dialplan to catch it |
| 15:05.16 | file | 0 = variable not set |
| 15:05.27 | file | 1 = variable is set, value in parentheses |
| 15:05.43 | kharwell | sounds like a bug then? |
| 15:05.53 | file | yes, it's a behavior change introduced in 12.0.0 |
| 15:07.48 | file | AGI is weird with those return values |
| 15:07.53 | file | c'est la vie |
| 15:20.42 | seanbright | gtjoseph: you've futzed with pjsip code in this area before, no: https://issues.asterisk.org/jira/browse/ASTERISK-26955 |
| 15:21.01 | gtjoseph | looks |
| 15:21.28 | seanbright | doing some research last night it looks like we've made two patches around via parsing to upstream |
| 15:22.33 | gtjoseph | yeah. I _thought_ we squashed those ipv6 issues. |
| 15:23.42 | gtjoseph | what i don't remember is whether we had to fix both asterisk and pjproject. |
| 15:23.54 | seanbright | so this is a bit if a weird one... |
| 15:24.27 | seanbright | technically, the 'received' parameter _should not_ have brackets around an IPv6 address (per RFC 3261) |
| 15:24.33 | file | I don't think we've touched Via for this |
| 15:24.42 | file | there was a spot in websockets where brackets weren't right |
| 15:24.55 | seanbright | but in RFC 5118 section 4.5: https://tools.ietf.org/html/rfc5118#section-4.5 |
| 15:25.08 | gtjoseph | yeah, "robust" |
| 15:25.13 | seanbright | While it would be beneficial if the same non-terminal ("IPv6reference") was used for both the "sent-by" and "via-received" production rules, there has not been a consensus in the working group to that effect. Thus, the best that can be suggested is that implementations must follow the Robustness Principle [RFC1122] and be liberal in accepting a "received" parameter with or without the delimiting |
| 15:25.19 | seanbright | "[" and "]" tokens. When sending a request, implementations must not put the delimiting "[" and "]" tokens. |
| 15:25.22 | seanbright | right |
| 15:25.51 | seanbright | i am firmly against the "robustness principle" |
| 15:25.52 | seanbright | BUT |
| 15:26.10 | seanbright | should we just try raising it as a bug with pjsip and see what happens? |
| 15:26.39 | gtjoseph | I would say it's a bug. whether it's theirs or ours i'm not sure. |
| 15:26.54 | gtjoseph | i guess it's theirs |
| 15:26.59 | file | yes |
| 15:27.03 | gtjoseph | since they'd be parsing that before it gets to us |
| 15:27.48 | gtjoseph | seanbright: the way we do pjproject bugs is we usually come up with the patch and send it to them. |
| 15:28.01 | seanbright | right, but this has been a bug for over 2 years |
| 15:28.06 | seanbright | might be better to just punt |
| 15:28.16 | seanbright | like... we obviously don't care that much |
| 15:28.19 | seanbright | maybe they will? |
| 15:28.52 | seanbright | i can certainly try to whip up a patch |
| 15:28.57 | gtjoseph | we could but it leaves it hanging out there. if it's a one or two line fix, we might be better off just fixing it and sending them the patch |
| 15:29.03 | seanbright | ok |
| 15:29.44 | file | the person on the issue stated a starting point |
| 15:29.46 | gtjoseph | Have you done a pjproject patch before? I don't remember. |
| 15:29.53 | seanbright | i have |
| 15:29.59 | gtjoseph | cool. |
| 15:30.48 | seanbright | the suggestion by OP is kinda the direction i was thinking, but it feels wrong |
| 15:31.14 | seanbright | i guess because you could have: received=2a00:123:][][][c17:1c3f::5 |
| 15:31.17 | seanbright | and that would parse |
| 15:31.24 | seanbright | BUT, it would fail address parsing later |
| 15:31.34 | seanbright | so maybe that isn't the end of the world |
| 15:32.29 | gtjoseph | i take it VIA_PARAM_SPEC is just a list of valid characters? |
| 15:33.34 | gtjoseph | it may be that the actual address parsing code was changed to accept the brackets but someone forgot to add the brackes to the PARAM_SPEC |
| 15:34.11 | seanbright | we're also assuming this is still a bug |
| 15:34.22 | seanbright | well, i am anyway |
| 15:34.32 | seanbright | will wait to hear back from the reporter about trying in the latest version |
| 15:34.38 | gtjoseph | yeah. cool. |
| 15:54.32 | seanbright | rmudgett: i believe the value is in kb |
| 15:58.55 | rmudgett | seanbright: The next statement divides by a megabyte (1024*1024). Which leads me to believe that the calculated value that could overflow is in bytes. |
| 15:59.55 | seanbright | you appear to be correct |
| 16:00.09 | seanbright | i wonder if it changes mem_unit based on the scale of the numbers |
| 16:00.11 | seanbright | but whatever |
| 16:01.50 | seanbright | rmudgett: does a long always have 32 bits? |
| 16:02.03 | seanbright | on my machine it's 64 |
| 16:02.37 | rmudgett | You have to assume it only has 32 as that is the minimum size of a long. |
| 16:02.42 | seanbright | i see |
| 16:05.31 | seanbright | rmudgett: so. totalram, freeram, and bufferram are all unsigned longs |
| 16:06.02 | rmudgett | sounds like a uint64_t cast is needed. :) |
| 16:06.03 | seanbright | and i assume that totalram = (freeram + bufferram + <memory in use>) |
| 16:06.29 | seanbright | so wouldn't totalram already have overflowed? |
| 16:06.35 | seanbright | like, in glibc or the kernel? |
| 16:07.46 | rmudgett | Well, the mem_unit value would reduce the need for larger variables. |
| 16:09.46 | seanbright | ok, so if mem_unit > 1, that scales all of the values appropriately |
| 16:09.53 | seanbright | so you shouldn't be able to overflow |
| 16:10.29 | seanbright | if it holds that freeram + bufferram + fudge = totalram |
| 16:10.30 | rmudgett | Right. But the calculation is converting the units into bytes. |
| 16:10.44 | seanbright | OH |
| 16:10.47 | seanbright | ok then yes |
| 16:44.12 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.110) |
| 16:49.43 | seanbright | i wonder how many places we do signed overflow in asterisk |
| 16:49.50 | seanbright | probably best not to ponder such questions |
| 16:58.02 | file | seanbright: YOU FOUND IT |
| 16:59.16 | seanbright | hmm? |
| 16:59.30 | file | the AOR crash group lock thingy |
| 16:59.37 | seanbright | yes |
| 16:59.37 | file | I knew I had seen a backtrace like it in the past |
| 17:00.02 | seanbright | i'm pretty good at this whole jira thing |
| 17:00.17 | file | did you go and take a course? |
| 17:01.12 | seanbright | no, read a book: masochism for dummies |
| 17:01.22 | file | harsh |
| 17:03.11 | seanbright | they need to just throw away this group lock implementation and start over |
| 17:03.16 | seanbright | something is just fundamentally wrong |
| 17:04.51 | file | I think it's two factor |
| 17:05.06 | file | 1. The fact we are multithreaded and use a dispatch model is different than others |
| 17:05.16 | file | 2. Group locks were an addition, so there may still be circumstances/scenarios where they aren't right |
| 18:28.05 | seanbright | rmudgett: potentially interesting to you (but who knows): |
| 18:28.07 | seanbright | curfreemem = sys_info.freeram + sys_info.bufferram; |
| 18:28.20 | seanbright | that wraps around, even when curfreemem is uint64_t |
| 18:28.46 | seanbright | the addition is done as ulong |
| 18:28.59 | seanbright | curfreemem = (uint64_t) sys_info.freeram + sys_info.bufferram; |
| 18:29.30 | seanbright | that ends up correct, because it promotes freeram to a 64 but int and then bufferram gets promoted implicitly |
| 18:29.32 | seanbright | i... think |
| 18:29.53 | seanbright | 64 *bit* int, not but |
| 18:30.00 | seanbright | that's a different thing altogether |
| 18:30.32 | rmudgett | That isn't where the overflow would occur though. |
| 18:31.03 | seanbright | uint64_t total = some_ulong_value + another_ulong_value; |
| 18:31.17 | seanbright | that wraps around, even when total is uint64_t |
| 18:31.22 | seanbright | i am just pointing that out |
| 18:32.10 | rmudgett | Yes. I wouldn't expect that those values would overflow because they would already be scaled by mem_unit uinits |
| 18:32.15 | seanbright | correct me if i am wrong, but without casts, integer operands will all be promoted to the largest size? |
| 18:39.28 | seanbright | ok, i did _exactly_ what you said, so there couldn't possibly be another -1 |
| 18:39.36 | seanbright | inconceivable |
| 18:41.27 | file | if there is then rmudgett is to fix it |
| 18:41.48 | seanbright | i like it |
| 18:42.16 | file | I shall use my non-existent authority to make it happen |
| 18:43.22 | *** join/#asterisk-dev aa1001 (~aa1001@office.ptera.net) |
| 18:46.30 | rmudgett | gets out my +1 |
| 18:48.16 | seanbright | wonderful |
| 18:48.20 | seanbright | i'm glad we've put that behind us |
| 18:48.27 | file | what's next? |
| 18:48.37 | seanbright | https://gerrit.asterisk.org/c/asterisk/+/13598 |
| 18:48.43 | seanbright | :P |
| 18:48.54 | file | did you say something? |
| 18:49.03 | seanbright | heh |
| 19:04.44 | coreyfarrell | I'm (finally) working on switching to chan_pjsip for the first time in a very simple test case, sip_to_pjsip.py gave me https://gist.github.com/coreyfarrell/8a639577ead3a1fb806ef948c14436a9 |
| 19:05.01 | coreyfarrell | 1) is this reasonable, 2) what happened to qualify, 3) what do I do if I have 2 endpoints on the same IP but different ports, how would the `type = identify` be altered to deal with this? |
| 19:07.54 | seanbright | 1) looks reasonable to me |
| 19:08.01 | seanbright | 2) :shrug: |
| 19:08.29 | seanbright | 3) i just added source port support to the match clause, so you could do "match = 127.0.0.1:5062" |
| 19:09.21 | seanbright | assuming you are running from git |
| 19:09.32 | seanbright | otherwise 3 won't work until the next release |
| 19:10.51 | coreyfarrell | good to know. what branches for #3? |
| 19:11.06 | seanbright | all of them |
| 19:11.20 | seanbright | for qualify i think you want to add 'qualify_frequency = 60' to the aor |
| 19:11.25 | coreyfarrell | ah I see it in 13 now |
| 19:12.41 | rmudgett | Remember 13 enters security fix in october |
| 19:12.48 | rmudgett | the end is near |
| 19:18.14 | coreyfarrell | upgrade to asterisk 16 is on my list but for now I'm just switching to pjsip. |
| 19:20.17 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 19:58.19 | file | seanbright: what have you done... |
| 19:59.10 | seanbright | eh? |
| 19:59.14 | seanbright | fixed some bullllllshit |
| 20:00.06 | seanbright | i will not be happy until the entire first page of gerrit is just my face over and over again |
| 20:00.09 | seanbright | then i can rest |
| 20:02.11 | file | plz don't rewrite app_voicemail kthx |
| 20:02.25 | seanbright | you couldn't pay me enough |
| 20:06.28 | kharwell | is it still app_voicemail if all the underlying code has been replaced one small patch at a time? |
| 20:07.27 | file | it finds a way... |
| 20:08.15 | rmudgett | gradually brings a pot of frogs up to a boil... err gradually changes lines in app_voicemail untill all are replaced. |
| 20:11.28 | seanbright | just remove all of the IMAP and ODBC code and you're already 1000 times better |
| 20:11.42 | seanbright | so looking here: |
| 20:11.43 | seanbright | https://jenkins2.asterisk.org/job/asterisk-gatetests/job/13/774/consoleText |
| 20:11.57 | seanbright | are the tests run in parallel or just a non-deterministic order? |
| 20:12.33 | file | parallel |
| 20:21.30 | seanbright | https://github.com/asterisk/testsuite/blob/master/tests/channels/SIP/custom_info/sipp/send_all.xml |
| 20:21.36 | seanbright | i find that scenario file interesting... |
| 20:24.55 | rmudgett | Because the contents are duplicated in the file? |
| 20:25.36 | rmudgett | or the SIP user in the messages? |
| 20:25.37 | seanbright | correct |
| 20:25.40 | seanbright | the first |
| 20:28.35 | seanbright | newer versions of sipp must be more strict with xml parsing |
| 22:17.01 | kharwell | seanbright: do you want help in your goal to rule the gerrit front page (25 rows per page version at least)? |
| 22:17.25 | seanbright | i've grown so tired over these last hours |
| 22:19.05 | kharwell | there ya go. achievement unlocked! |
| 22:19.25 | seanbright | fantastic |
| 22:19.27 | seanbright | what do i win? |
| 22:20.34 | kharwell | more issues |