IRC log for #asterisk-dev on 20181108

03:37.21*** join/#asterisk-dev infobot (ibot@208.53.50.136)
03:37.21*** 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
07:20.29*** join/#asterisk-dev tsearle (~tsearle@37.19.10.33)
07:20.29*** mode/#asterisk-dev [+o tsearle] by ChanServ
07:28.36*** join/#asterisk-dev pchero_work (~pchero@87.213.240.121)
08:10.41*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
08:10.47*** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74)
09:34.34*** join/#asterisk-dev pchero_work (~pchero@60.30.148.146.bc.googleusercontent.com)
10:04.06*** join/#asterisk-dev jkroon (~jkroon@165.16.203.52)
11:41.04coreyfarrell<rant>I hate the CHANGES/UPGRADE.txt files</rant>
12:36.47*** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca)
13:49.33*** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-icthrzktlxtolttt)
13:49.33*** mode/#asterisk-dev [+o bford] by ChanServ
14:02.43*** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie)
14:02.59*** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj)
14:03.31*** mode/#asterisk-dev [+o gtjoseph] by ChanServ
14:03.49*** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage)
14:04.02*** mode/#asterisk-dev [+o leifmadsen] by ChanServ
14:05.06*** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74)
14:13.15seanbrightmaybe they should be moved to the wiki
14:16.58tsearleI think I'm missing something ref pjsip design...
14:17.42tsearleI change the pjsip_module priority to  PJSIP_MOD_PRIORITY_UA_PROXY_LAYER +1 in the nat module because then according to the docs I can get the dialog object
14:18.16tsearlebut when I do that, I see that it's no longer getting called for received responses anymore
14:19.17tsearlethe response handlers have a return type of void, so I don't see how processing of handlers could end early, e.g. before my handler gets reached...
14:19.55seanbrighti've never found relative module priorities to be useful
14:20.01seanbrightis not being helpful
14:21.15tsearlewell right now I think why the MWI tests fail is that nat gets called at 2 layers, first at psjp_module before dialog is found where it can try to mangle messages before dialogs are create
14:21.26tsearleand later via ast_sip_session_supplement
14:21.49tsearlewere it can fix dialogs (if they were not already fixed by the message mangling)
14:22.07tsearlething is ast_sip_session_supplement handlers don't seem to get used for pubsub dialogs
14:22.30tsearleso I'm trying to go middlle road
14:22.37tsearlenuke the ast_sip_session_supplement
14:23.08tsearleand have the pjsip_module handlers get called at a time after the dialog layer has done its stuff
14:25.37tsearleModule should return PJ_TRUE if it handles the response, or otherwise it should return PJ_FALSE to allow other modules to handle the response.
14:25.41tsearleok.....
14:25.42fileSIP sessions are for sessions which are calls
14:26.08filethus why pubsub doesn't use that stuff
14:26.15tsearleI appreciate that
14:26.24tsearlebut nat magic is for sip dialogs in general
14:26.40filesure, just clarifying why it is the case
14:27.16tsearlebut taht's why mwi is breaking when decide to wait for rr in dialog object
15:13.01tsearlestatic struct ast_sip_session_supplement websocket_supplement = {
15:13.23tsearleI'm guessing pubsub over websocket is broken too
15:13.36tsearleas it's also depending on session
15:14.18fileit also has a pjsip_module
15:14.29filewhich is invoked straight off the transport
15:14.54tsearlenot quite.... it's armed                 pjsip_dlg_add_usage(session->inv_session->dlg, &websocket_module, NULL);
15:14.57fileor close to it, at least
15:15.02fileright
15:15.04fileit uses both.
15:15.21tsearlebut looking at that
15:15.33tsearlebecause as far as I can see, pjsip_dlg_add_usage
15:15.41tsearlewill be the only way to get responses with a dialog
15:15.54fileyes, due to the way that PJSIP does things
15:15.56tsearleand so far I'm seeing nothing to allow me to arm that in pubsub
15:16.45tsearlefeel like I need to add an on_rx_request method to res_pjsip_pubsub
15:16.58tsearleand then have *_nat arm both session and pubsub
15:22.59tsearlewould that be reasonable?
15:24.52fileat face value yes, but there's a lot of demons and gotchas in there
15:25.06tsearleindeed
15:25.21tsearlethis whole this is like walking on eggshells
15:27.51*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-zypnvvvkwzrtewyx)
15:27.51*** mode/#asterisk-dev [+o rmudgett] by ChanServ
15:33.33gtjosephdoes anyone remember...  did we determine that basename() was not safe to use for portability reasons?
15:34.25fileI vaguely recall kharwell doing something in that area years ago?
15:37.38*** join/#asterisk-dev kharwell (kharwell@nat/digium/x-iegdazggjomeeilg)
15:37.38*** mode/#asterisk-dev [+o kharwell] by ChanServ
15:39.57gtjosephkharwell...    did we determine that basename() was not safe to use for portability reasons?
15:40.45gtjosephdoes that ring a bell?
15:41.10kharwellI don't recall, no. But seems like it would be fine.
15:41.39gtjosephmaybe it was a freebsd thing
15:41.48kharwellThere was the readdir stuff and other calls associated with it I think that were not as portable that we tried to wrap
15:41.49gtjosephah well, nevermind.
15:41.50coreyfarrellgtjoseph: man 3 basename says that POSIX modifies the argument, GNU version does not.
15:42.15gtjosephyeah and I forced the GNU version for that reason but i think to be safe i'm just not going to use it.
15:42.42coreyfarrellor use it on an ast_strdupa
15:43.14gtjosephyeah it's not worth it.  it's easy enough to just use strrchr
15:45.31tsearlebah, too much work, think I'll just skip dialog checks for pubsub restoring mwi to it's original condition
15:45.52seanbrightcan filenames have slashes in them?
15:46.12*** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n)
15:46.12*** mode/#asterisk-dev [+o cresl1n] by ChanServ
15:46.21tsearle<PROTECTED>
15:46.21tsearletouch: cannot touch 'x/y': No such file or directory
15:46.49tsearlelooks like they cant
15:46.54seanbright👍
15:47.03gtjosephyeah, you can't escape or literal it.
15:48.50seanbrightlol -> https://github.com/lattera/glibc/blob/master/string/basename.c
15:49.04seanbrightpretty straight forward
15:50.25seanbrightthat's a shitty mirror, but it's the same as the sourceware.org version
15:53.17seanbrightoh, but the behavior is different
15:53.59seanbright/home/foo and /home/foo/ return different things. the posix version will always return 'foo' whereas the gnu version will return either '' or 'foo' depending on if the slash is there
15:54.03seanbrightinteresting
15:54.28gtjosephwell, in my case, they're always file names.
15:54.34seanbrightwhich is why the posix version eeds to be able to modify the string
15:54.44fileis named
15:54.51seanbrightthe more you know™
16:01.14*** join/#asterisk-dev dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82)
16:26.21*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
17:24.21*** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74)
18:51.23*** join/#asterisk-dev CELYA_ (~Thunderbi@lfbn-1-5361-63.w90-105.abo.wanadoo.fr)
19:13.30*** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl)
19:41.13kharwellso finally was able to capture a backtrace for the ast_restart test. here's the interesting threads: https://pastebin.com/a0VUMy68
19:41.30kharwellIt does appear the system is holding things up
19:42.12kharwelland the problem only seemed to manifest when other containers were processing (gating, checking..)
19:42.12fileyup yup, fsync
19:42.33kharwellthat was with debug_thread off too btw
19:44.30kharwellgtjoseph: do you think adding in those new drives will help?
19:44.57gtjosephi think it will but there's only 1 way to tell.
19:45.10kharwellyeah
19:45.56kharwellI think I've gotten as far as I can so whenever you're ready to include those drives go ahead
19:48.51gtjosephcool.  will do tonight
19:59.08*** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-tdniuwjdjixyrcsq)
19:59.08*** mode/#asterisk-dev [+o tm1000] by ChanServ
19:59.32tm1000"sleepycat"
19:59.35tm1000who thinks of these names.
19:59.52tm1000Asterisk 17 'sluggishsnail"
20:21.13*** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca)
20:22.28*** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca)
20:24.28*** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca)
20:27.40cresl1nGood find kharwell!
20:28.33coreyfarrellkharwell: so do you think the pjproject-2.8 testing issues are resolved?  maybe we'll see after the drives are upgraded?
20:29.03kharwellthere are some good times to be had in the testsuite
20:29.50kharwellcoreyfarrell: I'm not sure. There is still at least one test, another chanspy test, that is being looked into that may also be failing due to the pjsua stuff
20:30.29kharwellcsavinovich: is currently investigating.
20:30.58kharwellthat's the last one I know about that  might be a problem.
20:31.24kharwellI don't think any others have been specifically tied to the 2.8 upgrade (at least that I am aware of)
20:48.36cresl1ngtjoseph: where are we on https://gerrit.asterisk.org/#/c/asterisk/+/10227/
20:48.55gtjosephit's next on my list to finish up.
20:48.59cresl1nYou probably told me and I forgot
20:49.03cresl1nCool
20:49.12cresl1nDoing some spring cleaning on gerrit
20:49.18cresl1nthankfully there wasn't too much to do
22:16.34csavinovich2:30 PM <@kharwell> csavinovich: is currently investigating.
22:16.34csavinovichThat's right, I will get it fixed pretty soon
23:41.57*** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-aorhoxbatwiuuoqj)
23:41.57*** mode/#asterisk-dev [+o bford] by ChanServ
23:58.13*** part/#asterisk-dev kharwell (kharwell@nat/digium/x-iegdazggjomeeilg)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.