| 00:28.34 | mjordan | coreyfarrell: sorry about that; it's been added. I'm not sure it will produce exactly what you want, but I'm running the ref leak trunk job again so we can see what it dumps out |
| 00:29.25 | coreyfarrell | what do you mean might not produce what I want? should give a list of the number of leaked objects per refs.txt file in the logs dir |
| 00:31.36 | coreyfarrell | I assume you added the -b option if needed to point to the logs dir? |
| 00:39.23 | mjordan | it will process that and dump it out to a txt file |
| 00:40.35 | coreyfarrell | as long as that's being done once for the entire testsuite that's exactly what I want |
| 00:41.07 | mjordan | kk |
| 00:41.13 | coreyfarrell | just gives a list of how many ao2 objects were leaked by each instance of asterisk that was run (leak free tests are not listed) |
| 00:41.33 | coreyfarrell | anyways I gotta run thanks for taking care of that, I'll check on the trunk run tomorrow morning |
| 01:41.43 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:53.28 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 06:03.34 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 07:21.43 | X-Rob | [root@localhost limits.d]# ps -eLf | grep /usr/sbin/asterisk | wc -l |
| 07:21.44 | X-Rob | 1068 |
| 07:21.44 | X-Rob | [root@localhost limits.d]# |
| 07:22.07 | X-Rob | Should I REALLY have > 1K threads when I have 500 chan_sip peers? |
| 07:22.17 | X-Rob | (this is in 13.0.0) |
| 07:22.21 | X-Rob | I had 60 threads in 11. |
| 07:23.52 | X-Rob | 40 even. |
| 07:23.55 | X-Rob | 499 sip peers [Monitored: 0 online, 499 offline Unmonitored: 0 online, 0 offline] |
| 07:23.55 | X-Rob | localhost*CLI> quit |
| 07:23.55 | X-Rob | Asterisk cleanly ending (0). |
| 07:23.55 | X-Rob | Executing last minute cleanups |
| 07:23.55 | X-Rob | [root@localhost limits.d]# ps -eLf | grep /usr/sbin/asterisk | wc -l |
| 07:23.55 | X-Rob | 40 |
| 07:23.55 | X-Rob | [root@localhost limits.d]# |
| 07:31.42 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:02.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6998:c8e0:ea44:87c0) |
| 08:16.54 | *** join/#asterisk-dev tengulre (~tengulre@171.221.229.15) |
| 09:10.56 | skrusty | interesting ari error: Unrecognized recording error: Success |
| 09:45.14 | *** join/#asterisk-dev michael_work (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 10:12.35 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 10:17.17 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:17.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:18.52 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 10:26.39 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 12:14.40 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:03.46 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 13:03.46 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 13:04.28 | mjordan | X-Rob: someone else mentioned that but didn't give any information about what was going on. Can you use gdb and snag a backtrace of the threads? |
| 13:04.38 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-opedvnkavyaiyrwv) |
| 13:08.01 | coreyfarrell | mjordan: refleaks summary didn't work |
| 13:08.07 | mjordan | drat. |
| 13:10.37 | mjordan | I'll have to log into the build agent and see what transpired. |
| 13:11.00 | coreyfarrell | thanks |
| 13:12.05 | mjordan | X-Rob: Hm. I actually have a thought on what may be occurring. Do you have a mailbox set up for each of the 500 peers? |
| 13:16.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:28.15 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-enhlrxlsgukvtgvr) |
| 13:53.58 | file | falls over |
| 14:03.29 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 14:18.28 | *** join/#asterisk-dev Stefan27 (~stefan27@212.247.4.149) |
| 14:19.24 | Stefan27 | am i supposed to get a warning when compiling invert.c [CC] invert.c -> invert.o invert.c:167:24: varning: vektorindex är ovanför vektorgränsen [-Warray-bounds] ? |
| 14:19.55 | Stefan27 | irc2pc.c:145:12: varning: âtemp[8]â kan användas oinitierad i denna funktion [-Wmaybe-uninitialized] too? |
| 14:20.34 | Stefan27 | (the swedish info is basically the same as the info within the [ ]) |
| 14:23.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:23.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:24.02 | oej | Hello folks |
| 14:24.23 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:47.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-evcrtwnvapehwnrs) |
| 14:47.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:47.46 | mjordan | file: funny story. Stasis used to use a threadpool for subscriptions, but with a low number of subscriptions, that turned out to be less performant than just using a single thread per subscription |
| 14:48.01 | mjordan | file: alas, guess what bumps up the subscription count based on the number of endpoints/peers/what-have-you? |
| 14:50.04 | file | mjordan, oh. |
| 14:50.25 | file | mjordan, SQUIRRELS?!? |
| 14:50.43 | mjordan | yes, they would |
| 14:50.59 | mjordan | it was MWI, in the conservatory, with the lampstick |
| 14:51.20 | file | devicestate would do the same thing |
| 14:51.30 | mjordan | do we subscribe for each endpoint? |
| 14:51.35 | file | no, but if they do... |
| 14:51.44 | mjordan | looks |
| 14:52.11 | file | maybe. |
| 14:52.34 | file | I lied |
| 14:52.36 | mjordan | nope. |
| 14:52.44 | mjordan | that's handled by the core's single callback |
| 14:52.57 | mjordan | I don't think we want to change all subscriptions to be thread pool based |
| 14:53.04 | mjordan | I mean, we could. It'd be the easiest change. |
| 14:53.13 | mjordan | I can't recall how much of a hit that implied |
| 14:53.23 | file | well, it was substantial enough that we didn't ignore it |
| 14:53.32 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 14:53.37 | mjordan | the other idea would be to make the subscription provide a threadpool to use, or potentially have the topic specify that it wants a threadpool for subscriptions to it |
| 14:53.49 | mjordan | file: yeah |
| 14:54.33 | mjordan | likes the idea of the topic determining it |
| 14:56.11 | file | I could see both being good |
| 14:56.22 | file | well, maybe not the first as much |
| 14:56.28 | mjordan | yeah |
| 14:56.29 | file | (now that I think more) |
| 14:56.34 | mjordan | particularly since we have topic pools... |
| 14:59.43 | mjordan | should probably fix the tests he broke last night before breaking anything else today |
| 15:04.20 | file | tests mjordan |
| 15:10.21 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:10.21 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:13.55 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-floowiudteakbent) |
| 15:18.08 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-iqmzomieryyxwdlv) |
| 15:18.08 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:19.01 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 15:19.30 | mjordan | heh |
| 15:19.37 | mjordan | the confbridge nominal test that fails is due to tribles |
| 15:19.45 | mjordan | shakes his fist at user combinations that make no sense |
| 15:20.39 | file | mjordan, curl up in the corner and rock back and forth |
| 15:23.33 | mjordan | it is pretty funny |
| 15:27.49 | *** join/#asterisk-dev hellcorner (~Hellcorne@95.141.29.54) |
| 15:28.14 | file | mjordan, oh good lord |
| 15:29.38 | mjordan | what, my commit? |
| 15:29.51 | file | maybe. |
| 15:30.00 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:30.35 | mjordan | probably. |
| 15:30.52 | oej | Randomly |
| 15:31.03 | oej | mjordan: Thank you |
| 15:32.40 | mjordan | oej: for fixing the confbridge thing? :-) |
| 15:32.52 | oej | For committing my code. |
| 15:32.59 | mjordan | ah! |
| 15:32.59 | mjordan | np |
| 15:33.03 | mjordan | the other patches are on my list |
| 15:33.12 | oej | And of course for fixing confbridge. Always a good thing to do. |
| 15:33.19 | mjordan | but I think people's feedback on the reviews was right, and it's probably best to include those changes |
| 15:33.35 | oej | On what reviews? |
| 15:33.40 | mjordan | looks |
| 15:34.36 | mjordan | https://reviewboard.asterisk.org/r/1421/ - I'd like to merge the CLI commands together, so that we don't have two different debug commands (or at least have a single command with a 'action|event' filter) |
| 15:35.17 | mjordan | https://reviewboard.asterisk.org/r/1471/ - this one is close, but I need to look at wdoekes comment |
| 15:35.50 | oej | Having two different commands would be stupid. I made the patch in a version of asterisk that had nothing. |
| 15:35.53 | mjordan | https://reviewboard.asterisk.org/r/3439/ - I want to parse the full IP address here. I've personally never seen an SDP with an rtcp attribute that includes more than just the port, but it is theoretically possible, and IIRC, you mentioned that you had seen it |
| 15:35.57 | mjordan | oej: agreed |
| 15:36.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:36.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:36.37 | mjordan | https://reviewboard.asterisk.org/r/2872/ is missing the diff, but I've look at the lingon branch. Just want to write some tests for this. |
| 15:37.04 | oej | For #1471 someone made a lot of changes and I never followed up. SHould be on the bug tracker. Had a bad attitude, so I did not spend any time with him/her/it. |
| 15:37.26 | oej | The function is important unfortunately. IPv6 would make it un-needed. |
| 15:37.50 | mjordan | oej: some day... some day... :-) |
| 15:37.54 | oej | 2872 has been a little bit of moving target |
| 15:38.13 | oej | The problem was the MKI in negotiation. |
| 15:38.18 | mjordan | hm. |
| 15:38.28 | mjordan | what problems did you run into? |
| 15:38.41 | oej | I haven't really got any answers on what's correct. If an offer has no MKI parameter, but an answer has. |
| 15:40.46 | oej | Turned out that the Lync test tool behaved this way. The real lync did not. |
| 15:41.00 | oej | So I convinced them it was a bug in the test toolâ¦. |
| 15:41.11 | mjordan | yeah, that sounds good to me. |
| 15:41.16 | oej | My opinion is that the lingon code is correct now and that is the code we got certification for. |
| 15:41.35 | oej | If we get key 1 with MKI index and key2 without, we select key 2 and everything works. |
| 15:41.44 | oej | If we only get offer with MKI we refuse. |
| 15:42.41 | mjordan | sounds good. As I said, for that, I really just need to sit down and write some SIPp scenarios that exercise it. |
| 15:42.48 | mjordan | It's pretty needed for interoperability |
| 15:43.07 | oej | I added a few examples you can use in the source code. |
| 15:43.31 | oej | If not enough, poke me and I'll dig. |
| 15:44.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 15:53.14 | mjordan | oej: will do |
| 15:58.28 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-vbidfqhqqjakliju) |
| 16:08.17 | oej | mjordan: Been trying to fix DNS lookups for REGISTER= statements in sip.conf |
| 16:08.32 | oej | Found out we propably do a DNS lookup more than three times for one REGISTER... |
| 16:08.46 | coreyfarrell | ouch |
| 16:09.00 | oej | And every time we re-register... |
| 16:09.13 | oej | have a branch where I try to clean that up. Need to get control. |
| 16:09.22 | coreyfarrell | can I assume that using an IP address in register= should prevent any DNS lookup? |
| 16:09.41 | oej | At this point we can not assume anything. It's a mess. |
| 16:09.51 | oej | Using IP is not the goal and will just cause other issues. |
| 16:10.45 | coreyfarrell | such as? beyond the obvious of if the upstream SIP gets a new IP |
| 16:11.30 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wizacuurqovjfznz) |
| 16:11.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:11.52 | oej | Dns provides failover, load balancing and more. |
| 16:12.03 | oej | And you need a name to register to, a domain you are part of. |
| 16:12.43 | oej | DNS is an important part of SIP. If you remove it you will have so many other issues to fix. TLS will no longer work. |
| 16:14.43 | coreyfarrell | good points.. thanks |
| 16:15.46 | oej | (You can still fake and set an outbound proxy to an IP⦠But I did not say that) |
| 16:15.53 | oej | Just for testing... |
| 16:16.16 | oej | If you want to test something and use a SIP domain that doesn't exist in DNS, that's what you do. |
| 16:33.44 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vrlvfyxalmsluccj) |
| 16:37.18 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yrqtvtnvwyqgxxey) |
| 16:37.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:50.18 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-neqjtklmetaptnra) |
| 16:52.07 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 17:11.30 | file | gtjoseph, re ASTERISK-24532 nothing else polls |
| 17:11.48 | gtjoseph | looks |
| 17:12.34 | file | that is something that would be nice - but discussing it in the grand scheme of things would be best... as it applies to everything with state |
| 17:13.08 | gtjoseph | ah, yeah but that's because when you add a new pjsip object to realtime you don't have to reload anything. |
| 17:13.17 | gtjoseph | except... |
| 17:13.25 | file | you do if it has state associated with it |
| 17:13.41 | gtjoseph | ah, like contact and registration? |
| 17:13.52 | file | or if it's not externally triggered |
| 17:13.53 | gtjoseph | yes but phoneprov doesn't have state |
| 17:13.55 | file | outbound registration, yes |
| 17:14.11 | file | oh? |
| 17:14.16 | gtjoseph | nope |
| 17:14.24 | file | why doesn't it just work then? |
| 17:14.55 | gtjoseph | because res_phoneprov only builds its internal table of uris at load |
| 17:15.05 | file | that's state ^_^ |
| 17:15.23 | gtjoseph | it doesn't klnow that res_pjsip_phoneprov_provider seesnew phones. |
| 17:15.39 | gtjoseph | not really, it's not maintaing any volatile state, it's just a list |
| 17:15.50 | gtjoseph | of uris to serve |
| 17:16.26 | file | that's still some state - state of URIs dynamically added |
| 17:16.53 | gtjoseph | well, maybe... |
| 17:17.43 | file | despite the name - it's information that has to stay around in memory |
| 17:18.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 17:18.17 | gtjoseph | it's only that way because res_phoneprov/sip.conf/users.conf isn't sorcery based so to save processing time, the config files are read once. it's more of a cache than state. |
| 17:19.30 | gtjoseph | if res_phoneprov were sorcery based, then each time a http GET came in, we'd read it from sorcery. |
| 17:21.15 | file | sorcery all the things! |
| 17:21.41 | gtjoseph | all i'd do for this issue is change res_phoneprov to go to the provider for each request rather than it's internal cache. |
| 17:22.24 | gtjoseph | the current cache would become part of the sip.conf/users.conf provider. |
| 17:22.41 | file | that's fine then |
| 17:23.30 | gtjoseph | back to contacts and outbound registrations... How are you going to fix THAT?? :) |
| 17:23.46 | file | contacts don't matter, outbound registrations do |
| 17:24.09 | gtjoseph | who don't contacts matter for wualify? |
| 17:24.09 | file | or they matter less. |
| 17:24.13 | gtjoseph | qualify |
| 17:24.36 | file | because the number of people who do that aren't as large as the number of people who just want their outbound registrations to go? ^_6 |
| 17:25.14 | file | who knows what'll happen or where that'll go... |
| 17:27.50 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 17:44.24 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 18:01.10 | X-Rob | Dammit, mjordan's gone. It's the chan_sip peers that's doing it. When I disable them, I go back to a reasonable number of threads. |
| 18:02.47 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:03.46 | X-Rob | However, disabling the mailbox line in the sip.conf drops me to 569 threads. So thats' one of them |
| 18:05.04 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 18:47.56 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 18:56.29 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:30.31 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 19:40.44 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 19:41.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qpvoswgelwsiwxuz) |
| 19:41.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:58.13 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-70-182-53-212.ph.ph.cox.net) |
| 20:00.49 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:20.29 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:47.56 | file | opticron, so what did the assertion end up being? |
| 20:48.28 | opticron | I'm not sure it's my code at this point |
| 20:49.00 | opticron | the reproduction I thought I had didn't turn out to be |
| 20:49.00 | opticron | I've seen it happen twice now |
| 20:49.04 | opticron | out of several hundred runs |
| 20:49.04 | file | I'll rephrase: what was asserting? |
| 20:49.24 | mjordan | so here's an interesting question. Our swagger_model.py in Asterisk - which builds the auto-generated stubs and the wiki docs from Swagger JSON - says it supports 1.1 and 1.2 (which is kind of a lie, as it admits). |
| 20:49.37 | mjordan | Do we want to only support 1.2? It's a major breaking change. |
| 20:49.37 | opticron | file, I was unable to get that information from it :/ |
| 20:49.48 | mjordan | The only benefit I can see for putting in multiple version support is for when we move to 2.0 |
| 20:49.59 | mjordan | we wouldn't have to bite the whole thing off in one fell swoop if we did that |
| 20:52.29 | opticron | messages is capturing warning, error, notice and asserts should show up under the error level |
| 20:52.48 | opticron | nothing shows up in the logs |
| 20:53.59 | file | I don't think that's true, at least not for PJ asserts |
| 20:54.13 | opticron | I thought they were re-emitted on error or warning? |
| 20:54.46 | file | I don't... remember... |
| 20:54.49 | file | um |
| 20:55.52 | file | 'tis easy for me to test |
| 20:56.10 | X-Rob | ah, mjordan, you're back. disabling the mailbox line in sip.conf drops me to 569 threads, from 1000+ |
| 20:56.17 | mjordan | hrm. |
| 20:56.21 | mjordan | still more than I would expect. |
| 20:56.31 | X-Rob | mjordan: I have 500 extens on this test machine |
| 20:56.34 | mjordan | X-Rob: can you use gdb to snag a backtrace of a running system? |
| 20:56.42 | X-Rob | it's my 'what have I broken with a lot of extensions' machine |
| 20:56.46 | mjordan | I can get you the exact command if you'd like |
| 20:56.50 | file | opticron, nope! |
| 20:56.50 | X-Rob | mjordan: sure can |
| 20:57.00 | X-Rob | with or without mailbox? |
| 20:57.07 | mjordan | both, if possible |
| 20:57.24 | mjordan | gdb -ex "thread apply all bt" --batch /usr/sbin/asterisk `pidof asterisk` > backtrace.txt |
| 20:57.33 | file | <3 pidof |
| 20:57.37 | mjordan | I want to make sure I'm right about where all of the threads are coming from |
| 20:57.59 | mjordan | but I have a sneaky suspicion I know what it is. Which is a bit of a bummer, but it's definitely a problem (tm) |
| 20:58.10 | mjordan | or rather, even, Problem. |
| 20:58.14 | X-Rob | ooo. |
| 20:58.14 | mjordan | Capital 'P'. |
| 20:58.35 | X-Rob | mjordan: want me to open a ticket and dump all this there? |
| 20:58.37 | mjordan | plz |
| 20:58.44 | file | opticron, what was I doing? |
| 20:58.49 | file | oh |
| 20:58.50 | mjordan | we'll need to fix this soon before a bunch of people run into it |
| 20:59.18 | opticron | so I need to be running asterisk with -c and watching the console when it crashes to see the assert? |
| 20:59.32 | opticron | (this is what I've been doing trying to replicate the assert) |
| 20:59.42 | file | opticron, oui |
| 20:59.52 | opticron | it doesn't crash while I'm watching it |
| 21:00.07 | file | a watched pot never... IT'S ON FIRE |
| 21:00.13 | opticron | correct |
| 21:00.40 | mjordan | bbiab, need something warm |
| 21:00.43 | opticron | apparently you can configure pjproject to throw the assert into printk |
| 21:02.47 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:04.04 | X-Rob | ah poo, they're all 'in ??' - I mustn't have debugging libs |
| 21:04.10 | X-Rob | I thought they were there.. |
| 21:04.59 | X-Rob | ooh there they are. |
| 21:05.46 | X-Rob | Much better. |
| 21:12.30 | X-Rob | mjordan: https://issues.asterisk.org/jira/browse/ASTERISK-24533 |
| 21:16.18 | X-Rob | mjordan: btw, this is a test system, so if you want me to do stuff, I'm happy to do whatever. |
| 21:16.29 | X-Rob | Except post naked photos of me on facebook. That won't go down well. |
| 21:21.25 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 21:39.17 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 21:48.42 | malcolmd | that escalated from a bug report to something else very quickly. ;) |
| 21:57.05 | X-Rob | malcolmd: mjordan's seen what I put on facebook. |
| 21:57.34 | X-Rob | last time he was saying something about PTSD and 'the googles, they do nothing' |
| 22:02.29 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:04.00 | mjordan | X-Rob: My eyes! The goggles! |
| 22:04.15 | X-Rob | heh |
| 22:04.22 | mjordan | X-Rob: and thanks. You aren't running PJSIP with this as well, are you? |
| 22:04.38 | X-Rob | mjordan: Ummm. I don't think there are any pjsip entries on that machine |
| 22:05.03 | X-Rob | mjordan: just a transport entry for it |
| 22:09.31 | mjordan | X-Rob: I'll work on a patch tonight probably. We used to use a thread pool for certain things and removed it because globally, it was a bad idea. |
| 22:09.48 | mjordan | X-Rob: Unfortunately, in some cases, having an independent thread for every single subscription in Stasis is ... bad. |
| 22:09.52 | mjordan | even, dare I say, worse. |
| 22:10.13 | mjordan | I found the old code with the threadpool and it's pretty easy to insert for just the subscriptions that chan_sip is using for this case |
| 22:10.21 | mjordan | (as well as pjsip and the others who would run into it) |
| 22:10.21 | file | no perfect solution for every case |
| 22:10.22 | X-Rob | ah ok |
| 22:17.02 | coreyfarrell | what was the problem with threadpool globally? |
| 22:18.13 | mjordan | performance |
| 22:18.57 | mjordan | there's overhead with dispatching work items to a thread pool. If what you have is just a few subscribers, it is more efficient to have just a few threads handling their subscriptions |
| 22:19.16 | coreyfarrell | ok makes sense |
| 22:19.18 | mjordan | if, on the other hand, you have 1000 threads due to subscribing to things on a peer by peer basis, well... threadpool. |
| 22:20.05 | mjordan | one of the nice things is that a threadpool is front-ended by a taskprocessor |
| 22:20.21 | mjordan | and stasis already uses a taskprocessor to dispatch items to a single subscriber thread |
| 22:20.25 | mjordan | so internally, this is a very easy change |
| 22:20.41 | mjordan | I'll probably make it so that the topic determines the threading scheme |
| 22:20.43 | coreyfarrell | any idea the percent penalty for threadpool? |
| 22:21.20 | mjordan | unfortunately, I don't. It was a long time ago when we first started improving performance in Stasis. If we made the change, it was probably a good chunk - which is why I don't want to move all of the subscriptions over to a threadpool |
| 22:21.25 | mjordan | https://reviewboard.asterisk.org/r/2881 |
| 22:21.25 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:22.03 | mjordan | leedm777 may remember |
| 22:22.14 | mjordan | but alas, is not on :-P |
| 22:23.25 | coreyfarrell | sorry if I'm misunderstanding, but it seems like above a certain global number of subscription, it would be better for all to run on a threadpool? or would that give each subscription type a threadpool? |
| 22:24.51 | coreyfarrell | or maybe the CDR/CEL subscriptions (high volume) need their own threads, everything else should be pooled? just thinking out loud.. |
| 22:28.42 | mjordan | coreyfarrell: maybe, but some subscriptions are transient, and I think it might be hard to predict that. |
| 22:28.58 | mjordan | hm. |
| 22:29.39 | mjordan | It could be tied to the stasis_subscription topic, but then you'd need to pass in how you wanted to subscribe to the topic. Maybe. |
| 22:29.49 | mjordan | I'll take a look at that. It would require a new API call. |
| 22:31.11 | snuff-work | mm.. my pjsip still refuses to say the right IP outbound on my other sip trunk |
| 22:31.37 | snuff-work | any ideas.. (2 IPs both non-nat) |
| 22:31.51 | snuff-work | old chan_sip 'does the right thing' |
| 22:31.58 | coreyfarrell | yeah just a thought, when the profiling was done I assume that stasis was identified as a whole, but really stasis handles many types of traffic.. I think certain subscription types would always have higher volume of msgs. others may sometimes spike, but would normally be moderate to low volume |
| 22:32.00 | mjordan | snuff-work: apples and oranges |
| 22:32.15 | mjordan | snuff-work: without looking at you endpoint, dial string, and some debug, no idea |
| 22:32.47 | mjordan | coreyfarrell: I'll explore tagging it based on subscription instead of topic. It shouldn't be a large change either way. |
| 22:33.09 | mjordan | subscription actually does make more sense, as the subscriber typically knows the pattern of traffic better than the topic |
| 22:33.29 | snuff-work | mm.. what sort of debug would u want.. i have 'chan_sip logger / pjsip_logger output' (where you see the wrong addresses in parts of sip msgs |
| 22:34.54 | coreyfarrell | having the subscriber decide could allow 'creativeness' in the future.. if (peercount > 100) { use_threadpool(); } |
| 22:38.58 | mjordan | snuff-work: For PJSIP, I'd want to see the endpoint configuration; the dial string, as a DEBUG log output including 'pjsip set logger on' showing the outbound INVITE request |
| 22:39.08 | mjordan | coreyfarrell: true |
| 22:39.15 | mjordan | s/as/and a |
| 22:44.24 | snuff-work | an example.. |
| 22:44.25 | snuff-work | http://pastebin.com/ugwZDWPM |
| 22:45.06 | snuff-work | 10.21.16.253 = incorrect internal IP that 3202 contacts it on.. |
| 22:45.19 | snuff-work | 10.237.176.126 = IP it should be making outbound via |
| 22:45.55 | snuff-work | if anythin quick comes to mind.. otherwise.. i'll just roll back to chan-sip for time being |
| 22:46.40 | snuff-work | because of this IP issue.. i have problems with inband dtmf.. some reason voice still works but dtmf is broken |
| 22:46.55 | snuff-work | swap out with chan_sip.. no inband dtmf issue |
| 22:50.00 | *** join/#asterisk-dev hellcorner (~Hellcorne@95.141.27.41) |
| 23:00.45 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:04.00 | mjordan | snuff-work: localnet |
| 23:06.08 | mjordan | er, I'm confused. |
| 23:06.48 | mjordan | Your outbound INVITE request looks fine. Your SDP origin line is the only thing that references the 16.253 address, but that's generally just for information |
| 23:08.35 | snuff-work | mm but why From: <sip:0383708000@10.21.16.253> ? |
| 23:08.42 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:08.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:09.27 | snuff-work | i did have 'localnet' under my transport |
| 23:09.37 | snuff-work | for the 10.21.16.0/24 |
| 23:09.46 | snuff-work | but then i think it all broke on me.. |
| 23:14.54 | mjordan | snuff-work: the From header is going to be the initiator of the request; in this case, I'd assume that's the identity of the inbound channel in some fashion. |
| 23:14.57 | snuff-work | i set localnet to the above.. nothing changed for the outbound call.. (in terms of what was listed in inv) |
| 23:15.15 | mjordan | snuff-work: it won't. localnet only affects signaling, and your signaling is fine. |
| 23:15.46 | mjordan | Your via is fine, as is your Contact. What is your provider doing with the From header? |
| 23:16.02 | snuff-work | the RTP goes to diff host |
| 23:19.09 | mjordan | k, they aren't using the From header for that |
| 23:19.16 | mjordan | they're using the Origin IP address, which is funky and strange. |
| 23:19.21 | mjordan | They should be using the connection information |
| 23:19.39 | mjordan | snuff-work: are you using the latest 13? |
| 23:21.16 | mjordan | X-Rob: I have a patch... but it is not super tested. |
| 23:21.46 | snuff-work | yes.. trunk infact as of 3 days ago |
| 23:21.52 | mjordan | k |
| 23:22.10 | mjordan | snuff-work: go ahead and file a bug. A pcap would probably help, if they are sending RTP to the wrong address |
| 23:22.27 | mjordan | snuff-work: Really, your provider is doing the wrong thing, but the origin address in the SDP doesn't look right either. |
| 23:22.51 | snuff-work | well like i said.. the 'odd' part is.. i can do normal calls just fine.. just no dtmf.. |
| 23:23.13 | snuff-work | swap out for chan_sip.. inband dtmf no issue |
| 23:23.33 | snuff-work | k i will try and get this filed away today |
| 23:23.50 | file | unless it's an inband dtmf problem and unrelated to that |
| 23:24.49 | snuff-work | could be.. anyone done much pjsip testing with inband dtmf ? |
| 23:25.31 | snuff-work | my trunk to another * is via rfc.. i 'think' i tested inband for that link.. but can't recall |
| 23:25.51 | mjordan | I've tested inband and it worked with PJSIP |
| 23:26.24 | mjordan | granted, within inband, it's rather dependent on who you're talking to |
| 23:26.45 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qpvoswgelwsiwxuz) |
| 23:54.51 | snuff-work | mm.. interesting.. |
| 23:55.02 | snuff-work | > core show channeltype SIP |
| 23:55.09 | snuff-work | types out most info then says |
| 23:55.14 | snuff-work | failed to extend from 64 to 98 |
| 23:55.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |