| 00:21.56 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:21.56 | *** 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 |
| 00:29.04 | *** join/#asterisk-dev scgm11_ (~scgm11@76.14.13.82) |
| 01:03.57 | *** join/#asterisk-dev scgm11_ (~scgm11@76.14.13.82) |
| 06:46.37 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:51.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:15.16 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:24.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.37) |
| 07:50.47 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:24.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 11:01.36 | *** join/#asterisk-dev newtonr (~newtonr@2602:306:3688:1880:e052:7dd1:4a51:321b) |
| 11:01.36 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 11:04.59 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:34.32 | *** join/#asterisk-dev newtonr_ (~newtonr@99-104-129-136.lightspeed.brhmal.sbcglobal.net) |
| 11:34.32 | *** mode/#asterisk-dev [+o newtonr_] by ChanServ |
| 11:46.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@mail2.cloud-bretagne.com) |
| 11:52.43 | *** join/#asterisk-dev newtonr (~newtonr@99-104-129-136.lightspeed.brhmal.sbcglobal.net) |
| 11:52.43 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 11:56.22 | *** join/#asterisk-dev oej (~oej@81-235-185-50-no207.tbcn.telia.com) |
| 11:56.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:32.03 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:34.11 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:34.11 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:59.06 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zaduhbaqbeqryeuk) |
| 13:59.06 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:03.03 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:03.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.45 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-cmbtckxlijumyvse) |
| 14:46.45 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:03.33 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:09.37 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.6.104) |
| 15:12.44 | seanbright | file: question |
| 15:13.30 | seanbright | as we've discussed previously, res_rtp_multicast used in an originate without an explicit codec parameter is useless |
| 15:13.47 | seanbright | because slinear does not map well to any of the static RTP payload assignments |
| 15:14.06 | file | oui monsieur |
| 15:14.21 | seanbright | how would i go about telling chan_rtp that it should prefer ulaw, g722, alaw, etc. over slinear? |
| 15:14.33 | seanbright | is that the ast_channel_tech.capabilities member? |
| 15:14.59 | file | not really, in the _request callback it decides on the format |
| 15:15.21 | file | you'd want to add logic there |
| 15:15.59 | seanbright | gotcha |
| 15:16.10 | seanbright | so rather than defaulting to: |
| 15:16.11 | seanbright | ast_format_cap_get_format(cap, 0); |
| 15:16.15 | seanbright | do some magic |
| 15:17.03 | file | so! cap is the requested formats from whatever is requesting the channel |
| 15:17.40 | seanbright | in the case of an originate that would be slin and slin only it seems |
| 15:17.52 | file | yeah, so you can do a check and if it's a slin then default to something else |
| 15:18.00 | file | that'd allow other requested formats to work |
| 15:18.11 | seanbright | got it |
| 15:18.14 | seanbright | alrighty |
| 15:21.44 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-248-133.hsd1.co.comcast.net) |
| 15:24.17 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-chwyipicrlhmpmwf) |
| 15:25.13 | jameswf | if asterisk crashes on module load res_ari_endpoints.so might it be from a missing dependency? |
| 15:25.40 | jameswf | note this only seems to be an arm issue |
| 15:25.57 | file | it is possible, depends on how it behaves |
| 15:26.15 | seanbright | what's wrong with your arm? |
| 15:26.20 | file | well - not crash, but symbol resolution |
| 15:27.20 | jameswf | so on the raspi asterisk goes in to a death loop. if I noload res_ari it does not. When I go in to the CLI ans module load res_ari still happy. If I module load res_ari_endpoints BOOM goes the dynamite |
| 15:27.54 | jameswf | note asterisk restarts because of safe_asterisk |
| 15:28.29 | file | https://issues.asterisk.org/jira/browse/ASTERISK-27026 |
| 15:28.32 | file | :P |
| 15:29.54 | jameswf | yeah we told him to do that. He basically said it is our problem so we should fix it but didn't provide core dumps etc.... so I went through and regrettibly setup a raspi |
| 15:30.28 | file | I set up a raspi last night with stock samples and it was fine |
| 15:31.01 | file | there's also https://issues.asterisk.org/jira/browse/ASTERISK-27030 |
| 15:31.19 | file | so it's not strictly raspi, but something in the environment |
| 15:33.39 | jameswf | file: that was the clue I think |
| 15:34.48 | jameswf | file: no ari.conf BOOM |
| 15:35.04 | jameswf | touch ari.conf.... happy |
| 15:35.38 | file | voila |
| 15:38.54 | jameswf | commented on that tocket... 27026 |
| 15:39.18 | jameswf | I wish """DEVELOPERS""" could I dunno do their own basic troubleshooting |
| 15:43.37 | file | finishes paperwork |
| 15:52.35 | coreyfarrell | seanbright: about the pbx builtin review sorry for the noise. I already switched to +1. |
| 15:55.07 | file | rmudgett: https://issues.asterisk.org/jira/browse/ASTERISK-27023?filter=12936 didn't you do something there in your great 14 locking insanity change? |
| 15:56.54 | rmudgett | file: yes. That deadlock may no longer exist. |
| 15:57.13 | rmudgett | It would certainly be different now. |
| 15:57.21 | file | 'tis filed against 13 |
| 15:57.46 | rmudgett | The locking stuff went in 13.16.0 |
| 15:57.58 | file | oh yes |
| 15:58.01 | file | I was too far back in time |
| 15:58.49 | rmudgett | I suppose I should comment that it is likely fixed by whatever the other issue was. |
| 15:59.05 | file | triage it then, kthx |
| 16:14.13 | *** join/#asterisk-dev oej (~oej@h-205-12.a165.corp.bahnhof.se) |
| 16:14.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:45.22 | seanbright | coreyfarrell: no sweat, i saw that. |
| 17:08.40 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 17:08.40 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 17:09.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:10.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:15.07 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:26.55 | *** join/#asterisk-dev scgm11_ (~scgm11@76.14.13.82) |
| 18:06.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0055164de6f2842cde.ipv6.abo.wanadoo.fr) |
| 18:13.26 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@172.56.6.11) |
| 19:20.03 | *** join/#asterisk-dev scgm11_ (~scgm11@76.14.13.82) |
| 20:15.30 | *** join/#asterisk-dev oej (~oej@h-205-12.a165.corp.bahnhof.se) |
| 20:15.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:20.18 | seanbright | so... my smoother flags review |
| 21:20.25 | seanbright | it seems it is being avoided |
| 21:20.35 | seanbright | can i answer any questions about it? |
| 21:21.08 | gtjoseph | i think it's just big enough to warrant more scrutiny. |
| 21:21.12 | seanbright | got it |
| 21:21.32 | gtjoseph | besides, you only restored it yesterday. :) |
| 21:21.38 | seanbright | good point |
| 23:01.16 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-zaduhbaqbeqryeuk) |
| 23:04.38 | *** join/#asterisk-dev scgm11_ (scgm11@nat/google/x-yqydziitiasdnzwu) |