| 00:20.54 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:20.54 | *** 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 |
| 03:59.44 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.168) |
| 06:46.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:ca7:e796:a90f:7664) |
| 06:52.07 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/dadrc) |
| 07:28.32 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:10.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:50.22 | file | would anyone have any qualms if I remove STATIC_BUILD? it hasn't been supported in ages and doesn't work |
| 11:29.08 | gtjoseph | No qualms here. |
| 12:21.28 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/dadrc) |
| 12:31.36 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 12:31.37 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 12:45.22 | coreyfarrell | file: go for it |
| 12:45.36 | file | I rolled it into my change, yolo |
| 12:46.08 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/dadrc) |
| 12:46.27 | coreyfarrell | also FYI the asterisk-code-review mailing list is dead again |
| 12:47.14 | tsearle | real men don't need code review |
| 12:48.00 | file | that's a Matt thing, attack him when he appears |
| 13:00.43 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-69-145.dialup.adsl.anteldata.net.uy) |
| 13:42.02 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:42.02 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:42.06 | tsearle | is jenkins happy? |
| 13:42.36 | tsearle | got a build fail on my gerrit, but I don't see my change in the list of changes jenkins was building |
| 13:42.47 | tsearle | https://gerrit.asterisk.org/#/c/asterisk/+/9477/ |
| 13:42.51 | file | gtjoseph is doing stuff |
| 13:43.40 | tsearle | oki |
| 13:47.51 | gtjoseph | yeah i'm working on it |
| 14:06.58 | coreyfarrell | cresl1n: FYI codereview mailing list is down |
| 14:07.12 | gtjoseph | working on it |
| 14:08.12 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 14:08.13 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:19.22 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-zmorkrpbxxspqkrq) |
| 14:19.22 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:21.59 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tnelmrgtgxvnnflu) |
| 14:21.59 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:40.18 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cohondryvnegiiqs) |
| 14:40.18 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:41.56 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ecylkwtgeqrzcngl) |
| 14:41.56 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:31.14 | cresl1n | thanks coreyfarrell |
| 15:31.17 | cresl1n | we're looking into it |
| 15:51.49 | seanbright | tm1000: you have an asterisk config for https://github.com/onsip/SIP.js/issues/543 that i can look at? |
| 15:52.08 | seanbright | i hope and pray that you are testing against chan_pjsip |
| 15:52.56 | tm1000 | seanbright: nobody got time for chan_sip shit! |
| 15:53.12 | seanbright | bless your heart |
| 15:53.12 | tm1000 | But yeah I have a config. I'll find it. Is it working for you? |
| 15:53.17 | seanbright | haven't tried it yet |
| 15:53.19 | seanbright | need a config |
| 15:53.21 | seanbright | :P |
| 15:53.36 | tm1000 | We changed most of this to pjsip a year agk |
| 15:53.52 | tm1000 | On that note do you know if early media is possible in webrtc seems like yes and no |
| 15:54.21 | seanbright | that is above my pay grade |
| 15:54.47 | file | it's possible in the sense that you can do the SDP negotiation |
| 15:54.50 | seanbright | there are more reliable webrtc resources reading our exchange and hoping they are not called upon |
| 15:54.59 | seanbright | oh! nevermind, there's one |
| 15:55.36 | file | from the browser that's really all it talks in the end, SDP, and the negotiation that occurs |
| 15:57.57 | tm1000 | but right now. in the current moment Asterisk does not support that |
| 15:58.08 | tm1000 | (not complaining fyi) |
| 16:01.45 | kharwell | so I've done some testing with Asterisk 13 and registrations (4000 endpoints). Findings are somewhat interesting for those interested: https://pastebin.com/6VbSfm56 |
| 16:02.07 | kharwell | chan_pjsip has for sure benefited by recent improvements |
| 16:02.11 | tm1000 | https://www.irccloud.com/pastebin/5tg9YnUu/ |
| 16:02.25 | tm1000 | seanbright: ^ (yes password changed and ip is in a private range) |
| 16:02.52 | tm1000 | seanbright: also havent yet switch to your sdes |
| 16:03.30 | kharwell | gtjoseph: ^^^ test results |
| 16:03.51 | gtjoseph | kk |
| 16:15.23 | coreyfarrell | kharwell: any ideas why the results for pjsip had such a large range of CPU usage compared to chan_sip being consistent? |
| 16:17.11 | kharwell | not yet. my suspicions is it might be the options going out as they were turned on for these tests. I'm going to test some with them off and see |
| 16:18.22 | file | may also be that the execution flow for chan_sip is also simpler and more predictable |
| 16:18.41 | file | no dispatch model, single threaded |
| 16:20.46 | kharwell | also chan_sip jumped around a bit too it was just less. Maybe +/- a couple percent |
| 16:21.26 | file | kharwell: did you use a fixed number of PJSIP threads? |
| 16:22.12 | kharwell | no? where is that configured? config_site.h? |
| 16:22.27 | file | nah, it's configurable in pjsip.conf in the system section I think |
| 16:23.02 | file | threadpool settings |
| 16:23.29 | kharwell | ah no I used the default so would have kept growing |
| 16:24.13 | file | it'd be interesting to probably do the number of processing cores, and maybe * 2, fixed number |
| 16:24.18 | file | that may level out the fluctuation |
| 16:24.39 | file | and level things out in general |
| 16:30.05 | AsteriskRoss | What about setting async_operations on transports also? |
| 16:31.54 | file | I would not expect that to have a noticeable impact on his testing |
| 16:34.35 | AsteriskRoss | The one thing that does improve things for me is putting astdb in to memory instead of on disk |
| 16:38.05 | kharwell | so here is "options turned off": https://pastebin.com/iT5heFC5 |
| 16:38.34 | kharwell | it helped a little. The cpu didn't appear to jump around as much. At least to my eye (very scientific). |
| 16:39.07 | kharwell | The interesting thing to note is chan_sip seems to be slightly better at just pure registrations |
| 16:41.31 | file | I'm not overly surprised |
| 16:45.28 | seanbright | tm1000: all of the cool kids are using ephemeral dtls in asterisk, just sayin |
| 16:45.44 | tm1000 | seanbright: yeah but thats only in what? |
| 16:45.47 | tm1000 | 13?14?15? |
| 16:45.50 | tm1000 | I cant remember |
| 16:46.06 | seanbright | i thought i put it in all release branches |
| 16:46.39 | seanbright | no, just 15+ |
| 16:47.19 | tm1000 | yeah thats the problem |
| 16:47.29 | tm1000 | 15 isn't LTS too |
| 16:47.38 | tm1000 | otherwise I'd be forcing SFU |
| 16:47.39 | tm1000 | ;-0 |
| 16:48.42 | seanbright | tm1000: so you're testing against latest 13? git or release? |
| 16:48.53 | tm1000 | I'm actually testing this against 15 |
| 16:49.01 | seanbright | tm1000: so you're testing against latest 15? git or release? |
| 16:49.04 | tm1000 | but the product we are delivering needs it to work in 13 |
| 16:49.08 | tm1000 | 15.4.0 |
| 16:49.27 | seanbright | tm1000: so you're delivering against latest 13? git or release? |
| 16:49.30 | kharwell | file: still jumps around with threadpool_max_size set. I set mine to 32 |
| 16:49.34 | tm1000 | https://www.irccloud.com/pastebin/E780lDkF/ |
| 16:49.40 | *** join/#asterisk-dev joshelson (~joshelson@144.178.7.132) |
| 16:49.41 | tm1000 | seanbright: latest 13 |
| 16:49.49 | seanbright | heh... |
| 16:49.51 | seanbright | git or release? |
| 16:49.55 | tm1000 | release |
| 16:50.11 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-iicefsovnlzqqyet) |
| 16:50.13 | tm1000 | from tarballs provided by digium (then build through mock to make it an rpm) |
| 16:50.20 | seanbright | 13.22.0 is the latest release |
| 16:50.24 | seanbright | so i will test with that |
| 16:50.31 | seanbright | should have it fixed in a couple minutes |
| 16:50.33 | file | Good data point kharwell |
| 16:50.33 | tm1000 | yup thats fine |
| 16:50.37 | seanbright | (kidding) |
| 16:50.41 | tm1000 | seanbright: wait? it's an asterisk issue? |
| 16:50.47 | seanbright | i have 0 idea |
| 16:50.52 | tm1000 | I was strongly in the camp of its not. |
| 16:50.58 | tm1000 | but I'd be curious to know |
| 16:51.01 | seanbright | i didn't even know what version of asterisk to test against until 15 seconds ago |
| 16:51.05 | tm1000 | heh |
| 16:51.13 | seanbright | you suck at bug reporting |
| 16:51.15 | seanbright | <3 |
| 16:51.19 | tm1000 | I didn't see a difference between 13.22 or 15.4 |
| 16:51.30 | seanbright | also, onsip sucks in general |
| 16:51.39 | tm1000 | yeah well... when you tell sipjs "im using asterisk" they instantly blame asterisk |
| 16:51.42 | seanbright | their attitude about supporting anything that isn't their platform is garbage |
| 16:51.46 | seanbright | right |
| 16:51.46 | tm1000 | ^ see |
| 16:51.53 | tm1000 | but its the same for jssip |
| 16:52.06 | tm1000 | the whole "lets point the finger at asterisk"game |
| 16:52.08 | seanbright | they also have this half-assed pjsip configuration section that doesn't even use chan_pjsip |
| 16:52.21 | seanbright | but i digress |
| 16:52.30 | file | kharwell: try dropping down to 4 |
| 16:52.35 | tm1000 | and I won't ever use SIPML5 so hard |
| 16:52.41 | file | kharwell: including initial |
| 16:53.27 | tm1000 | theres two things I have issues with hold and early media. hold I worked around. early media would require Asterisk changes |
| 16:53.58 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 16:53.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:54.39 | seanbright | but asterisk supports early media |
| 16:54.54 | seanbright | and webrtc doesn't do signalling |
| 16:55.01 | seanbright | so i don't know why it wouldn't work |
| 16:55.04 | seanbright | "out of the box" |
| 16:56.10 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 16:56.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:56.11 | tm1000 | seanbright: there's a PR on sipjs that enables early media, so it might just be a sipjs limitation |
| 16:56.19 | seanbright | got it |
| 16:56.21 | kharwell | file: with 4 I am seeing similar. Numbers between 52 and 70% |
| 16:56.28 | file | kharwell: good to know |
| 16:56.50 | tm1000 | seanbright: the devs gave some long winded excuse to why they dont want to support early media. |
| 16:57.21 | seanbright | i blame sorcery for the CPU problems |
| 16:57.28 | seanbright | but i also have no idea what i am talking about |
| 16:57.32 | tm1000 | https://github.com/onsip/SIP.js/pull/502 |
| 16:57.33 | seanbright | "problems" |
| 16:57.48 | tm1000 | The real issue is that this is a limitation of the WebRTC Peer Connection. We are applying the early media as a final response. This is because WebRTC does not support pre-answers. So in the case of a forked call... |
| 16:57.48 | tm1000 | Alice calls (with SDP) Bob. Bob has 2 endpoints Bob1 and Bob2. Both endpoints send early media. So now it is a race for whoever can get early media to Alice faster. Lets say that Bob1 gets early media to Alice first, the SDP from Bob1 is applied as the final answer to Alice's offer. Then Bob2 actually answers the call. There is no way for us to override the SDP that was already applied from Bob1. The call is dead. |
| 16:57.48 | tm1000 | Invite without SDP fixes this by reversing the SDP offer answer. So in the above example Bob1 and Bob2 are sending SDP offer's in the 183. This allows us within SIP.js to build a Peer Connection for each fork of the call, and generate distinct answers for each fork. When we get the final 200 Ok from any fork, we can simply discard the other peer connections. |
| 16:57.56 | tm1000 | ^ so says sipjs.... |
| 16:58.27 | file | that's the age old problem of forked calling with early media from multiple sources |
| 16:59.10 | file | Asterisk would never do such a thing. |
| 16:59.48 | tm1000 | and there you go |
| 16:59.57 | tm1000 | but they dont want to do it because "random other endpoint could/can" |
| 17:00.04 | tm1000 | which then leads me into forking the library |
| 17:00.11 | tm1000 | which... I guess maybe... |
| 17:00.34 | tm1000 | sorry not endpoint I mean random other non-asterisk implementation of which there can be thousands. |
| 17:05.13 | seanbright | tm1000: please send SangomaTech.crt and SangomaTech.key, thanks |
| 17:05.17 | seanbright | heh |
| 17:05.39 | tm1000 | seanbright: its a wildcard crt. are you going to fake your DNS? |
| 17:05.56 | seanbright | i was joking |
| 17:05.59 | tm1000 | lol |
| 17:06.03 | seanbright | i will generate some |
| 17:06.45 | seanbright | are you using Simple or UA? |
| 17:06.49 | seanbright | in sip.js |
| 17:10.08 | tm1000 | UA |
| 17:10.14 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 17:10.14 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:18.23 | seanbright | can you share that code as well? |
| 17:19.50 | tm1000 | seanbright: code? which code? |
| 17:19.56 | tm1000 | the UA? |
| 17:19.58 | seanbright | your JS |
| 17:19.59 | seanbright | yes |
| 17:20.08 | tm1000 | I can but it wouldnt help you |
| 17:20.10 | tm1000 | well |
| 17:20.16 | tm1000 | nevermind I can |
| 17:20.20 | seanbright | k |
| 17:20.24 | tm1000 | I forgot I'm testing this with a fork |
| 17:20.49 | tm1000 | seanbright: how can I send it to you? |
| 17:20.59 | seanbright | sean.bright@gmail.com |
| 17:21.05 | seanbright | creative, i know |
| 17:21.37 | seanbright | i mean... the signalling looks correct to me |
| 17:21.41 | seanbright | but what do i know |
| 17:21.51 | tm1000 | seanbright: I hope google allows this |
| 17:21.53 | seanbright | using Simple right now |
| 17:21.54 | tm1000 | as I sent a zip |
| 17:22.08 | seanbright | if not, just change the extension to .png |
| 17:22.09 | tm1000 | also this uses my hack that modifies the sdp just fyi so that hold would work |
| 17:22.10 | seanbright | but hold on |
| 17:22.21 | seanbright | i got it |
| 17:22.38 | seanbright | so, uh... |
| 17:22.44 | seanbright | this photo you sent with it is nice and all |
| 17:22.48 | seanbright | but unnecessary |
| 17:23.06 | tm1000 | lol you.... |
| 17:23.32 | seanbright | ugh... .DS_Store files |
| 17:23.37 | tm1000 | sorry mac |
| 17:23.39 | seanbright | you lost so much credibility |
| 17:23.55 | tm1000 | ¯\_(ã)_/¯ |
| 17:24.11 | tm1000 | I had a mac at the devcon you clearly saw it |
| 17:24.16 | tm1000 | along with the 90% others |
| 17:24.17 | tm1000 | :-p |
| 17:24.23 | seanbright | yes, i saw it |
| 17:24.25 | tm1000 | seanbright: speaking of which you coming this year? |
| 17:24.31 | seanbright | undecided |
| 17:24.36 | seanbright | my wife's birthday is 10/11 |
| 17:24.41 | tm1000 | excuses |
| 17:24.52 | seanbright | so ua-0.11.2.js sits on top of sip.js, correct? |
| 17:24.58 | seanbright | meaning i can use that with vanilla sip.js |
| 17:25.05 | seanbright | and it won't work, but it won't be invalid |
| 17:25.15 | seanbright | is that fair? |
| 17:25.19 | tm1000 | ua-0.11.2.js is just my code. |
| 17:25.24 | seanbright | right |
| 17:25.24 | seanbright | ok |
| 17:25.36 | tm1000 | you can launch index.html and it'll function |
| 17:25.41 | tm1000 | it has input boxes. |
| 17:25.49 | tm1000 | I stole this from sip.js and its in an electron container. |
| 17:26.04 | tm1000 | it allows me to test their releases without freepbx being in the way |
| 17:26.10 | tm1000 | so I can do just asterisk <==> sipjs |
| 17:26.14 | seanbright | lots'o'hackiness in here |
| 17:26.47 | seanbright | before i start digging in to this, i am going to bet $10 it's something wrong in your codfe |
| 17:26.48 | tm1000 | partially stolen from them as I said ;-) |
| 17:26.50 | seanbright | code* |
| 17:26.58 | *** join/#asterisk-dev jkroon (~jkroon@105.4.4.45) |
| 17:26.59 | tm1000 | seanbright: then it'd be their code |
| 17:27.05 | seanbright | your code. |
| 17:27.10 | seanbright | 17:25 < tm1000> ua-0.11.2.js is just my code. |
| 17:27.14 | seanbright | excuses |
| 17:27.20 | tm1000 | "I stole this from sip.js and its in an electron container." |
| 17:27.38 | tm1000 | "hold" is in the native library |
| 17:27.45 | seanbright | this would be funnier for everyone if you just went with it |
| 17:27.48 | tm1000 | not sure how *my* code could mess that up |
| 17:28.04 | tm1000 | heres my hacky part though |
| 17:28.07 | tm1000 | https://www.irccloud.com/pastebin/Hvtia6Ia/ |
| 17:28.15 | tm1000 | seanbright: its no fun if I give in to you |
| 17:43.29 | seanbright | so not using ua-0.11.2 (just using Simple), hold/unhold appears to work with asterisk 13 git |
| 17:44.10 | seanbright | but let me confirm 100% |
| 17:44.35 | tm1000 | I cant use Simple |
| 17:44.47 | seanbright | well Simple is just a layer on top of UA |
| 17:45.07 | seanbright | but please hold your applause until the end |
| 17:45.08 | tm1000 | yeah well I'm unsure how anything I am doing in that simple UA would mess up hold states |
| 17:45.34 | seanbright | well, it does mean that it's probably not a bug in sip.js |
| 17:45.40 | seanbright | which is what i am trying to determine |
| 17:54.21 | seanbright | yes, works with simple |
| 17:54.52 | seanbright | so the ua code is broked |
| 17:55.25 | seanbright | tm1000: i would look here https://github.com/onsip/SIP.js/blob/master/src/Web/Simple.js |
| 17:55.29 | seanbright | and figure out what is different |
| 17:56.20 | tm1000 | seanbright: they aren't doing hold |
| 17:56.22 | tm1000 | thats whats different |
| 17:56.30 | seanbright | who's not? |
| 17:56.41 | seanbright | https://github.com/onsip/SIP.js/blob/master/src/Web/Simple.js#L216 |
| 17:56.43 | tm1000 | Simple is not |
| 17:56.55 | tm1000 | https://github.com/onsip/SIP.js/blob/master/src/Web/Simple.js#L221 |
| 17:56.55 | seanbright | yes it is, how else did i just test it? |
| 17:57.08 | tm1000 | nevermind I see the hold but whats the point of muting |
| 17:57.09 | tm1000 | I dont mute |
| 17:57.15 | seanbright | mute shouldn't matter |
| 17:57.20 | tm1000 | thats the only difference |
| 17:57.22 | seanbright | don't mute, like i give a fuck |
| 17:57.23 | seanbright | heh |
| 17:57.51 | seanbright | that's the only difference? |
| 17:58.03 | seanbright | on what planet is that the only difference between your code and Simple.js? |
| 17:58.04 | tm1000 | session.hold(inviteOptions) |
| 17:58.08 | tm1000 | I also send inviteOptions |
| 17:58.43 | tm1000 | var inviteOptions = { |
| 17:58.43 | tm1000 | <PROTECTED> |
| 17:58.43 | tm1000 | } |
| 17:58.43 | tm1000 | seanbright: Stop treating me like an idiot Sean. Im not an idiot |
| 17:58.43 | seanbright | ok, well, this has teached the point of being OT for this channel |
| 17:58.44 | tm1000 | I didn't ask for your help |
| 17:58.46 | seanbright | reached* |
| 17:58.49 | tm1000 | ok cool. |
| 17:58.59 | seanbright | it's not a bug in sip.js as far as i can tell |
| 17:59.15 | tm1000 | ok |
| 18:00.23 | seanbright | if you look at the onAccepted callback they have defined, they are propogating hold and unhold events up to the UA and doing some other nonsense with the session description handler. my guess is that the problem is somewhere in there. |
| 18:00.43 | seanbright | and i apologize for treating you like an idiot. sorry for treating you like an idiot. |
| 18:00.55 | seanbright | that double apology was not intentional |
| 18:01.27 | tm1000 | It's probably because options.inviteWithoutSdp is false |
| 18:01.32 | tm1000 | against hold |
| 18:01.38 | tm1000 | I will try to remove that in one second |
| 18:01.45 | tm1000 | (I am not sure why that is false tbh) |
| 18:02.16 | seanbright | i'm not sure what that option does at all |
| 18:03.09 | tm1000 | If true, send the INVITE with no SDP offer. In this case, the SDP offer is to be generated by the remote endpoint, and the SDP answer will be sent in an ACK or PRACK. Default is false (send with SDP). |
| 18:03.20 | tm1000 | they dont modify that I dont know why I modify that |
| 18:03.59 | seanbright | the SDP is what is doing the hold/unhold (sendonly vs sendrecv), so i don't know how it would work without it |
| 18:05.19 | tm1000 | exactly |
| 18:05.26 | tm1000 | which is why yes you are right (I think) it is me |
| 18:05.32 | tm1000 | but I havent gotten there yet to check |
| 18:08.11 | tm1000 | ok now I am going to check |
| 18:08.40 | file | wonders when this became #webrtc-javascript-help |
| 18:08.49 | seanbright | it's my fault |
| 18:08.51 | seanbright | sorry |
| 18:08.56 | seanbright | you can kick me |
| 18:10.16 | file | I _could_ |
| 18:10.19 | seanbright | maybe we can talking about python 3 or building on slackwar... zzzzzzzzzzzzzzzzzzzzzzzzzzzzz |
| 18:10.33 | file | or I could just not kick you... yet... |
| 18:10.35 | tm1000 | ffs |
| 18:10.39 | tm1000 | why the hell am I doing this |
| 18:10.43 | tm1000 | seanbright: yes that was the issue |
| 18:10.45 | seanbright | k |
| 18:10.47 | file | and let it drag on until an undefined date and time in the future |
| 18:11.00 | tm1000 | I was doing that on all invites and reinvites as well |
| 18:11.54 | seanbright | yeah, stop doing that |
| 18:12.49 | tm1000 | seanbright: commented and closed. thanks |
| 18:12.57 | tm1000 | seanbright: but really thanks it was my code. |
| 18:13.08 | tm1000 | and I kept saying it wasn't. humbling moment |
| 18:13.13 | tm1000 | goes to hide in a cave |
| 18:13.27 | seanbright | i've been wrong before |
| 18:13.37 | seanbright | let me take you back... it was the summer of 1996 |
| 18:13.53 | seanbright | anyway, glad you got it figured out |
| 18:14.27 | tm1000 | also this PR https://github.com/onsip/SIP.js/pull/502 |
| 18:14.35 | tm1000 | fixes (allows) early media from asterisk correclt.y |
| 18:14.59 | tm1000 | seanbright: see you should come to astricon cause now I owe you a drink or money or hookers or drugs. |
| 18:16.02 | cresl1n | IRC is such a wholesome place |
| 18:16.17 | seanbright | that is not my experience at all |
| 18:16.29 | file | cresl1n: get back to work, you |
| 18:16.54 | tm1000 | cresl1n: this is open source, we don't trade in real money. |
| 18:17.12 | tm1000 | I figure if I can find the right hat I can get file to do almost anything |
| 18:17.39 | file | anyone can ask me to do anything, doesn't mean I'll do it though |
| 18:18.51 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 18:19.54 | sahmed | Hello, recently I got a crashed in my asterisk 13.20.0 |
| 18:20.26 | sahmed | could anyone please guide me on that? |
| 18:22.25 | sahmed | according to coredump crash was happened while it try to access media on a channel |
| 18:22.50 | sahmed | #0 0x00007f37016e3132 in chan_pjsip_read (ast=0x7f36244c0150) at chan_pjsip.c:743 |
| 18:23.27 | cresl1n | sahmed: you should probably open a bug report on it |
| 18:23.28 | cresl1n | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines |
| 18:24.25 | sahmed | cresl1n: Thanks, I will do that |
| 19:08.03 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.168) |
| 19:11.01 | seanbright | kharwell: have you actually profiled at all to know where the CPU time is being spent? or do you already know that? |
| 19:13.24 | kharwell | I did a little with profiling. Here are some of the top results I got (this was against Asterisk 15 branch at the time): https://pastebin.com/5C8PEexw |
| 19:13.40 | kharwell | nothing really stood out |
| 19:14.02 | seanbright | do you have kernel debug symbols installed? |
| 19:14.21 | kharwell | don't believe so |
| 19:14.36 | seanbright | that may give you more insight into kernel land |
| 19:14.47 | seanbright | but mayhaps not |
| 19:15.07 | seanbright | get cresl1n to get your a license to intel vtune |
| 19:15.12 | seanbright | you* |
| 19:15.30 | seanbright | if the CFO needs approval just let me know |
| 19:16.11 | kharwell | that was with some tool called oProfile |
| 19:16.16 | seanbright | yeah |
| 19:16.30 | seanbright | intel's profiler is just over 100000x times better |
| 19:16.40 | kharwell | never messed with vtune..expensive I take it? |
| 19:16.52 | seanbright | well, i got an OSS license |
| 19:16.56 | seanbright | not sure if that'd work for digium |
| 19:17.13 | seanbright | i think a single user license is like $1k or something, but i might be making that up |
| 19:17.42 | kharwell | ever use codexl? that was the other on my list as I perused profiles |
| 19:17.53 | seanbright | i have not |
| 19:18.18 | seanbright | the pricing is more attractive |
| 19:18.41 | kharwell | looks like 899 for standalone vtune |
| 19:19.40 | kharwell | they do have a trial though: https://software.intel.com/en-us/intel-vtune-amplifier-xe/try-buy |
| 19:20.18 | kharwell | oh wait yours probably fell under this "Students, educators, academic researchers, and open-source contributors may qualify for free software tools" |
| 19:20.24 | seanbright | yes |
| 19:26.26 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 19:26.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:32.52 | kharwell | AsteriskRoss: async_operations seemed to also have no effect |
| 19:59.03 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 20:30.19 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 20:30.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:10.16 | seanbright | am i remembering incorrectly or did we make pjsip required at some point? |
| 21:10.50 | file | it is not required |
| 21:11.00 | seanbright | k |
| 21:43.08 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 21:43.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:22.26 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-cohondryvnegiiqs) |