| 00:05.46 | coreyfarrell | jpsharp: if you're using asterisk 16 you can enable from asterisk.conf |
| 00:16.11 | jpsharp | I wish I was. |
| 00:18.41 | jpsharp | Seems to be some sort of ref counting issue in the local channel. |
| 00:23.43 | snuff-work | runs away |
| 00:32.32 | jpsharp | does calling ast_channel_get_by_name increase a channel ref counter? |
| 00:36.12 | file | yes. |
| 00:36.23 | file | it returns the channel with its refcounted bumped so that it doesn't go away |
| 07:40.07 | *** join/#asterisk-dev jkroon (~jkroon@41.114.74.43) |
| 10:05.41 | *** join/#asterisk-dev jkroon (~jkroon@41.114.74.43) |
| 10:53.53 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 10:58.08 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 12:09.52 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-umdvykalkhcroord) |
| 12:09.52 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 13:02.35 | *** join/#asterisk-dev spditner (~simon@toroon0560w-lp130-12-70-50-22-69.dsl.bell.ca) |
| 14:00.46 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 14:03.14 | stevedavies | Does anyone recall if there was a bug in the AMI service - I have a 13.10.0 system. We are issuing a Redirect and then a Call action at the same time into the manager interface and find that sometimes Asterisk doesn't execute the Redirect. Could it be a race of some sort? |
| 14:04.09 | gtjoseph | It's hard to say. 13.10.0 is pretty old. |
| 14:04.26 | stevedavies | nods |
| 14:04.41 | stevedavies | I'll look at commits to see what I can find |
| 14:08.50 | stevedavies | Last change to app_channelredirect.c itself in 13 was 8 years ago... |
| 14:09.11 | tsearle | @file |
| 14:09.30 | tsearle | 't' should be capitalized in "This 183 can" |
| 14:09.36 | tsearle | "this can" is the 2nd word in the scentence "Forwarding this 183 can" |
| 14:09.37 | tsearle | (I'll look into changes and sample) |
| 14:09.58 | file | oh Gerrit presented it funny |
| 14:10.31 | gtjoseph | stevedavies: the issue may not be in app_channelredirect itself. |
| 14:10.56 | tsearle | so, if that description is now blessed I'll propagate it to the sample config :D |
| 14:11.30 | gtjoseph | tsearle: did you see my questions about alembic yesterday? |
| 14:11.58 | stevedavies | @gtjoseph indeed more likely in the actual manager.c or related |
| 14:11.59 | file | tsearle: it's fine |
| 14:13.18 | tsearle | gtjoseph: no I didn't, is it ref the error I encountered when trying to run it? |
| 14:13.36 | gtjoseph | yeah. was asking about versions of alembic, sqlalchemy |
| 14:13.47 | gtjoseph | your alembic version seems old |
| 14:13.59 | tsearle | @gt |
| 14:14.46 | tsearle | @gtjoseph I was using mysql |
| 14:15.13 | tsearle | alembic 0.9.3-2ubunt |
| 14:15.21 | gtjoseph | hmmm. i'll try with mysql but it didn't look like it was getting that far. |
| 14:15.35 | tsearle | python3-sqlalc 1.1.11+ds1-1 |
| 14:16.38 | tsearle | so basically I'm using what ships with ubuntu 18.04 |
| 14:16.47 | gtjoseph | gotcha |
| 14:16.53 | gtjoseph | i'll double check mysql then |
| 14:18.41 | tsearle | for my stuff, I just removed the offending param and I was able to get past the error |
| 14:19.01 | gtjoseph | ok thanks. |
| 14:57.20 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.41.161) |
| 15:00.04 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:00.04 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:25.47 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gkwbsuopafbyewce) |
| 15:25.47 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:33.46 | file | seanbright: I brought that up earlier in a review, forgot to ask it again |
| 15:34.11 | seanbright | ah. yes you did. sorry about that. |
| 15:34.26 | seanbright | re: https://gerrit.asterisk.org/c/asterisk/+/11085 |
| 15:34.43 | seanbright | all (most?) of the call sites are passing unsigned ints, so i'm not sure what the point of changing the type is |
| 15:41.36 | seanbright | what is the general concensus on https://gerrit.asterisk.org/c/asterisk/+/10715 |
| 15:42.09 | file | I gave my thoughts on 10715 already :D |
| 15:42.12 | seanbright | i feel like there are already a few other ways to get this information |
| 15:43.32 | file | seanbright: yeah I'm not sure either re 11085... I also looked at history and it's been that way for ages... |
| 15:43.36 | seanbright | sorry - i'm using polygerrit now and it hides the earlier messages by default |
| 15:49.07 | pchero_work | Ah, my commit. |
| 15:54.50 | pchero_work | Thanks for talking about my stuffs, ask to me if have any question. :P |
| 16:01.23 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:03.09 | pchero_work | all (most?) of the call sites are passing unsigned ints, so i'm not sure what the point of changing the type is -> Yes, that's why it making the crash in potentially. the RTP structure keeps the count number itself and keep increasing it as an unsigned integer type. So it's possible to hits to the 0 eventually. |
| 16:03.14 | seanbright | i personally don't like the debug/ari module |
| 16:03.23 | pchero_work | Ah⦠|
| 16:03.25 | seanbright | we already have the logger, hep, and there is always pcapsipdump |
| 16:04.10 | seanbright | i'm not going to -1 it, but i just don't think it is necessary and it just becomes another module to maintain - community supported or not |
| 16:04.40 | file | seanbright: thanks for looking at some things |
| 16:04.41 | seanbright | re: unsigned ints, just changing the argument is not going to change the rollover |
| 16:04.52 | seanbright | argument type* |
| 16:05.30 | seanbright | file: you're... welcome? |
| 16:05.35 | file | :D |
| 16:06.12 | pchero_work | seanbright: I've got it. :) I don't mind with that. |
| 16:07.38 | seanbright | does sample_count start at 0? |
| 16:07.56 | seanbright | and if so, how long would a call have to go on to rollover? |
| 16:08.32 | pchero_work | Yes, sample_count start a 0. |
| 16:08.45 | seanbright | (i don't know this code well, so forgive me if i am asking dumb questions) |
| 16:08.56 | pchero_work | So, normally, the divide by zero will not happen for normal situation. |
| 16:09.05 | pchero_work | seanbright: Don;t mind that. :) |
| 16:09.38 | seanbright | i guess my question is this |
| 16:09.45 | pchero_work | But afaik, there's no rule for rtcp sending delay time. |
| 16:10.14 | seanbright | if i call would have to go on for some unreasonable amount of time (years) for this to occur, we probably don't need to worry about it |
| 16:10.30 | seanbright | if it's more on the order of days, it might be worth changing |
| 16:10.53 | seanbright | but we would have to change the types that we are passing in to stddev_compute(), not just the argument type of the function |
| 16:11.09 | seanbright | none of that was a question... sorry for saying it was :D |
| 16:11.35 | pchero_work | That might be ok to keeping it as unsigned int for callers. |
| 16:11.57 | seanbright | so step 1 is, evaluate the call sites and determine risk of rollover |
| 16:12.24 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:12.27 | pchero_work | All we have to do is having a bigger type than caller. |
| 16:12.35 | seanbright | the other option - just to avoid the crash - is to just do something like: |
| 16:12.42 | seanbright | if (!sample_count) sample_count = 1; |
| 16:12.52 | seanbright | and the data will be wrong, but at least it won't crash |
| 16:13.32 | pchero_work | Yes, I've thought about that too. :) But don't want to add more condition into function. Cause it will affect to the performance. |
| 16:14.30 | pchero_work | It's trick. Agree. :P hard to reproduce it. Btw, if I reproduce the bug, it will be security issue btw. |
| 16:15.51 | pchero_work | I don't know how to generate many RTCP packets.. any idea? :P |
| 16:17.03 | csavinovich | use the WEBRTC based cyber_mega_phone program |
| 16:17.39 | seanbright | hmm |
| 16:17.40 | pchero_work | Can I manage the RTCP sending interval? |
| 16:17.48 | csavinovich | yes |
| 16:18.03 | pchero_work | Ah,, haven use that one before.. any other options? :P |
| 16:18.04 | csavinovich | as far as I remember from the rtp.conf |
| 16:18.12 | pchero_work | haven.t |
| 16:20.22 | seanbright | so the 4 values that we pass as the last argument to stddev_compute() are: |
| 16:20.35 | seanbright | rxlost_count, rxjitter_count, rtt_count, and reported_jitter_count |
| 16:20.50 | seanbright | none of them are provided from the remote site, we just ++ them all |
| 16:20.51 | pchero_work | Yes, |
| 16:21.08 | pchero_work | Yes. |
| 16:21.27 | pchero_work | And those values are increasing when the RTCP packet received. |
| 16:21.50 | pchero_work | And there's specified interval time for RTCP. |
| 16:21.54 | seanbright | right, but a 32 bit unsigned int is 4294967296 |
| 16:22.15 | pchero_work | Yes. |
| 16:22.43 | seanbright | ok |
| 16:22.48 | seanbright | here is my vote |
| 16:23.00 | seanbright | add code to stddev_compute() to protect against divide by zero |
| 16:23.15 | pchero_work | Hooray! |
| 16:23.36 | seanbright | i don't think it is likely enough a problem to cause any real world problem |
| 16:23.50 | seanbright | so rather than crash, we'll just return a bullshit value |
| 16:24.04 | seanbright | i don't think that is the end of the world |
| 16:24.24 | seanbright | i'd also be fine with upping those 4 types from int to long |
| 16:24.39 | seanbright | but you're just kicking the can down the road |
| 16:24.44 | pchero_work | Agree. ;) haha |
| 16:25.11 | cresl1n | Really far down the road |
| 16:25.14 | pchero_work | looks like bug, so I've ate them. |
| 16:25.33 | seanbright | cresl1n: i don't disagree |
| 16:26.04 | seanbright | but in 4011AD when that bug report is opened... |
| 16:27.55 | pchero_work | Im my calc, if someone sending a 100 RTPCs per seconds, it takes 497 days.. -_-;; |
| 16:28.03 | pchero_work | to hits the max. |
| 16:28.11 | rmudgett | In a 32 bit environment there isn't really a difference between an int and a long since both will be 32 bits. |
| 16:28.29 | seanbright | pchero_work: what are the implications of promoting those 4 variables to long? are they 100% internal to res_rtp_asterisk? are their ways to pull the values with a dialplan function or application? |
| 16:28.41 | seanbright | rmudgett: oh right... duh |
| 16:28.45 | seanbright | uint64_t |
| 16:28.48 | seanbright | that. |
| 16:29.59 | pchero_work | It will not affect to any result. It gets the unsigned integer type as a unsigned long and return the values. |
| 16:30.16 | pchero_work | All the callers are increasing the value by itselves. |
| 16:30.40 | pchero_work | That function is working alone. :P |
| 16:32.24 | seanbright | this is such a can of worms |
| 16:32.41 | seanbright | ok, i've lost patience |
| 16:32.54 | seanbright | change your patch to protect against divide by 0 |
| 16:33.11 | seanbright | you'll have to do it in normdev_compute as well |
| 16:34.23 | pchero_work | Ah, right. I was forgot about that. -_-;;; |
| 16:43.17 | seanbright | so i've brought this up before, but i need some advice |
| 16:44.05 | seanbright | we have ephemeral endpoints (and auths and aors) that are pulled in via realtime (res_config_curl) specifically. all of those objects have uuids for names. |
| 16:44.39 | seanbright | asterisk keeps them around and their associated task processors |
| 16:45.20 | seanbright | pjsip/options/<uuid>-00000001 and subp:PJSIP/<uuid>--00000001 |
| 16:45.27 | seanbright | lots and lots of them |
| 16:45.38 | seanbright | so my goal is to introduce a 'feature' that allows them to be cleaned up |
| 16:46.09 | seanbright | i could do it in a way that is very specific to my use case, but then i would have to maintain my own patch and we would really prefer to not do that |
| 16:48.12 | seanbright | so i guess my current thinking is (and this is partially based on previous conversations with file), that we'd have some kind of scheduled task that would traverse the relevant containers, re-validate the endpoints/auths/aors, and if they were no longer backed by the realtime engine, remove them. |
| 16:48.45 | file | it'd need to be optional, but I think that makes sense |
| 16:50.16 | seanbright | so something in [global] like 'prune_realtime_stuff = yes'? |
| 16:50.22 | seanbright | or a per-object flag? |
| 16:50.46 | file | hrm! |
| 16:51.02 | seanbright | like, i could see an 'ephemeral = yes' on objects |
| 16:51.08 | seanbright | but that could also get really noisy |
| 16:51.33 | seanbright | for the problematic task processors, it's just aors and endpoints |
| 16:52.44 | seanbright | the other option is that i change how my endpoints identify themselves so that things get re-used instead of an indefinitely growing list |
| 16:53.05 | seanbright | but that has other challenges |
| 16:54.23 | file | I think a global configurable interval for housekeeping is fine |
| 16:55.35 | seanbright | alrighty |
| 16:55.36 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:55.59 | seanbright | thank you for the feedback |
| 16:56.23 | file | some restrictions apply on feedback, see faxed document for details |
| 17:01.21 | seanbright | i added the global option but now i'm stuck... can you finish it? |
| 17:02.20 | file | have you tried turning it off and on again? |
| 17:03.59 | seanbright | that... worked?! |
| 17:08.05 | seanbright | do you think res_pjsip.c would be a reasonable place for said functionality? |
| 17:08.37 | file | yes |
| 17:08.54 | seanbright | kthx |
| 17:10.46 | rmudgett | Does not sorcery caching have anything to do with the keeping of these ephemeral objects? |
| 17:11.56 | seanbright | it does not |
| 17:13.04 | seanbright | nothing ever tell sorcery to delete them, so it doesn't |
| 17:13.09 | seanbright | tells* |
| 17:15.14 | seanbright | my user calls in, sorcery uses realtime to look them up, finds them, creates endpoints and aors and all that, the user hangs up |
| 17:15.28 | seanbright | the persistent_endpoints container keeps a reference to them |
| 17:15.42 | seanbright | the subp:PJSIP/<uuid>--00000001 taskprocessor sticks around |
| 17:15.49 | seanbright | and that is how we get here |
| 17:16.32 | seanbright | asterisk -rx "core show taskprocessors" | wc -l |
| 17:16.35 | seanbright | 46706 |
| 17:19.07 | seanbright | the potentially weird thing is going to be that i want to remove them from the container, but i don't really want to delete them via ast_sorcery_delete because that will fail (because the realtime engine won't be able to find the record because it doesn't exist) |
| 17:19.15 | seanbright | so i'll have to figure that one out somehow |
| 17:23.28 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 17:35.51 | seanbright | tsearle: overly pedantic - pjsip_rdata_get_sdp_info() will never return null |
| 17:37.20 | seanbright | think of the microseconds that could be saved. |
| 17:37.39 | seanbright | actually, it's not documented not to return NULL, so i guess it's not guaranteed in the future |
| 19:05.51 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 19:15.03 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 21:05.21 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 22:22.58 | *** join/#asterisk-dev snuff-work (~snuff-wor@202.161.112.134) |
| 22:22.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:18.59 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 23:30.05 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |