| 00:53.32 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:53.32 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Hell hath frozen over: Asterisk is moving to Git -=- Follow on Twitter at @AsteriskDev |
| 02:18.57 | *** join/#asterisk-dev superscrat (~asanders@173.21.89.217) |
| 02:42.09 | *** part/#asterisk-dev superscrat (~asanders@173.21.89.217) |
| 03:24.09 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 05:39.23 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 06:21.21 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:53.15 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:55.13 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 06:58.20 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 07:56.49 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:23.35 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 09:23.24 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 09:23.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:25.42 | *** join/#asterisk-dev Guest76385 (danjenkins@gateway/shell/firrre/x-ysqfzrerxczibght) |
| 11:23.02 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:23.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:39.24 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 12:02.44 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:36.14 | *** join/#asterisk-dev flujan (~flujan@200.160.115.22) |
| 12:44.23 | flujan | Hi there. I am studying asterisk code, trying to develop a SIT detection. First, I tried using function talk_detect, trying to detect earlymedia and failed. I am studying the ways to use the DSP to detect the sit tones. |
| 12:44.33 | flujan | Found this blog post: https://tucny.com/telephony/asterisk-sit-detection |
| 12:44.43 | flujan | Basically he implement a dsp on the dial and set it like this: ast_dsp_set_features(dsp, DSP_PROGRESS_CONGESTION); |
| 12:45.07 | flujan | I just donât understand what this function actually do. It will drop the call, generate a event or what? |
| 12:45.09 | flujan | Thanks. |
| 13:07.25 | *** join/#asterisk-dev opticron (~opticron@75.76.201.152) |
| 13:07.25 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 13:10.57 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 13:32.21 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:33.01 | *** join/#asterisk-dev opticron (~opticron@75.76.201.152) |
| 13:33.02 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 13:46.01 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-mrrjeiydcwwzazyb) |
| 13:46.06 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 13:46.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:48.20 | Kobaz | sadf,khjsadfkjhasdlkfhsafd |
| 13:48.21 | Kobaz | ugh |
| 13:48.33 | Kobaz | second time in a row, that two asterisk's were running at the same time, at this customer |
| 13:48.39 | Kobaz | they are going to hate us |
| 13:48.50 | Kobaz | at least i found the bug in our watcher that's supposed to detect and fix that |
| 13:57.52 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 13:58.12 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ydayoqhjgoxqfnrb) |
| 13:58.12 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:58.43 | dan_j | Typo in configs/samples/features.conf.sample. It still says Asterisk 12. |
| 13:59.15 | dan_j | If I were to correct that, does it need a JIRA? |
| 14:02.48 | gtjoseph | dan_j: nope |
| 14:03.16 | gtjoseph | minor stuff like that is ok to just do |
| 14:04.39 | dan_j | Ok. Thanks. |
| 14:05.03 | dan_j | Shame there is no way to globally replace the version numbers in those files. |
| 14:05.15 | dan_j | Or have a constant that can be quickly updated.. |
| 14:06.00 | gtjoseph | sed -i -r -e "s/ Asterisk 12/ Asterisk 13/g" |
| 14:06.06 | gtjoseph | :) |
| 14:06.54 | dan_j | Bit risky doing that isn't it? Unless you can guarantee that 'Asterisk 12' is always in a comment. |
| 14:07.08 | gtjoseph | that's why i did the smiley. |
| 14:07.20 | gtjoseph | :) |
| 14:07.34 | dan_j | Ah. Sorry. Had my programmer head on. |
| 14:07.46 | dan_j | Took it literally |
| 14:17.56 | *** join/#asterisk-dev sgriepentrog (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:19.31 | Kobaz | there's always git diff |
| 14:19.38 | Kobaz | to show you what broke |
| 14:30.08 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 14:41.12 | *** join/#asterisk-dev flujan (~flujan@200.160.115.22) |
| 15:06.13 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-mycysefngynaiqxm) |
| 15:13.17 | *** join/#asterisk-dev flujan (~flujan@200.160.115.22) |
| 16:15.51 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rbvzzgmjguwarjdt) |
| 16:37.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 16:37.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:44.29 | gtjoseph | rmudgett: forgot to check the load order... since the log forwarder doesn't rely on res_pjsip any reason I can't make it AST_MODPRI_CHANNEL_DEPEND - 4 ? |
| 16:49.56 | rmudgett | I was more thinking that res_pjsip could provide a global API for the PJ_MAX_HOSTNAME value. When res_pjsip_log_forwarder gets loaded (if ever) then it can tell res_pjsip what the value is. This way you don't HAVE to load res_pjsip_log_forwarder. |
| 16:51.06 | rmudgett | If res_pjsip_log_forwarder is loaded you will get pjsip logging. If not then you don't get pjsip logging. |
| 16:53.16 | rmudgett | These things being added to res_pjsip_log_forwarder are extras to the purpose of that module. |
| 16:53.38 | gtjoseph | yeah the problem is that we need to know the length while res_pjsip is loading |
| 16:55.01 | rmudgett | For config parameter validation? |
| 16:55.05 | gtjoseph | yep |
| 16:56.46 | gtjoseph | i always thought the log forwarder should be part of res_pjsip anyway. seems like a 'core' thing. |
| 16:58.36 | gtjoseph | wouldn't be hard to move that functionality into config_system.c |
| 16:59.27 | gtjoseph | or maybe I should just clone the pieces I need into config_system |
| 16:59.38 | rmudgett | Doing that gives no way to disable the pjsip logging. |
| 16:59.43 | *** join/#asterisk-dev Demon_VoIP (~demon@ip253.net222.n37.ru) |
| 17:00.18 | gtjoseph | true but why would you need to? |
| 17:01.06 | rmudgett | It's the same case as res_pjsip_logger |
| 17:01.51 | *** part/#asterisk-dev flujan (~flujan@200.160.115.22) |
| 17:02.09 | gtjoseph | yes but if yo don't turn it on, it does nothing |
| 17:02.50 | gtjoseph | ok, how about if I take the pieces I need and put them into config_system |
| 17:03.13 | rmudgett | res_pjsip_log_forwarder is in the same boat as res_pjsip_logger was initially. To enable logging you loaded the modue. To disable it you unloaded the module. |
| 17:04.30 | gtjoseph | so if i put what i need into config_system are you ok with it? |
| 17:05.57 | rmudgett | Yeah, I was thinking that res_pjsip could be a proxy for res_pjsip_log_forwarder's log_cb(). The res_pjsip log_cb could do the show_buildopts stuff. When res_pjsip_log_forwarder is loaded it could supply a callback to res_pjsip to call when res_pjsip is not intercepting the pjsip log messages. |
| 17:07.25 | rmudgett | That way the new CLI commands don't live in res_pjsip_log_forwarder and dilute the purpose of the log forwarder module. |
| 17:09.23 | gtjoseph | well, the other option is to revert log_forwarder back before your changes and have config_system, do the pj_dump_config once and store the result. then the cli can just dump the result anytime |
| 17:09.41 | gtjoseph | and the api can parse it anytime |
| 17:10.11 | gtjoseph | it's not like it's a lot of data |
| 17:10.11 | rmudgett | I've just added a new CLI command to dump more debug information. |
| 17:10.19 | rmudgett | That information is not static. |
| 17:11.14 | gtjoseph | but now we've got cli commands that are dependent on that module |
| 17:12.51 | rmudgett | And those CLI commands don't exist if the module is not loaded. |
| 17:13.01 | rmudgett | Anyway see: https://gerrit.asterisk.org/#/c/2022/ |
| 17:13.07 | gtjoseph | but their dicumentation does |
| 17:13.46 | rmudgett | The only documentation for those CLI commands is loaded when the module is loaded. |
| 17:13.56 | gtjoseph | not on the wiki :) |
| 17:14.15 | rmudgett | I think you are thinking of config option documentation. |
| 17:15.07 | gtjoseph | ok, fine :) so i'll move my bits out of forwarder and put them in config_system |
| 17:15.22 | gtjoseph | and the forwarder can stay optional |
| 17:16.03 | gtjoseph | agreed? |
| 17:16.50 | rmudgett | Yes. And the additional CLI commands should be moved to res/res_pjsip/pjsip_cli.c |
| 17:17.17 | rmudgett | That way the commands will always be available. |
| 17:17.49 | gtjoseph | pjsip_cli was meant to be the cli infrastructure |
| 17:18.21 | rmudgett | oh |
| 17:18.47 | gtjoseph | i was thinking that commands should go with the data they expose |
| 17:19.46 | rmudgett | I was trying to group the CLI commands. There doesn't seem to be a common place where they are coded. |
| 17:20.37 | gtjoseph | they're prettymuch as I indicated...with the data they expose |
| 17:22.19 | rmudgett | Ok. I just hadn't found a good place for them. |
| 17:23.43 | gtjoseph | ok, so... we put put log_forwarder back to its original state but we have it call a new res_pjsip api to register itself as the logger... |
| 17:24.06 | gtjoseph | we put the redirection bits and cli stuff into config_system |
| 17:24.24 | rmudgett | sounds like a plan |
| 17:24.44 | gtjoseph | and move pjsip show version from pjsip_cli to config_system |
| 17:26.10 | rmudgett | Why does that one need to move? |
| 17:26.22 | gtjoseph | so now how do we do this? use your patches to do the work, my patches to do the work, or we scrap ours and one of us does it with a new patch? |
| 17:26.30 | gtjoseph | just to clean things up |
| 17:27.25 | rmudgett | My new one can be placed on hold until you get your's done. I can then update mine. |
| 17:28.13 | gtjoseph | ok sounds good |
| 17:30.22 | rmudgett | Just put mine into WIP status. Does that remove it from public view? See above link. |
| 17:33.59 | gtjoseph | yep it does |
| 17:56.30 | gtjoseph | file: pj_init and pj_shutdown... do you know if they are process-level or module-level? |
| 17:56.41 | file | process. |
| 17:56.54 | gtjoseph | so we should NOT be doing them in other modules |
| 17:57.00 | gtjoseph | which we are |
| 17:57.12 | gtjoseph | log_forwarder and rtp_asterisk |
| 17:58.42 | file | their implementation allows them (at least pj_init from memory) to be called multiple times without problem |
| 17:59.45 | gtjoseph | ok |
| 18:49.56 | *** join/#asterisk-dev Demon_VoIP (~demon@ip253.net222.n37.ru) |
| 19:48.57 | tm1000 | file: gimmie a release⦠I want my 13.7!! :â( |
| 19:57.20 | file | tm1000, kharwell may or may not be working on it |
| 19:58.10 | file | is off today |
| 20:16.23 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 20:25.41 | *** part/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 20:30.23 | gtjoseph | rmudgett: 2012/2013 are ready to be based upon. |
| 20:30.34 | rmudgett | I saw |
| 20:30.51 | gtjoseph | in the new version, there's no need for the mutex so if you need it, add it back in |
| 20:31.39 | rmudgett | The mutex is required to prevent other CLI instances from interfering with each other. |
| 20:32.43 | rmudgett | As well as other CLI commands that do something similar in their internals from interference. |
| 20:33.25 | gtjoseph | Agreed, just sating I didn't need it because it's a one-time-thing now. |
| 20:33.33 | gtjoseph | s/sating/stating/ |
| 21:27.19 | kharwell | tm1000: ask and you shall receive! 13.7.0 and 11.21.0 are now released |
| 21:27.52 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:27.52 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 21:31.56 | tm1000 | whoooo! |
| 21:37.05 | jsmith | kharwell: Great -- now I have to go update Fedora packages :-/ |
| 21:37.12 | jsmith | I should make leifmadsen do it :-p |
| 21:43.58 | gtjoseph | coreyfarrell rmudgett well, i suppose I could create a completely standalone module whose sole purpose is to expose pjproject data and make it load before res_pjsip, res_rtp_asterisk and res_pjsip_log_forwarder |
| 21:44.48 | rmudgett | coreyfarrell: Argh you had to go and make things more difficult didn't you. :) |
| 21:45.18 | gtjoseph | is anyone really going to run res_rtp_asterisk with pjproject but not use res_pjsip? |
| 21:45.30 | rmudgett | Those who use chan_sip with ICE |
| 21:45.48 | gtjoseph | the ICE support is a pjproject-only feature? |
| 21:46.04 | rmudgett | That is what supplies the ICE support. |
| 21:46.14 | gtjoseph | gotcha |
| 21:46.21 | gtjoseph | so, seaprate module? |
| 21:46.37 | rmudgett | Looks like it has to be. |
| 21:47.15 | gtjoseph | the I have to make those other 3 modules depend on it, OK? |
| 21:47.31 | rmudgett | Have to |
| 21:47.38 | gtjoseph | ok, stay tuned. |
| 21:48.39 | gtjoseph | res_pjproject_proxy? or something else? |
| 21:49.16 | gtjoseph | res_pjproject_we_have_to_do_this_because_pjproject_doesn't_have_good_apis maybe |
| 21:52.03 | gtjoseph | coreyfarrell: rmudgett: ^^^ vote now. :) |
| 21:52.43 | coreyfarrell | abstains from voting |
| 21:53.08 | rmudgett | Sounds like a good enough name to me. |
| 21:53.23 | coreyfarrell | rmudgett: what is the problem the log forwarder having global symbols? |
| 21:53.29 | gtjoseph | res_pjproject_proxy it is |
| 21:53.57 | gtjoseph | i need it before res_pjsip loads. |
| 21:54.26 | gtjoseph | well, before res_pjsip starts sorcery processing |
| 21:54.38 | rmudgett | coreyfarrell: res_pjsip.so needs to know PJ_MAX_HOSTNAME to process the config. |
| 21:54.56 | rmudgett | Compile time is not sufficient |
| 21:55.03 | coreyfarrell | rmudgett: I'm saying why is it a problem for res_pjsip_log_forwarder to expose global symbols and be used by res_pjsip? |
| 21:55.44 | rmudgett | That makes res_pjsip dependent upon res_pjsip_log_forwarder. |
| 21:55.57 | rmudgett | You then always have to load res_pjsip_log_forwarder |
| 21:56.10 | rmudgett | It is optional now. |
| 21:56.14 | coreyfarrell | oh hadn't considered the possibility that someone would not want logs |
| 21:56.34 | gtjoseph | see, that's what I thought. :) |
| 21:56.37 | rmudgett | What? With the amount of disk space logs consume? :) |
| 21:57.06 | coreyfarrell | rmudgett: wouldn't it be debug log? |
| 21:57.35 | rmudgett | Most of the output is DEBUG but pjlib can output ERROR and WARNING |
| 21:58.03 | rmudgett | What pjlib uses as level 1 and 2. |
| 21:58.09 | rmudgett | Level 3 and above is DEBUG |
| 21:58.29 | coreyfarrell | yeah so I understand not wanting DEBUG, but that is turned off from logger.conf. |
| 22:00.13 | gtjoseph | rmudgett: make the call. |
| 22:00.24 | rmudgett | It sounds more like res_pjsip_log_forwarder isn't the best name for that module |
| 22:00.42 | rmudgett | file: or putnopvut should weigh in |
| 22:02.24 | rmudgett | res_pjsip_log_forwarder -> res_pjproject_log_forwarder so as not to confuse it with all the other res_pjsip modules |
| 22:02.49 | gtjoseph | how about res_pjproject_support? |
| 22:02.58 | gtjoseph | not just log forwarding |
| 22:03.22 | rmudgett | Yeah that is better as it allows other functionality |
| 22:03.32 | coreyfarrell | what about just plain res_pjproject? |
| 22:03.46 | gtjoseph | works for me |
| 22:03.51 | putnopvut | So here's what I'm missing what initially started this conversation. The first thing I see is " well, i suppose I could create a completely standalone module whose sole purpose is to expose pjproject data and make it load before res_pjsip, res_rtp_asterisk and res_pjsip_log_forwarder" |
| 22:03.58 | putnopvut | So I don't know what got suggested initially that led to that. |
| 22:04.16 | putnopvut | I do see gtjoseph's review |
| 22:04.45 | gtjoseph | so there are pjproject things we can only get by dumping to log... |
| 22:04.46 | rmudgett | It all started because we need to know the run time value of PJ_MAX_HOSTNAME that pjproject is using |
| 22:05.15 | gtjoseph | and we need it before res_pjproject starts processing sorcery |
| 22:05.21 | rmudgett | and dumping the log is the only way to get the value at run time |
| 22:05.47 | putnopvut | Maybe I'm dumb, but isn't PJ_MAX_HOSTNAME a symbol that you can just reference directly? |
| 22:06.03 | gtjoseph | but you get the asterisk compile time versionb |
| 22:06.16 | gtjoseph | not the actual pjproject runtime version |
| 22:06.46 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:06.57 | rmudgett | should say not the value that the pjproject you are actually using was compiled with. |
| 22:06.58 | putnopvut | So wait a second. PJ_MAX_HOSTNAME is a runtime value, but if we reference that symbol, we'll get the compile-time value? Why is that? |
| 22:07.24 | gtjoseph | no PJ_MAX_HOSTNAME is a define |
| 22:07.27 | coreyfarrell | putnopvut: PJ_MAX_HOSTNAME is a #define in pj/config.h. no symbol |
| 22:07.39 | putnopvut | So what runtime value are we talking about then? |
| 22:08.04 | coreyfarrell | the value of PJ_MAX_HOSTNAME when libpjproject.so was built |
| 22:08.15 | gtjoseph | asterisk can be compiled against 1 version of pjproject but run against another |
| 22:08.22 | rmudgett | The value of PJ_MAX_HOSTNAME compiled into the pjproject you are running with may not be the same value that Asterisk was compiled with. |
| 22:08.31 | wdoekes | you could do some pointer arithmetic on a struct that holds a PJ_MAX_HOSTNAME char-array somewhere ;) |
| 22:08.58 | rmudgett | wdoekes: Doing that will only get your compile time value. |
| 22:09.00 | gtjoseph | unfortunately that only works if you can get pjproject to return it from an api |
| 22:09.05 | gtjoseph | it doesn't |
| 22:09.11 | putnopvut | If the runtime and compile time values differ, I think you'd be up shit creek if Asterisk ever declared any arrays sized at PJ_MAX_HOSTNAME. |
| 22:09.29 | gtjoseph | we don't |
| 22:09.33 | gtjoseph | BUT... |
| 22:09.35 | putnopvut | But might we ever? |
| 22:09.39 | rmudgett | Asterisk doesn't have any that I know of |
| 22:10.10 | rmudgett | we will crash if we send a string to pjlib longer than the define size |
| 22:10.19 | rmudgett | or pjlib will crash |
| 22:10.25 | putnopvut | I'd think this could happen with any constant, and you can't be in a position where you have to assume that the compile time constant might be different from the runtime value. |
| 22:10.51 | coreyfarrell | what if we compared the value of asterisk compile time vs run-time, AST_MODULE_LOAD_DECLINE if not matching? |
| 22:11.18 | gtjoseph | no |
| 22:11.27 | gtjoseph | there are legitimate reasons it might be different |
| 22:11.45 | putnopvut | Why would it be legitimate? |
| 22:12.05 | gtjoseph | first, we can't control which versions are used in which situation |
| 22:12.22 | coreyfarrell | but we can control which versions are accepted. like an ABI check |
| 22:12.27 | gtjoseph | the default is 128 now but someone may have a legitimate reason for making it 255 |
| 22:12.42 | gtjoseph | we shouldn't prevent that |
| 22:12.49 | rmudgett | If you compiled pjproject with a -DPJ_MAX_HOSTNAME=400 in the ./configure script Asterisk will not get that value when it compiles |
| 22:13.25 | gtjoseph | also true |
| 22:14.18 | putnopvut | Why is that? Is that because Asterisk would get the value of PJ_MAX_HOSTNAME from the .h included and not from the .so where the value was defined? |
| 22:14.26 | rmudgett | The pjproject ./configure script. For asterisk to get the non-default value you have to change the pjlib/include/pj/config_site.h file to set PJ_MAX_HOSTNAME there |
| 22:17.46 | rmudgett | I'll go so far as to say that any CFLAGS define given to pjproject ./configure will not be passed to Asterisk when it compiles. |
| 22:18.22 | rmudgett | You would have to define those things in the config_site.h file |
| 22:18.26 | rmudgett | of pjproject |
| 22:20.45 | gtjoseph | so, we all up to speed? :) |
| 22:30.50 | gtjoseph | i feel like i'm waiting for white smoke or black smoke. |
| 22:32.10 | putnopvut | Yeah, I think we're up to speed, but my problem here is that in my mind, the rational fix here is don't compile Asterisk and PJProject with different values for what should be a constant. |
| 22:33.12 | gtjoseph | rational and pjproject aren't 2 things i always associate with each other |
| 22:34.34 | putnopvut | The only other thing is to make functions in pjproject (or macros, whichever) to get the constants instead of referring to the constants directly |
| 22:34.52 | gtjoseph | that's what pj_dump_config does |
| 22:35.08 | gtjoseph | except we get it in text form |
| 22:36.13 | putnopvut | Right, I was thinking a series of functions like pj_max_hostname() and pjsip_max_pkt_size(), etc. |
| 22:36.49 | gtjoseph | yep, and we should submit that request to Teluu |
| 22:37.26 | gtjoseph | in the mean time, this is the best we've got. |
| 23:45.01 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 23:45.01 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 23:57.45 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-mycysefngynaiqxm) |