| 00:00.05 | coreyfarrell | gtjoseph: why no lock for AST_RWVECTOR_SIZE? also didn't realize I was asking for the CALLBACK_DATA macro's to go away, that's cool. |
| 00:00.30 | gtjoseph | it's an atomic call (practically) |
| 00:00.41 | gtjoseph | although... |
| 00:01.10 | coreyfarrell | if the member that held size was volatile it would be |
| 00:01.36 | gtjoseph | hmmm, yeah true. i'll add it |
| 00:01.45 | coreyfarrell | add the lock right? |
| 00:01.51 | gtjoseph | correct |
| 00:01.54 | coreyfarrell | cool |
| 00:23.25 | gtjoseph | coreyfarrell: did you find anything else? |
| 00:24.33 | coreyfarrell | oh tweak the commit msg for about the CALLBACK functions |
| 00:24.43 | gtjoseph | wilco |
| 00:25.01 | coreyfarrell | maybe mention creation of the test.. |
| 00:25.04 | coreyfarrell | that's it :) |
| 00:25.17 | gtjoseph | creation of test? |
| 00:25.19 | coreyfarrell | oh sorry I see the added unit test, never mind |
| 00:25.26 | gtjoseph | :) |
| 00:33.01 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:33.01 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:05.53 | *** join/#asterisk-dev dant (~dant@180.190.49.237) |
| 01:07.05 | snuff-work | mm... |
| 01:07.28 | snuff-work | when u reload pjsip.. it doesn't seem to show the 'errors' on loading config |
| 01:14.38 | gtjoseph | snuff-work: it should. what are you looking for specifically? |
| 01:15.06 | snuff-work | so when i 1st start * i got msg the i'd missed a 't' of trust_rpid |
| 01:15.25 | snuff-work | when i reloaded via 'pjsip reload res_pjsip |
| 01:15.41 | snuff-work | it just displayed notices.. no errors of config |
| 01:15.56 | gtjoseph | probably because it didn't lead the forst time |
| 01:16.00 | gtjoseph | let me try |
| 01:16.43 | snuff-work | mm.. that time it gave error.. after i made it 'incorrect' again |
| 01:17.03 | snuff-work | then if i reload again.. and the value is still incorrect.. i get no warning msg |
| 01:20.31 | gtjoseph | yeah, that's expected. on reload if nothing changed, you don't get any new errors |
| 01:21.32 | snuff-work | mm.. i'd kind of like it to say on a 'reload' that something is wrong still.. maybe just me.. |
| 01:21.51 | snuff-work | if i change the 'wrong' value to another 'wrong' value it does pick it up |
| 01:22.34 | snuff-work | tries to remember if older ast_sip does a similar thing.. i think it constantly reports error on config reload.. |
| 01:22.35 | gtjoseph | might not be too easy to change. it's wrapped up in the sorcery config stuff. |
| 01:24.28 | snuff-work | ah thought might be the case.. |
| 01:25.15 | snuff-work | what is the cmd to show what levl of verb/debug u have |
| 01:27.11 | gtjoseph | core show settings |
| 01:35.59 | snuff-work | =) |
| 01:40.21 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 02:01.53 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-rkyqsjfzlvqhqskn) |
| 02:01.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:05.44 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 04:05.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:10.24 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-wtjtafckealtniml) |
| 06:48.41 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:05.39 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:6017:9389:2b14:974a) |
| 07:05.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:16.43 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:16.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:21.04 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 10:30.53 | *** join/#asterisk-dev dant (~dant@180.190.62.187) |
| 10:37.48 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:6017:9389:2b14:974a) |
| 10:37.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:06.17 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 12:29.00 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:30.50 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-zqmekxwdldfnxupi) |
| 12:50.48 | file | mjordan, moo |
| 12:50.56 | mjordan | indeed. |
| 12:51.03 | file | mjordan, https://gerrit.asterisk.org/#/c/345/ |
| 12:51.05 | mjordan | And now I shalt disappear, so that I might partake in the morning commute. |
| 12:51.09 | file | FINE |
| 12:51.22 | mjordan | file: what about it? |
| 12:51.32 | mjordan | ah |
| 12:51.35 | mjordan | he cherry-picked it |
| 12:51.40 | file | mjordan, yeah into 11 |
| 12:51.46 | mjordan | hum. |
| 12:51.53 | mjordan | arguably, it is a bug. |
| 12:52.18 | mjordan | but I am open to objections and/or condemnations |
| 12:53.13 | mjordan | traipses off to work |
| 12:54.32 | [TK]D-Fender | condemns mjordan |
| 12:54.47 | [TK]D-Fender | sets up a security fence |
| 12:55.46 | [TK]D-Fender | places ANFO, packs in the det-cord and wires back to a reinforced trailer |
| 12:55.59 | [TK]D-Fender | *b00m* |
| 12:56.33 | [TK]D-Fender | places "Land for Sale" sign over the rubble |
| 13:15.03 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-trwisanylswvwckd) |
| 13:31.31 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-gzqymqyjaqxqohrw) |
| 13:33.06 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-exkckxcqrtylxwxh) |
| 13:33.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:43.58 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:43.58 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:53.51 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:14.53 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:15.57 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-afiycqbhlofzwnbn) |
| 14:19.25 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:41.26 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-yhlsjotrflolzqmd) |
| 14:41.48 | file | rmudgett, hi |
| 14:44.40 | rmudgett | file hi |
| 14:45.13 | file | rmudgett, is there a reason why the dial masquerade datastore persists on the caller channel after answer? |
| 14:46.01 | rmudgett | idk |
| 14:46.25 | file | my best hope! |
| 14:48.59 | mjordan | file: is the dial masquerade datastore used by ARI/Stasis at all?' |
| 14:49.22 | file | mjordan, don't think so - it's used to publish dial events |
| 14:49.28 | mjordan | ugh. |
| 14:49.35 | mjordan | The code in stasis channels. Oi. |
| 14:49.38 | file | so if something gets masqueraded around the dial events reflect that |
| 14:49.48 | rmudgett | Is this the datastore that mark recently put channel refs in? |
| 14:49.51 | file | rmudgett, yes |
| 14:50.08 | file | rmudgett, the ref to the caller is now making it so the caller channel never gets destroyed |
| 14:50.45 | mjordan | I can't see why we would need it post-answer. |
| 14:50.53 | file | mjordan, I can't either |
| 14:51.09 | mjordan | looking at rmudgett's commit (c61b66e1), it's pretty clear that we're dealing with the lack of the early bridge (I know rmudgett, I know) |
| 14:51.22 | mjordan | once you've answered, all events had to have fired |
| 14:51.35 | mjordan | so even if you're masqueraded between the answer and entering the bridge, that datastore shouldn't care. |
| 14:51.46 | mjordan | In fact, whoever raises the final event should probably just nuke the datastore off the channel |
| 14:52.04 | mjordan | hm. Which it does attempt to do, only on the peer |
| 14:52.22 | file | correct |
| 14:52.28 | file | that works |
| 14:52.31 | mjordan | file: ah |
| 14:52.37 | mjordan | it would be hard to know when to remove it on the caller |
| 14:52.46 | mjordan | because in a parallel dial, you don't know if there are any others floating around. |
| 14:53.57 | mjordan | you can't remove the datastore on the caller channel completely until all of its dial operations have completed successfully. Right now, all it attempts to do is remove the peer off the list in the datastore. |
| 14:53.58 | file | mjordan, should be able to know - the datastore has a list |
| 14:54.11 | mjordan | file: true, if the list length is 0, you should be able to remove it from the caller |
| 14:54.15 | file | yeah |
| 14:54.29 | mjordan | whether or not that would fix the crash is unknown... |
| 14:54.33 | mjordan | when does the crash happen? |
| 14:54.45 | file | the original reported crash? |
| 14:54.48 | mjordan | yeah |
| 14:54.52 | file | in a bridge |
| 14:54.57 | mjordan | ah |
| 14:54.59 | file | thus my original question |
| 14:55.09 | mjordan | yeah, it should be completely gone by that point |
| 15:00.00 | file | so that makes me wonder whether it would even be possible for the channels to go away then |
| 15:23.38 | *** join/#asterisk-dev jrose_atDigium (jrose_atDi@nat/digium/x-boillkydlrvhfngt) |
| 15:42.41 | file | zoom zoom zoom |
| 15:43.07 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:50.13 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-xgfyckqvhyjrlwql) |
| 15:53.37 | file | well, that works |
| 16:44.23 | mjordan | yay? |
| 16:45.39 | file | that is the correct response |
| 17:01.11 | file | aw heck |
| 17:05.30 | file | I think? I fixed it? |
| 17:29.22 | *** join/#asterisk-dev angler (angler@pdpc/sponsor/digium/angler) |
| 17:43.06 | *** join/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 17:43.06 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:05.13 | coreyfarrell | mjordan: I cherry-picked the test registration test to 13, it doesn't apply cleanly to 11. rewrite for 11 or don't bother? it's not like a ton of new tests/changes are going to hit 11. |
| 18:05.16 | *** join/#asterisk-dev roramirez (~rodrigo@186-78-14-65.baf.movistar.cl) |
| 18:21.04 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 18:21.04 | *** 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 |
| 18:33.58 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 18:38.36 | mjordan | coreyfarrell: I'm fine if it is 13+ |
| 18:41.08 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:50.43 | roramirez | hello |
| 18:51.02 | roramirez | mjordan: i have a question about the a review |
| 18:51.24 | mjordan | roramirez: ask away - I'm about to head over to a meeting, but I'll answer when I come back |
| 18:51.28 | mjordan | (or someone else will!) |
| 18:55.14 | roramirez | the point is the best way for add support to schema cel/cel_pgsql.c. I have a review https://gerrit.asterisk.org/#/c/120/. Initialy was a port commit 2d60b755. after interaction on review i thing would be better add schema parameter on configuration files instead add this feature on the name of table. |
| 19:22.22 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-elippoeoafuwfegf) |
| 19:25.06 | *** join/#asterisk-dev outtolunc (me@c-67-170-214-55.hsd1.ca.comcast.net) |
| 20:01.32 | *** join/#asterisk-dev kasanop (~kasanop@ivanpoddubny.com) |
| 20:34.44 | mjordan | roramirez: I don't disagree. Making it configuration driven would potentially be better. |
| 20:35.15 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-afgrehnnacbsewnt) |
| 20:35.42 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:30a4:2d86:4408:1eaa) |
| 20:43.57 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 20:48.27 | roramirez | ok mjordan: i'll do it for cel_pgsql. After this, I also think it would be good to apply this change to cdr_pgsql. |
| 20:49.05 | mjordan | roramirez: as long as it is in master only, I'm not against it. |
| 20:49.59 | roramirez | the problem is backward compatibility |
| 20:50.22 | roramirez | beacuse in the table name for cdr_pgsql accept table=public.cdr |
| 20:54.36 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:54.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:55.24 | kharwell | if a particular audiohook direction is muted would it be fine/make sense to not write the frames to the associated slin [read/write]_factory? |
| 21:00.41 | mjordan | kharwell: unsure. Where exactly are you looking at? |
| 21:00.49 | file | also - define muted |
| 21:01.10 | kharwell | audiohook.c in ast_audiohook_write_frame |
| 21:01.53 | kharwell | there is a muteme flag that may get set. I was going to use this to keep frame from being written to the slin factory |
| 21:02.21 | kharwell | if they did not need to be. For instance in the case of write only ("out") then the read_factory can be muted |
| 21:03.56 | kharwell | but muteme currently only clears the frame. I was going to add an if (!muteme) right before the ast_slinfactory_feed method call |
| 21:04.41 | kharwell | I figured if it was explicitly muted then there is not need to write the frame to the slin factory |
| 21:04.57 | kharwell | *no |
| 21:06.53 | kharwell | file: muted in this case currently means just clear the frame. I want it to also mean don't add the frame to the associated slin factory |
| 21:07.24 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:10.18 | file | ah |
| 21:23.06 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:23.06 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:29.00 | leifmadsen | mjordan, ping? |
| 21:51.10 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 21:57.53 | mjordan | leifmadsen: pong |
| 22:29.06 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-exkckxcqrtylxwxh) |
| 22:46.51 | *** join/#asterisk-dev roramirez (~rodrigo@186-78-14-65.baf.movistar.cl) |
| 22:47.12 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 22:54.39 | *** join/#asterisk-dev roramirez (~rodrigo@186-78-14-65.baf.movistar.cl) |
| 23:05.15 | *** join/#asterisk-dev roramirez (~rodrigo@186-78-14-65.baf.movistar.cl) |
| 23:08.18 | *** part/#asterisk-dev roramirez (~rodrigo@186-78-14-65.baf.movistar.cl) |
| 23:08.51 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 23:21.30 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-afiycqbhlofzwnbn) |
| 23:39.18 | *** join/#asterisk-dev dant (~dant@120.28.153.231) |