| 00:01.19 | kharwell | seems like we only need 3 states. "Available" (frequency > 0 && contact responds) "Unavailable" (frequency > 0 && contact does not respond), and "Unknown" (frequence == 0) |
| 00:10.19 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-odnasejhbecnwzyw) |
| 00:11.43 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 00:23.51 | seanbright | good god |
| 00:25.17 | seanbright | so... update_all_unqualified_endpoints() calls ast_sorcery_retrieve_by_fields("aor") looking for "contact != ''" and "qualify_frequency <= 0" |
| 00:25.34 | seanbright | by default, that goes to res_sorcery_config |
| 00:26.11 | seanbright | then we build an objectset from the object to compare with those two operations |
| 00:26.39 | seanbright | but to build the 'contact' for the AOR, we call back into sorcery via ast_sip_location_retrieve_aor_contacts_nolock_filtered for each aor |
| 00:28.11 | seanbright | in my case, all endpoints register dynamically, so there will never be a contact, but 4000 times (that's the number of endpoints) we call back into sorcery to find the contacts (which i guess calls into astdb?) |
| 00:28.25 | seanbright | that takes 2-3ms per AOR |
| 00:28.36 | seanbright | so... good times |
| 00:28.45 | seanbright | that is why update_all_unqualified_endpoints() is dogshit slow |
| 00:28.54 | seanbright | and i have no idea how to fix it :-) |
| 00:37.17 | coreyfarrell | blowtorch |
| 00:49.05 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 00:53.44 | seanbright | yeah |
| 00:54.16 | seanbright | i'm not sure there is a fix, to be honest |
| 00:54.41 | seanbright | dan_j: you around? |
| 01:07.34 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 01:19.37 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:19.37 | *** 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 |
| 01:34.14 | coreyfarrell | seanbright: can you use res_sorcery_memory or res_sorcery_memory_cache for aor? |
| 01:56.11 | seanbright | i could |
| 02:12.13 | seanbright | coreyfarrell: but that defeats the point. the goal is to make it perform reasonably "out of the box" |
| 02:12.22 | seanbright | and it don't |
| 02:12.57 | coreyfarrell | seanbright: fair point. I think it's also supposed to persist restarts. |
| 02:13.02 | seanbright | correct |
| 02:13.36 | seanbright | i can improve the speed by 40% by adjusting the astdb SQL queries to not be so brain dead |
| 02:13.44 | seanbright | but i will need to test to see if that would affect anything |
| 02:13.57 | seanbright | anything outside of pjsip, that is |
| 02:14.55 | seanbright | i guess i could add to the db.c API... that's a thought |
| 02:15.51 | coreyfarrell | sometimes it's amazing how a tiny change can make such a big difference. a patch I did today made graceful restart 20% faster by switching two lines and adding a conditional to another. |
| 02:16.23 | coreyfarrell | if you can get 40% out of pjsip with the change it's worth seeing if the change can help everything else.. otherwise it's worth adding to the API. |
| 02:32.22 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 02:57.48 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 03:02.53 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 03:49.50 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 07:45.42 | *** join/#asterisk-dev jkroon (~jkroon@41.21.200.174) |
| 07:50.37 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:50.38 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:00.07 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 08:14.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:14.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:20.17 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:54.57 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:06.39 | dan_j | seanbright: i'm awake now |
| 11:03.41 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 11:04.21 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 11:05.53 | AsteriskRoss | I am currently experiencing an issue with regular TLS disconnects and this appears to be related to ASTERISK-27001. The patch was accepted upstream in the PJSIP code however since the bundled version has been updated to 2.7.1 the issue has returned. Did all of the patch included with asterisk get added to pjproject 2.7? |
| 11:27.31 | file | the patches in bundle are the precise change taken from PJSIP upstream |
| 11:45.42 | AsteriskRoss | I just compared the two and confirmed this. However Asterisk is sending a FIN packet closing the connection and I see this when looking at netstat, one connection in TIME_WAIT and the the reconnect in SYN_SENT. There are no SIP packets being exchanged before the disconnect |
| 11:46.34 | AsteriskRoss | What is the best way to debug asterisk here? |
| 11:48.58 | AsteriskRoss | Its worth saying that TCP stays connected without any issues at all |
| 11:50.36 | file | you'd likely need to look in the same area of PJSIP as before, within Asterisk we don't manage things differently between TCP or TLS |
| 12:15.00 | AsteriskRoss | Asterisk states Removed contact from AOR due to transport shutdown the question is where is the transport being shutdown. At present, correct me if I'm wrong, subscriptions persist even when the transport disconnects therefore if they are sent to the incorrect port, would the eventual timeout disconnect the active connection? But again there is no difference between TCP/TLS |
| 12:16.14 | AsteriskRoss | Side note - The CLI isn't predicting commands anymore in the latest GIT version |
| 12:19.04 | file | we receive notification that the transport is shutdown, we don't trigger it, and PJSIP doesn't terminate it as a result of a subscription timing out or call going down as the connection can be reused by tons of stuff |
| 12:20.03 | AsteriskRoss | ok, thank you. I'll try to debug pjproject further |
| 12:20.52 | file | as for the CLI thing you should file an issue, coreyfarrell did work in the CLI stuff recently and it may have caused something |
| 12:21.57 | file | I just tried under 15 branch and it was fine |
| 12:23.10 | AsteriskRoss | I'm using 13 |
| 12:24.11 | AsteriskRoss | Entering a tab with no entry doesn't show anything and if you enter pjsip <tab> still nothing |
| 12:27.14 | file | I just did a fresh 13 build and it also worked for me |
| 12:28.50 | AsteriskRoss | Its happening on multiple servers, fresh install today Asterisk GIT-13-13.15.0-rc1-845-g8e6aedb built by root on a x86_64 running Linux on 2017-12-07 05:24:54 UTC |
| 12:31.12 | file | then you'll need to open an issue and likely work with coreyfarrell to understand what is going on and what is unique to cause it |
| 12:31.47 | AsteriskRoss | ok no problem |
| 14:33.20 | seanbright | everything is always my fault |
| 14:33.37 | file | unlikely |
| 15:23.40 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 15:23.40 | *** 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 |
| 15:25.19 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 15:31.25 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qcoajskluweaqqhi) |
| 15:31.25 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:51.41 | coreyfarrell | AsteriskRoss: CLI issues with `asterisk -c` or `asterisk -r`? |
| 15:54.52 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:02.10 | coreyfarrell | AsteriskRoss: nm issue confirmed using remote only (on 13 so far). not an issue in master, waiting for a 15 build but probably an issue there. |
| 16:02.24 | coreyfarrell | AsteriskRoss: did you report the CLI thing to JIRA? |
| 16:03.04 | file | I haven't seen it come in |
| 16:03.04 | AsteriskRoss | I haven't yet I've been busy, would you like me to now? |
| 16:04.10 | coreyfarrell | AsteriskRoss: if you don't mind. BTW issue confirmed for 13 and 15 only. apparently removing the compatibility code from master fixed the issue for that branch. |
| 16:04.43 | file | neat |
| 16:09.48 | coreyfarrell | DAMNIT!! AST_VECTOR_GET_CMP strikes again. |
| 16:11.08 | AsteriskRoss | @correyfarrel - Issue ASTERISK-27465 created for the CLI issue |
| 16:11.42 | coreyfarrell | gtjoseph: do you remember why you made it so we have to negate strcmp for that function? AST_VECTOR_GET_CMP(vec, str, strcasecmp) has caused me problems multiple times. |
| 16:12.11 | coreyfarrell | AsteriskRoss: thanks. I'll have patches for review shortly. |
| 16:14.30 | gtjoseph | coreyfarrell: i'm not sure. i think i thought since it was really a boolean that was required the cmp should return a boolean instead of a -1, 0, 1. |
| 16:14.57 | gtjoseph | bu thonestly i don't remember |
| 16:26.38 | coreyfarrell | has anyone else noticed gcc not warning about uninitialized vars? just had a segfault from reading the wrong variable, dev-mode on and DONT_OPTIMIZE off but no error. |
| 16:43.11 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.166) |
| 16:51.04 | gtjoseph | coreyfarrell: yeah, I thought it was just me. |
| 16:52.13 | coreyfarrell | gtjoseph: I'm wondering if it's an issue in current (fedora) gcc.. because I've seen it happen a couple times where gerrit caught the issue (this time a segfault caught it for me). |
| 16:53.26 | coreyfarrell | in the past I assumed I just had the wrong build settings (sometimes I'll use DONT_OPTIMIZE without double compile) but this time I know that wasn't the case. |
| 16:53.40 | gtjoseph | possibly. it's be weird though given that they usually get more restrictive as time goes on. Maybe one of the -W options changed recently and we're no longer specifying it correctly. |
| 16:58.11 | coreyfarrell | I feel like -Wall -Werror should cover uninitialized variables regardless of any other options (we don't use -Wno-uninitialized) |
| 17:00.01 | gtjoseph | true |
| 17:00.44 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 17:25.30 | rmudgett | coreyfarrell: The https://gerrit.asterisk.org/#/c/7470/ patches are missing the issue in the commit message |
| 17:28.01 | coreyfarrell | rmudgett: fixed |
| 17:46.24 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00683a8500b39c865c.ipv6.abo.wanadoo.fr) |
| 18:03.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00794b74346420751b.ipv6.abo.wanadoo.fr) |
| 18:06.40 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 18:16.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f928d2db894711ff.ipv6.abo.wanadoo.fr) |
| 18:19.36 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 18:19.36 | *** 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 |
| 18:29.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0018a62a89ece1312e.ipv6.abo.wanadoo.fr) |
| 18:44.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00e05f766e9a8b65af.ipv6.abo.wanadoo.fr) |
| 18:59.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0029b9d674e7cf9548.ipv6.abo.wanadoo.fr) |
| 19:12.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d004db0b8a80d4085b2.ipv6.abo.wanadoo.fr) |
| 19:27.14 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009cc65c753e80946e.ipv6.abo.wanadoo.fr) |
| 19:39.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d000050ca579def619e.ipv6.abo.wanadoo.fr) |
| 19:54.51 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0078b4eb3722d65ea9.ipv6.abo.wanadoo.fr) |
| 20:01.41 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01cb0583d31d007c91736063c98d93.ipv6.abo.wanadoo.fr) |
| 20:18.07 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d003d57120936ee643e.ipv6.abo.wanadoo.fr) |
| 20:30.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f5edbeef3c7d94fc.ipv6.abo.wanadoo.fr) |
| 20:44.55 | seanbright | stuff in 'main' doesn't seem to be affected by make -j |
| 20:45.02 | seanbright | unless i don't understand make -j |
| 20:45.44 | seanbright | nevermind, i think i'm just wrong |
| 20:45.46 | seanbright | which happens |
| 20:46.04 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01cb0583d31d0031003c8cd2ab4c63.ipv6.abo.wanadoo.fr) |
| 20:47.23 | seanbright | huh... so i think i may have done it |
| 20:47.36 | seanbright | from 8 seconds down to 377ms |
| 20:47.43 | seanbright | which is pretty dope |
| 20:48.28 | coreyfarrell | seanbright: the source root isn't effected by make -j but all the subdirs including main are. |
| 20:48.51 | coreyfarrell | 8 seconds is that for the pjsip reload thing? |
| 20:49.11 | seanbright | yes |
| 20:49.17 | coreyfarrell | nice |
| 20:49.20 | seanbright | on my machine anyway, which is fairly new |
| 20:49.39 | seanbright | Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz |
| 20:57.46 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 20:57.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:59.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00ac9cb11d324eafbe.ipv6.abo.wanadoo.fr) |
| 21:07.33 | seanbright | kharwell: ping |
| 21:07.42 | kharwell | seanbright: hi |
| 21:07.52 | seanbright | you working on ASTERISK-26806 |
| 21:07.53 | seanbright | ? |
| 21:08.21 | kharwell | not atm |
| 21:08.23 | seanbright | k |
| 21:08.47 | kharwell | I'm am working on another problem with options reloading though |
| 21:09.01 | kharwell | doesn't have an asterisk issue yet. I need to create one I suppose |
| 21:09.49 | seanbright | well.. take https://gerrit.asterisk.org/#/c/7475/ for a spin |
| 21:09.58 | seanbright | let me know if that improves your life at all |
| 21:10.44 | kharwell | okay I'll try to set up something and see what happens |
| 21:11.34 | seanbright | no rush |
| 21:13.51 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a9dd1e098a26e182.ipv6.abo.wanadoo.fr) |
| 21:26.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0091b8b3e6b9a4b193.ipv6.abo.wanadoo.fr) |
| 21:40.02 | kharwell | seanbright: with your changes and running the scenario described on the issue, but adding a static contact for the 3K aors, I'm currently over 3 minutes on load. Asterisk appears hung up, but it's it's processing and my cpus are pretty much pegged |
| 21:40.37 | kharwell | ooo I'm getting task processor queue limit messages now |
| 22:01.08 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 22:01.08 | *** 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 |
| 22:04.20 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d002dff8887dec91bf2.ipv6.abo.wanadoo.fr) |
| 22:09.07 | seanbright | ok, confirmed |
| 22:09.26 | seanbright | before my patch 'update_all_unqualified_endpoints' takes 9 seconds |
| 22:09.34 | seanbright | after, 400ms |
| 22:09.54 | seanbright | all of those are dead registrations though |
| 22:10.01 | seanbright | so i will need to figure out the live ones next |
| 22:14.10 | seanbright | coreyfarrell: i know you like patching things, so here's a thought... |
| 22:14.35 | seanbright | in dev-mode, have the "Asterisk Ready" message that prints out to the console include the total time that boot took |
| 22:14.41 | seanbright | annnnnd GO |
| 22:15.22 | seanbright | actually, that would be useful for each module load as well... |
| 22:15.28 | seanbright | anyway... if you're bored :D |
| 22:16.44 | seanbright | (nanosecond resolution would be ideal) |
| 22:18.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0031f40d748622e85a.ipv6.abo.wanadoo.fr) |
| 22:33.58 | coreyfarrell | seanbright: the total boot time thing sounds like it could be useful but if ns are significant then isn't startup fast enough? |
| 22:34.30 | seanbright | coreyfarrell: for total boot time, nanos might be overkill |
| 22:34.54 | seanbright | and what does "fast enough" mean :) |
| 22:34.54 | coreyfarrell | ah you were talking per module ns? |
| 22:34.58 | seanbright | yes |
| 22:35.18 | seanbright | i consider 0 "fast enough" |
| 22:36.16 | coreyfarrell | if the total startup time rounds to 0ms I consider it fast enough. |
| 22:36.30 | seanbright | yes. |
| 22:36.34 | seanbright | we can never get there |
| 22:36.39 | seanbright | but it's a nice goal |
| 22:36.52 | seanbright | on my VM i'm down to 200ms or so with 13 |
| 22:37.07 | seanbright | and only lightly configured |
| 22:37.17 | coreyfarrell | is that with xmldoc disable? |
| 22:37.55 | seanbright | ah, you're right. i am adding up module loads but not taking asterisk itself into account. |
| 22:38.31 | seanbright | i can do 'service asterisk start' and then 'asterisk -r' |
| 22:38.38 | seanbright | and i don't see any output |
| 22:38.44 | seanbright | which is better |
| 22:39.02 | seanbright | so however long it takes me to type 'asterisk -r<enter>' |
| 22:40.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0025d088b7cf81c8dc.ipv6.abo.wanadoo.fr) |
| 22:42.07 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 22:42.07 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zegyvjhshbuiapbg) |
| 22:42.07 | *** join/#asterisk-dev file (uid178970@asterisk/developer-and-muffin-lover/file) |
| 22:42.07 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/dadrc) |
| 22:42.07 | *** mode/#asterisk-dev [+oo kharwell file] by livingstone.freenode.net |
| 22:42.54 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:42.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:45.47 | coreyfarrell | seanbright: what if you run asterisk;asterisk -r? does it listen for remote consoles fast enough after fork so asterisk -r succeeds? |
| 22:46.45 | seanbright | no |
| 22:46.52 | seanbright | we'll need to fix that |
| 22:46.53 | seanbright | heh |
| 22:48.54 | coreyfarrell | module loader is the area I'm currently working on. in theory it could (eventually) allow the module loader to use multiple threads during startup. |
| 22:50.25 | seanbright | that'd be sexy |
| 22:50.40 | seanbright | how would that work with all of the optional api mumbo jumbo? |
| 22:53.07 | coreyfarrell | the optional api module will be forced to load before any module that uses it - assuming the optional api module is being loaded at all. |
| 22:53.23 | coreyfarrell | and the module loader would prevent the optional api from being unloaded before a module that uses it. |
| 22:54.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00403411305a90fa35.ipv6.abo.wanadoo.fr) |
| 22:58.50 | seanbright | asterisk;asterisk -r |
| 22:59.14 | seanbright | takes about 160ms on my machine to get the listener set up |
| 22:59.41 | seanbright | is going home. night night. |
| 23:00.13 | coreyfarrell | seanbright: we could probably move ast_makesocket earlier in startup but that could be trouble. |
| 23:00.18 | coreyfarrell | have a good one. |
| 23:07.47 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0030043d1e0791b2a1.ipv6.abo.wanadoo.fr) |
| 23:22.48 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0050756509e44f378f.ipv6.abo.wanadoo.fr) |
| 23:35.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0008094adebaafe80b.ipv6.abo.wanadoo.fr) |
| 23:50.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00cdd042322606e3a3.ipv6.abo.wanadoo.fr) |
| 23:53.00 | coreyfarrell | gtjoseph: are you still around? |
| 23:53.05 | gtjoseph | yep |
| 23:53.42 | coreyfarrell | could you tell me how res_pjsip_config_wizard fits into the big picture? |
| 23:54.05 | gtjoseph | sure... |
| 23:54.42 | coreyfarrell | I see it exports globals just for the sake of loading early? |
| 23:54.56 | gtjoseph | oh at that level. :) |
| 23:55.13 | gtjoseph | now i have to look at the code |
| 23:55.29 | coreyfarrell | oh sorry. I know it's late if you don't feel like looking now I understand |
| 23:55.48 | gtjoseph | nope, i'm in front if it gimme a sec |
| 23:56.31 | coreyfarrell | I see that it uses 1 symbol from res_pjsip, it doesn't actually export any symbols of it's own. |
| 23:56.34 | gtjoseph | ok, globals... |
| 23:57.37 | coreyfarrell | I'm trying to understand where it is meant to fit in with the load order. |
| 23:58.34 | gtjoseph | yeah, the wizard has to load before res_pjsip, ir any other of the modules it provides configs for, so outbound_registration, endpoint_identify, etc. |
| 23:59.28 | gtjoseph | this way when those modules register their types, the wizard gets notified and inserts itself as a "sorcery wizard" |