| 00:16.42 | *** part/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 00:23.12 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 01:05.00 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 01:34.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 01:35.08 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 02:33.18 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 02:48.57 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:48.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:06.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 04:18.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:32.10 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 05:32.10 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 06:35.47 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:51.49 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:54.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 07:36.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 07:36.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 08:42.35 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:14.53 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:26.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 09:41.01 | *** join/#asterisk-dev tzafrir (~tzafrir@81.218.177.19) |
| 09:41.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:56.39 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:28.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:25.20 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:10.58 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:25.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:33.19 | file | X-Rob, res_pjsip_multihomed is going in soon! |
| 12:33.40 | file | of course it's late there so who knows if he's around |
| 12:33.44 | file | but, yay |
| 12:43.05 | opticron | actually, I might know of a way to get a proper test for it in the testsuite |
| 12:43.23 | opticron | linux supports subinterfaces, right? |
| 12:43.56 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:44.50 | file | opticron, if it requires modifying the system itself then that's fine for our test nodes but not for people |
| 12:44.54 | opticron | so add a subinterface on the primary ethernet, pull a second IP, run the test on those two interfaces, and drop the subinterface when you're done |
| 12:44.57 | file | (this discussion already happened) |
| 12:45.02 | opticron | ok, fair enough |
| 12:45.07 | opticron | I missed it |
| 12:45.30 | file | but yes, that is a way |
| 12:50.07 | file | skrusty, I sent an email out about an alternative approach for the DTMF stuff with bridge creation and it would be great to have your feedback on it |
| 12:50.15 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:50.19 | file | (as you are a consumer of ARI) |
| 12:52.21 | skrusty | will do |
| 12:52.24 | skrusty | :) |
| 12:52.39 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 12:56.23 | skrusty | file: interesting, i will contrib back on like, but it might be a better way forward as "features" can be wrapped up and packaged out via ARI as a required feature, not specifically a property of the bridge |
| 12:56.32 | file | yeah |
| 13:16.31 | pabelanger | time to profile app_confbridge in asterisk 11 |
| 13:16.52 | pabelanger | default configuration of 1.8 gets me 512 channels in app_meetme |
| 13:17.13 | pabelanger | rumour has it confbridge will blow it away |
| 13:17.14 | skrusty | file: posted my thoughts :) |
| 13:17.27 | skrusty | (the ramblings skrusty) |
| 13:18.20 | leifmadsen | pabelanger: per my testing at Digium... yes. |
| 13:18.36 | pabelanger | leifmadsen, remember the amount of channels you had? |
| 13:18.40 | leifmadsen | we did some pretty godo testing on app_confbridge in Asterisk... 10 with David Vossel and I think Qwell |
| 13:18.40 | pabelanger | or any results page? |
| 13:18.48 | leifmadsen | pabelanger: thousands? |
| 13:18.57 | pabelanger | Hmm |
| 13:18.59 | Qwell | leifmadsen: mmm, nope |
| 13:19.01 | leifmadsen | depends on transcoding etc |
| 13:19.09 | pabelanger | Right, no transcoding, native format |
| 13:19.15 | leifmadsen | many many many calls. |
| 13:19.16 | pabelanger | everybody a listener in my case |
| 13:19.36 | pabelanger | sliske_-, fyi ^ |
| 13:19.37 | leifmadsen | oh I know what you're working on :) |
| 13:19.44 | leifmadsen | yes, use app_confbridge for sure |
| 13:19.51 | file | pretty sure that'll still transcode, it's not that smart |
| 13:20.00 | leifmadsen | through slin? |
| 13:20.13 | file | yes |
| 13:20.24 | leifmadsen | what if you dropped it into the conf via slin? |
| 13:20.36 | leifmadsen | like you had edge Asterisk machines that did the transcoding before it got to the conference machine? |
| 13:20.45 | file | then fine |
| 13:20.47 | pabelanger | sln -> ulaw (wav) is my scenario right now |
| 13:20.55 | leifmadsen | pabelanger: sliske_-: something to consider |
| 13:21.03 | leifmadsen | I'm not sure your topology |
| 13:21.04 | pabelanger | sln is native format in confbridge |
| 13:21.08 | leifmadsen | right |
| 13:21.17 | pabelanger | and Ulaw is the SIP for incoming members |
| 13:21.20 | leifmadsen | what I'm saying is if transcoding is an issue, do it on the edge machines |
| 13:21.23 | pabelanger | so, there is a convert happening |
| 13:21.29 | leifmadsen | yes. |
| 13:21.45 | pabelanger | leifmadsen, Ya, I would love to see some rtpproxy handle that on the edge |
| 13:21.52 | leifmadsen | and go. |
| 13:22.02 | pabelanger | no codec_slin for sip |
| 13:22.04 | pabelanger | or is there? |
| 13:23.58 | pabelanger | file, is one able to control the native format confbridge mixes at? |
| 13:24.15 | file | you can only mix at signed linear |
| 13:24.16 | file | so, no |
| 13:24.23 | Qwell | file: well, slin, slin16 |
| 13:24.28 | pabelanger | why is that? Only mixing at slin? |
| 13:24.40 | pabelanger | otherwise you need more code for other formats? |
| 13:24.42 | Qwell | pabelanger: because that's the only thing that's possible |
| 13:25.12 | pabelanger | Qwell, right, is it a technical limitation, like other formats don't support it, or we just don't have support for mixing others |
| 13:25.46 | opticron | it's not going to be easy to mix a compressed format unless that compression is designed to allow for compressed mixing without transcoding steps |
| 13:26.02 | pabelanger | thanks, that's what I was looking for |
| 13:33.11 | *** join/#asterisk-dev bford (~bford@nat/digium/x-qhukxpozzcmptxhe) |
| 13:36.48 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:36.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:37.39 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 13:39.33 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 13:39.33 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 13:50.48 | *** join/#asterisk-dev reconwireless (uid10170@gateway/web/irccloud.com/x-onjqmceomjxokovd) |
| 14:05.13 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-eizjqdfczxhtoyba) |
| 14:20.56 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mcfmvnflxkwgkaoo) |
| 14:21.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 14:22.28 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:22.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.36 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 14:48.19 | file | pon pon pon. |
| 14:58.18 | scouture | hey guys. if anyone of you feels like it, i'm looking for some feedback on a patch i've provided for ASTERISK-18411 (dynamic hints used as state_interface for queue members). thanks! |
| 14:58.51 | pabelanger | scouture, So, I just hit something like this last week |
| 14:59.14 | scouture | pabelanger: oh yeah? |
| 14:59.19 | pabelanger | Have you checked *CLi> sip show channels |
| 14:59.26 | pabelanger | to confirm you don't have a hung channel? |
| 14:59.31 | pabelanger | also, are you using SIP session timers |
| 14:59.43 | pabelanger | my issue, asterisk reported a queue_member IN_USE |
| 15:00.00 | pabelanger | however, I had a SIP channel that was hung for 5 hours, |
| 15:00.16 | pabelanger | Asterisk still thought the channel was used, but clearly it was dead |
| 15:00.39 | scouture | yeah, no, the issue as far as we're concerned is app_queue relying on a dynamic hint that disappears across a 'dialplan reload' |
| 15:01.06 | scouture | so the agent's state is stuck on the last state app_queue had for the hint |
| 15:06.43 | scouture | pabelanger: not to say we haven't had our fair share of stuck channels though.. were you able to soft hang up those? that's an issue we had with 1.8 a lot; channels stuck in the 'ring' state, that you couldn't hang up unless you restarted Asterisk. |
| 15:08.14 | scouture | although we've seen that happen less frequently with 11, a couple occurrences did come up, but we were able to soft hangup those channels, contrary to 1.8 |
| 15:11.58 | scouture | pabelanger: by the way, i've been following the kickstand project from afar for a little while now.. definitely interested in where this is going. how did the summit go? |
| 15:12.48 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 15:13.01 | jsmith | scouture: It went well :-) |
| 15:14.51 | scouture | great! my impression was that it was coming along quite nicely even before the summit. any breakthroughs? :) |
| 15:15.23 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-ppxdtehdjrohcwxh) |
| 15:15.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:16.59 | pabelanger | scouture, okay, ya, just my findings from last week since I thought I had the same issue |
| 15:23.22 | pabelanger | Back to profiling, we managed 1000 calls on meetme, using quad core 8GB memory. That was the limit of the box, then we seen audio issues |
| 15:23.31 | pabelanger | confbridge now |
| 15:24.40 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:36.18 | scouture | pabelanger: what kind of memory footprint did you see on a 1000 calls? it must have remained fairly low, with the cpu being the bottleneck still? |
| 15:37.26 | pabelanger | sliske_-, ^ |
| 15:37.38 | pabelanger | want to say 380MB? |
| 15:37.53 | leifmadsen | scouture: sounds like there will be regular meetings, and we discussed the minimum viable product, a little bit of the timeline, and getting ripcord (authentication API) going (and documenting it) |
| 15:38.09 | leifmadsen | scouture: all the notes are here: http://etherpad.kickstand-project.org/p/hx46rUvHuv <-- beyond this, join #kickstand-dev |
| 15:38.28 | leifmadsen | goes back on-topic |
| 15:38.43 | scouture | leifmadsen: cool, i'll do that. thanks. |
| 15:48.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@mf92636d0.tmodns.net) |
| 15:50.11 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-wzawpuupcbhmzscs) |
| 15:51.34 | file | mjordan, good to go on res_pjsip_multihomed commit? |
| 15:52.37 | mjordan | yes |
| 15:52.42 | mjordan | I'd comment in the commit how it was tested |
| 15:52.46 | file | yeah |
| 15:52.48 | mjordan | (may as well, anyway) |
| 16:03.51 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ujbcraqephgaukoi) |
| 16:05.33 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:23.47 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-afwdqovlsbkwdwlg) |
| 16:23.47 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:27.53 | pabelanger | first round of profiling confbridge, coredump :( |
| 16:29.51 | pabelanger | profile* |
| 16:31.59 | skrusty | heh :) |
| 16:32.30 | skrusty | pabelanger: any change you could share your results, be interesting to compare to my SimpleConf built on ARI |
| 16:34.01 | skrusty | "chance" even |
| 16:34.53 | pabelanger | ya, want to get the findings on line at some time |
| 16:51.19 | pabelanger | okay, so getting some what terrible results from app_confbridge |
| 16:51.35 | pabelanger | after 300 channels, distorted audio on the bridge |
| 16:55.14 | pabelanger | mixing_interval=20 was the killer |
| 16:55.19 | pabelanger | moved to 40 and improved |
| 16:55.23 | pabelanger | going to 80 now |
| 17:02.41 | pabelanger | Ya, there is something wrong, 1.8 with meetme, is preforming WAY better then 11 with confbridge |
| 17:02.52 | pabelanger | we are getting terrible audio quality in 11 |
| 17:03.32 | file | with a single conference bridge with tons of participants I could see Meetme performing better |
| 17:03.59 | pabelanger | file, why is that? |
| 17:04.34 | file | because ConfBridge has a single thread running in user space which has to mix and produce a frame for all of those channels |
| 17:04.50 | pabelanger | okay, so that make sense then |
| 17:05.03 | pabelanger | and why we are seeing 1 thread consuming a ton of CPU |
| 17:05.29 | seanbright | 300 talkers? |
| 17:06.04 | file | I don't know if ConfBridge has been optimized that much to take it into account |
| 17:06.25 | pabelanger | no, 300 listeners, 1 talker |
| 17:06.32 | pabelanger | or 1000 listeners and 1 talker |
| 17:06.49 | file | a holding bridge would be much more efficient there |
| 17:06.52 | pabelanger | Right |
| 17:07.05 | pabelanger | I don't think confbridge in 11 has access to that, right? |
| 17:07.09 | file | nope |
| 17:07.31 | pabelanger | but I could use Bridge() I think |
| 17:07.33 | pabelanger | to set it up |
| 17:07.45 | pabelanger | well, no |
| 17:07.51 | pabelanger | would need asterisk 12 |
| 17:09.07 | mjordan | Bridge is always a two party bridge |
| 17:09.08 | pabelanger | time to compile asterisk |
| 17:09.14 | mjordan | BridgeWait is a holding bridge |
| 17:09.16 | pabelanger | mjordan, ya, read documentation |
| 17:09.28 | pabelanger | was confusing it with jrose_atDigium bridge_wait() app |
| 17:12.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 17:16.20 | pabelanger | file, so you think confbridge will scale better with holding more conference on a box, but be limited with the amount of people in said conference |
| 17:16.36 | pabelanger | in 11 |
| 17:24.43 | putnopvut | gtjoseph: hey I remember you asking in here or on the mailing list at one point about consolidating the sorcery instance used in res/res_pjsip/config_system.c and the sorcery instance used for the rest of res_pjsip. Did that ever go anywhere, or were you just curious about it? |
| 17:25.01 | gtjoseph | it's done and committed |
| 17:25.23 | gtjoseph | the one created by system is used for the rest of pjsip |
| 17:25.38 | putnopvut | gtjoseph: cool |
| 17:25.38 | putnopvut | updates |
| 17:27.28 | putnopvut | gtjoseph: hm, was that change only made in trunk? |
| 17:27.42 | gtjoseph | nope should have been made in 12 |
| 17:28.02 | gtjoseph | not seeing it? |
| 17:28.37 | putnopvut | gtjoseph: nope. In res/res_pjsip/pjsip_configuration.c, I see the sip_sorcery object being opened and acted on, and in res/res_pjsip/config_system.c, I see the system_sorcery being opened and acted upon. |
| 17:28.44 | putnopvut | Seems to be the same as it was before. |
| 17:29.19 | putnopvut | looks through the -commits list |
| 17:29.53 | gtjoseph | ah, the callers don't know it's the same one. Sorcery now keeps track of instances by module. The first caller creates a new instance, subsequent callers get the original one |
| 17:30.08 | file | putnopvut, as it exists yes |
| 17:32.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:3e97:eff:fe14:ef66) |
| 17:32.30 | putnopvut | okay. The reason I had been asking is that ast_sorcery_apply_config() is being called twice during PJSIP's startup. If you have a realtime backend specified in sorcery.conf, this means that the same wizard is applied to the object type twice. This results in queries returning all results twice. |
| 17:32.54 | putnopvut | So in my test, I have two endpoints configured and perform a PJSIPShowEndpoints AMI action. The result lists four endpoints, each one listed twice. |
| 17:33.39 | putnopvut | I thought that if there was only a single sorcery instance, then the attempt to apply the config would only occur once and would solve this problem automagically. |
| 17:33.44 | gtjoseph | do you know where the ast_sorcery_apply_config() is being called from? |
| 17:34.33 | putnopvut | res/res_pjsip/config_system.c::ast_sip_initialize_system() and res/res_pjsip/pjsip_configuration.c::ast_res_pjsip_initialize_configuration() |
| 17:34.58 | gtjoseph | is looking |
| 17:35.17 | putnopvut | Since both calls to ast_sorcery_apply_config() tell it to apply the same configuration section from sorcery.conf, the result is that everything gets applied twice. For some reason this doesn't seem to show itself if you use the default sorcery backends. |
| 17:35.27 | putnopvut | Probably because there's no sorcery.conf involved then. |
| 17:36.48 | putnopvut | The fixes are either to 1) only call ast_sorcery_apply_config() once, 2) Specifiy a separate config section in sorcery.conf for system config (gross), or 3) have sorcery not apply the same wizard twice for an object type. |
| 17:37.12 | file | blargh |
| 17:38.05 | X-Rob | file: YAY MULTIHOMED. I'm easily amused. |
| 17:38.10 | gtjoseph | it's probably going to have to be 3. |
| 17:38.22 | putnopvut | gtjoseph: that's what I was thinking. file, got objections to it? |
| 17:38.35 | file | no |
| 17:38.39 | putnopvut | file: cool beans. |
| 17:43.37 | pabelanger | boo, confbridge drops the call when the conference is locked |
| 17:44.03 | gtjoseph | file, putnopvut: apply_config only takes the module name for an argument so maybe it should be done automatically when the instance is created (only once) |
| 17:44.27 | file | without redoing how default wizards are done you can't |
| 17:44.37 | pabelanger | trying to get it to fall through to the next dialplan |
| 17:44.44 | putnopvut | I've pretty much already got the change I talked about written anyway :) |
| 17:45.24 | putnopvut | Ah, much better now. |
| 17:45.27 | gtjoseph | file: why? both config_system and pjsip_configuration call apply directly after open anyway? |
| 17:45.41 | gtjoseph | putnopvut: that qas quick :) |
| 17:46.24 | putnopvut | It wasn't too difficult. |
| 17:46.30 | file | ah I forgot the order I did things in, CARRY ON |
| 17:48.15 | gtjoseph | just thinkin... if apply_config should only be called once per instance, then we should move the call anyway. |
| 17:48.30 | gtjoseph | or 'as well' |
| 17:49.18 | putnopvut | Yeah, I'd be fine with that. What I've written in sorcery is pretty much a band-aid for the mis-coding being done in res_pjsip files if you ask me. |
| 17:49.59 | putnopvut | If there's just one sorcery being used, then I think that applying config should be called once. |
| 17:51.17 | gtjoseph | let's do that then... remove apply_config from both system and configuration and put it in __ast_sorcery_open after the new instance is allocated |
| 17:53.15 | putnopvut | I don't know that we can just put it in __ast_sorcery_open() since __ast_sorcery_open() won't know what configuration section from sorcery.conf to apply. |
| 17:55.46 | gtjoseph | the ast_sorcery_apply_config macro only get's called from these 2 places and res_mwi_external |
| 17:56.01 | gtjoseph | and in both cases they use their module name |
| 17:56.13 | gtjoseph | as the category |
| 17:57.45 | putnopvut | Hm...I'm giving it some thought. I'm trying to decide if there is any real likelihood in a module wishing to load sorcery configuration from multiple configuration sections. The thing is, I can't see why any module would want that. |
| 17:58.36 | putnopvut | It's not as if the objects in one configuration section are disparate from the objects in a different one. Really, separating configuration by module makes sense to me, and using the module name makes sense by me at least. |
| 17:58.50 | gtjoseph | mee too. |
| 17:59.38 | gtjoseph | at the very least, i don't see how it could hurt anything in the current codebase. |
| 17:59.49 | putnopvut | okay. I'll give it a shot. |
| 18:00.17 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-ebjiuvzyxnssidlb) |
| 18:00.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:03.41 | mjordan | sgriepentrog: for your sdp_offer_answer tests, did you find that having tests for UDP/TCP as well as IPv4/IPv6 was necessary for testing codec negotiation? |
| 18:03.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 18:05.52 | pabelanger | file, you are the man |
| 18:05.54 | pabelanger | that was the issue |
| 18:06.01 | file | what? |
| 18:06.04 | pabelanger | 1000 calls across 4 rooms, better audio |
| 18:06.06 | pabelanger | then1 room |
| 18:06.09 | file | yes |
| 18:06.16 | pabelanger | that is 11 |
| 18:06.24 | pabelanger | going to push to 1500 |
| 18:06.27 | pabelanger | and see the results |
| 18:06.28 | pabelanger | then asterisk12 |
| 18:06.32 | pabelanger | with bridgewait |
| 18:06.35 | file | if the amount of time it takes to mix your audio exceeds the interval at which you are attempting to mix audio... then sadness |
| 18:06.37 | pabelanger | or hold bridge |
| 18:14.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qahvmwdatfxavenh) |
| 18:19.20 | hexanol | out of curiousity, how hard do you think this bug would be to resolve ? https://issues.asterisk.org/jira/browse/ASTERISK-21737 |
| 18:19.48 | Qwell | resolve, or fix? :) |
| 18:20.19 | hexanol | as you wish |
| 18:21.52 | hexanol | (since I'm not a native english speaker, I could even ask what's the difference between fixing it and resolving it) |
| 18:22.22 | Qwell | An issue can have a resolution of "Won't fix". |
| 18:22.47 | hexanol | ah ok, this is a bit playing on the word I guess |
| 18:22.59 | hexanol | anyway, I'm talking about a "real" fix |
| 18:23.07 | hexanol | maybe not the most beautiful solution |
| 18:23.12 | hexanol | but something that would work |
| 18:24.01 | hexanol | or |
| 18:24.20 | hexanol | another question I could have, is that would I also have the bug if I was using asterisk 12 ? |
| 18:43.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 18:49.42 | sgriepentrog | mjordan: re sdp_offer_answer - no, I didn't expect it to be necessary, but wanted to model the offer/answer after the basic tests, only with the 4/6 udp/tcp broken out so it would be easy to determine what was failing. Consider it a baseline for other offer/answer tests to be added in the future. |
| 18:50.59 | pabelanger | [2014-03-11 18:50:28.982] WARNING[1836][C-00000b85]: bridge.c:767 bridge_base_init: Bridge 3cae971d-465a-4d2c-9c08-06d2a1943d89: Could not create class base. No technology to support it. |
| 18:51.18 | pabelanger | did I miss something for bridgewait()? |
| 18:52.00 | file | bridge_holding.so? |
| 18:52.29 | pabelanger | file, yup, missing depending on module load I guess |
| 18:55.36 | pabelanger | wow, it takes some time for asterisk to drain the bridge now |
| 18:58.46 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:00.04 | pabelanger | okay, so how do you disable MOH on bridgewait() ? |
| 19:00.09 | pabelanger | options don't appear to do it |
| 19:02.09 | pabelanger | I would expect: |
| 19:02.11 | pabelanger | <PROTECTED> |
| 19:02.13 | pabelanger | so play no audio |
| 19:02.31 | pabelanger | jrose_atDigium, ^ |
| 19:04.59 | file | e(s) |
| 19:05.03 | pabelanger | file, okay, so single holdbridge using BridgeWait() seems to have the same limitations as ConfBridge. Audio quality is related to amount of people on the bridge |
| 19:05.32 | mjordan | sgriepentrog: well.... I like it. But I have about 100 of those to add, and including transports turns that into 400 :-P |
| 19:05.45 | file | e(n) would be better from a doing stuff perspective |
| 19:07.18 | mjordan | well, and let's be honest here for a second. If I ask you to hand a note to 1 person, that's not the same thing as handing a note to 100000 people. There's a scaling issue here. |
| 19:07.33 | pabelanger | [2014-03-11 19:07:08.166] WARNING[5542]: channel.c:1174 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/101@public-00000015;2 |
| 19:07.33 | sgriepentrog | Maybe there could be some way of creating 4 run-time paths (4/6, tcp/udp) with only a single test directory? |
| 19:07.57 | file | Local channels will also impact scaling. |
| 19:08.04 | pabelanger | Right |
| 19:08.07 | mjordan | Well, we definitely need to test transports and address schemes. But I'm not sure we have to test that on every test |
| 19:08.19 | pabelanger | so, I am using a local channel just to dump an external audio source into the bridge |
| 19:08.27 | pabelanger | just to see what happens |
| 19:08.28 | sgriepentrog | Say, optional arguments in the tests.yaml -test: entry |
| 19:08.33 | mjordan | nah |
| 19:08.49 | mjordan | more optional arguments are bad - and keep in mind that doing IPv6 requires changes to the SIPp scenarios |
| 19:08.51 | pabelanger | Ideally, I would see the best way to hook said audio source into the bridge directly |
| 19:09.27 | sgriepentrog | Actually, it only requires changes to the sipp arguments in yaml, assuming you've written the sipp flexibly |
| 19:09.31 | mjordan | pabelanger: that doesn't really fundamentally work with Asterisk's architecture |
| 19:09.46 | pabelanger | mjordan, the local channel thing? |
| 19:09.51 | pabelanger | or hooking in external audio |
| 19:10.04 | mjordan | sgriepentrog: true, but this feels like over-engineering for something that I'm not sure needs to be tested there. If we've already tested a thing, we don't need to test it another 100 times |
| 19:10.13 | mjordan | pabelanger: Asterisk uses channels to move media. |
| 19:10.32 | sgriepentrog | Except when you turn up that one odd case where the IPv6 tcp test fails and nothing else does... |
| 19:10.37 | pabelanger | mjordan, right, this is just a proof of concept right now. |
| 19:10.42 | mjordan | which is already covered by the other tests ;-) |
| 19:10.57 | mjordan | allow=all or allow=ulaw,alaw,g729 isn't an IP related thing |
| 19:11.07 | pabelanger | Ideally, I need to figure out how to better move audio into a bridge, external to asterisk |
| 19:11.35 | sgriepentrog | In that case, no. it isn't. |
| 19:12.22 | sgriepentrog | Although if that where to fail only certain protocols you would know it was something setup wrong. |
| 19:13.14 | mjordan | well, I think there's tests that need to cover setting up a call over multiple transports and IP schemes |
| 19:13.24 | mjordan | but with the SDP offer/answer, I really just want to cover the SDP parsing and media set up |
| 19:13.36 | mjordan | I think there's a few things in there that are transport related - like the media address |
| 19:13.42 | mjordan | that clearly needs an IPv4 and an IPv6 test |
| 19:13.50 | sgriepentrog | Okay. I really don't have any problem with dropping the non 4/udp tests. |
| 19:14.17 | mjordan | I do like that it was broken up though ;-) |
| 19:14.32 | sgriepentrog | Or even just leaving the other options commented out in the main test so they can be put back in to check something. |
| 19:15.03 | sgriepentrog | You |
| 19:15.31 | sgriepentrog | oops . You're right that it seems like overkill - but sometimes testing things you don't expect to ever fail catches something you otherwise wouldn't. |
| 19:16.34 | seanbright | pabelanger: can you run patched versions of asterisk? i have a patch for 11 that might help a bit |
| 19:16.54 | mjordan | hm |
| 19:17.00 | mjordan | that is an interesting question. What version of 11 are you running? |
| 19:19.50 | pabelanger | seanbright, Ya, this is just a testing environment right now. Basically trying to determine which path to take for a client |
| 19:20.12 | seanbright | what kind of hardware will this be running on? |
| 19:20.19 | seanbright | x86_64? |
| 19:20.52 | pabelanger | Yup, x86_64 system on rackspace |
| 19:20.58 | seanbright | hmmm |
| 19:20.59 | seanbright | ok |
| 19:21.14 | seanbright | ok, stand by for patch that may or may not actually work |
| 19:21.24 | pabelanger | sure |
| 19:22.00 | seanbright | http://paste.ubuntu.com/7075260/ |
| 19:22.24 | mjordan | pabelanger: srsly. What version of 11? |
| 19:22.44 | pabelanger | mjordan, HEAD |
| 19:22.49 | pabelanger | from subversion |
| 19:22.55 | file | seanbright, ah that |
| 19:22.55 | seanbright | that patch uses SSE3 for the saturated arithmetic instead of ast_slinear_saturated_add/subtract |
| 19:22.56 | mjordan | kk |
| 19:22.58 | mjordan | just making sure |
| 19:23.11 | mjordan | seanbright: yeah, that would help |
| 19:23.14 | pabelanger | seanbright, what impact does your patch do? |
| 19:23.19 | pabelanger | just so I understand |
| 19:23.30 | seanbright | it uses SIMD instructions to mix 8 samples at once |
| 19:23.32 | file | there's a patch somewhere for removing the ao2 lookup for format stuff as well |
| 19:23.53 | seanbright | should have at least a 3x speed up on mixing |
| 19:24.09 | pabelanger | well, my testing setup could be exposed some place, and results recorded |
| 19:24.20 | pabelanger | I want to make the setup automated, to track asterisk over time |
| 19:24.25 | pabelanger | and record results |
| 19:25.17 | pabelanger | seanbright, no need to update my gcc compile flags, right? |
| 19:25.20 | seanbright | nope |
| 19:25.30 | pabelanger | okay |
| 19:25.34 | pabelanger | stand by for results |
| 19:25.44 | seanbright | should be using -march=native anyway if you're using a mostly vanilla asterisk |
| 19:26.19 | seanbright | this could be made faster with straight assembly, but that is a project for another day |
| 19:28.02 | file | yeah before going down that route I'd fully profile it to see where time is going |
| 19:29.06 | pabelanger | seanbright, so, your patch will improve people on the bridge vs audio quailty |
| 19:29.23 | seanbright | well, ideally it should help with both |
| 19:29.33 | file | it reduces the amount of time it takes to mix the audio |
| 19:29.38 | seanbright | that. |
| 19:30.00 | file | the less time it takes the more it can do within a specific interval of time |
| 19:30.20 | pabelanger | okayu |
| 19:30.29 | pabelanger | just updating dialplan now |
| 19:30.31 | pabelanger | single bridge |
| 19:30.36 | seanbright | and if you have avx2 support (which you don't) it could be faster |
| 19:30.37 | pabelanger | a lot of listeners |
| 19:39.35 | pabelanger | seanbright, what is your mixing_interval? |
| 19:39.41 | pabelanger | right now I setup 40 |
| 19:40.02 | seanbright | i don't see confbridge |
| 19:40.06 | seanbright | err |
| 19:40.10 | seanbright | i don't USE confbridge |
| 19:40.13 | pabelanger | ok |
| 19:40.39 | pabelanger | so, I need to see what the softbridge defaults to |
| 19:40.58 | seanbright | 20 |
| 19:41.09 | seanbright | #define DEFAULT_SOFTMIX_INTERVAL 20 |
| 19:41.40 | pabelanger | ya |
| 19:42.55 | pabelanger | 8000 the default sample rate? |
| 19:43.27 | seanbright | if you want the defaults why are you specifying values? |
| 19:43.52 | pabelanger | well, I update confbridge to not use default |
| 19:44.06 | pabelanger | I change to 8000 sample rate and 40 mixing interval |
| 19:44.29 | pabelanger | There looks to be a minor improvement in system load at my max calls |
| 19:44.44 | pabelanger | but wanted to see if the changes in your patch were specific to those values |
| 19:44.50 | seanbright | no |
| 19:45.00 | seanbright | all my patch does is change how audio is mixed |
| 19:45.10 | pabelanger | ok |
| 19:49.11 | pabelanger | Okay, results |
| 19:49.29 | pabelanger | there seems to be an improvement in system load. When I test against my 2000 channel limit |
| 19:49.46 | pabelanger | but that is still spreading channels across conf rooms |
| 19:49.49 | pabelanger | 250 over 8 |
| 19:50.23 | pabelanger | when I did dump them in to a single room, it seems we we're able to get 200 more, up to 500 |
| 19:53.20 | pabelanger | attempting 300 over 10 rooms |
| 19:56.35 | pabelanger | made it up to 3000 channels |
| 19:56.41 | pabelanger | audio was not as good |
| 19:56.49 | pabelanger | but at 80ms for samples |
| 19:56.57 | pabelanger | but, it does seem your patch has an improvement |
| 19:57.21 | pabelanger | seanbright, what is stopping you from merging it up? |
| 20:02.52 | pabelanger | TIL: Saturation arithmetic |
| 20:06.17 | seanbright | pabelanger: various reasons. it assumes sse3 support for one. |
| 20:07.28 | pabelanger | seanbright, interested in getting it merged? Assuming the leg work gets done and review process happens |
| 20:07.38 | seanbright | not particularly, no. |
| 20:08.04 | seanbright | i have reviewboard and commit access |
| 20:08.16 | seanbright | and it couldn't go into 11 at this point anyway |
| 20:08.43 | pabelanger | would you gpl the patch? |
| 20:08.48 | pabelanger | so I _could_ use it? |
| 20:09.41 | seanbright | I, Sean Bright, hereby grant Paul Belanger an irrevocable license to my SSE3 patch without limitation. |
| 20:09.46 | seanbright | -- Sean Bright |
| 20:09.51 | pabelanger | danke |
| 20:14.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:15.06 | mjordan | ooo |
| 20:15.13 | mjordan | More GPL than GPL |
| 20:15.14 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:17.32 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:20.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:26.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:36.30 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:45.05 | coreyf1513 | do the mailing lists block messages that come from non-subscribed addresses? |
| 20:45.28 | putnopvut | coreyf1513: yes |
| 20:46.15 | coreyf1513 | putnopvut: thanks., just wanted to make sure before I change my subscriptions and resend the message :) |
| 20:52.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:27.34 | putnopvut | mjordan: do test agents run ARI tests? |
| 21:27.36 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:29.28 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 21:29.30 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:29.30 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:33.34 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-outweudhjnubkjzx) |
| 21:38.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:38.24 | *** join/#asterisk-dev tzafrir (~tzafrir@81.218.177.19) |
| 21:38.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:38.27 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 21:41.05 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:41.05 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 21:41.05 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-tyrmtjbdpldvjzmj) |
| 21:41.05 | *** join/#asterisk-dev sliske_- (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 21:41.05 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-pgtaovigpfyazdnf) |
| 21:41.05 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 21:41.05 | *** mode/#asterisk-dev [+o putnopvut] by kornbluth.freenode.net |
| 21:42.26 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-yefrfimypinaxjbo) |
| 21:42.26 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:43.46 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 21:47.20 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ubrgpgsifipsylxo) |
| 21:47.36 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-zhspnlzutootcljf) |
| 21:48.07 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-hppmuonragqyjwot) |
| 21:48.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:49.05 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-dmwtbzvpdzgoicuw) |
| 22:05.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 22:05.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 22:13.58 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:13.59 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:24.57 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 23:12.11 | *** join/#asterisk-dev serafie (~erin@24.96.232.218) |
| 23:21.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 23:24.22 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-zhspnlzutootcljf) |
| 23:40.09 | *** join/#asterisk-dev serafie1 (~erin@24.96.232.218) |
| 23:41.02 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 23:41.02 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |