| 00:21.56 | *** join/#asterisk-dev leedm777 (~textual@216.186.181.138) |
| 00:47.13 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 01:10.31 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:24.58 | *** join/#asterisk-dev leedm777 (~textual@50-81-28-152.client.mchsi.com) |
| 05:03.00 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 05:47.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0078997eced866392c.ipv6.abo.wanadoo.fr) |
| 06:00.38 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:05.33 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:10.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:10.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:35.27 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:18.45 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.182.47) |
| 09:20.20 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 11:09.57 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 12:47.17 | gtjoseph | i'm keeping my fingers crossed but i think between fixing add_peer_mailboxes and add_peer_mwi_subs the chan_sip issue is resolved. |
| 12:57.10 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rtrglrrscyxsxeme) |
| 13:27.24 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:28.59 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:28.59 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:30.59 | file | cresl1n, ahhhhhhhhh! |
| 13:31.01 | file | gtjoseph, you wish |
| 13:31.24 | gtjoseph | i know. tracking down ref leaks now. :) |
| 13:32.41 | cresl1n | hey! |
| 13:33.02 | file | pours cheese on cresl1n |
| 13:33.19 | cresl1n | not the cheese! |
| 13:33.41 | file | cresl1n, Taco? |
| 13:35.13 | cresl1n | not today |
| 13:48.28 | file | hum |
| 13:51.20 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pyifhedvjtwxhioa) |
| 13:55.35 | cresl1n | Looks like gtjoseph beat me to the CLI fix review |
| 13:55.44 | gtjoseph | :) |
| 13:56.13 | file | cresl1n, the options that are deprecated for odbc are now removed from the sample config |
| 13:56.51 | file | I'm pondering how to... mention... stuff... |
| 13:56.57 | cresl1n | excellent |
| 13:57.00 | cresl1n | which stuff? |
| 13:57.13 | file | that deprecation happened in between 13 releases |
| 13:57.19 | file | but there's no mention of it in 14 |
| 13:57.26 | cresl1n | ah |
| 13:57.41 | file | including the UPGRADE-13.txt file |
| 13:57.49 | file | because it was in between 13 releases |
| 13:58.08 | cresl1n | i.e. is it needful? |
| 13:58.36 | file | that's the ponderance - no changes _need_ to be done as it operates in the same state it previously did |
| 13:58.44 | file | it just outputs a deprecated message if you use the options |
| 13:59.27 | cresl1n | let me finish this review and I'll take a look at it |
| 13:59.43 | file | denied. |
| 14:00.11 | cresl1n | woah, didn't realize the mysql cdr backend was in deprecated support land |
| 14:00.21 | file | yes |
| 14:00.40 | file | cdr_adaptive_odbc is core |
| 14:03.02 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zfcdxchhnmcjvqfz) |
| 14:03.11 | cresl1n | waves to kharwell |
| 14:03.14 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-aochwjourxlcrciq) |
| 14:03.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:03.23 | file | nods to newtonr |
| 14:03.40 | cresl1n | how social we are this morning |
| 14:03.53 | file | orange level social |
| 14:04.01 | newtonr | mooorning |
| 14:04.11 | kharwell | says hi to cresl1n |
| 14:06.14 | file | cresl1n, listen... do you want to know a secret? do you promise not to tell? |
| 14:06.32 | cresl1n | yes. Tell me in this public IRC chatroom |
| 14:06.44 | file | cresl1n, the password is password |
| 14:06.54 | cresl1n | NOOOOOOOOOooooooooooooooo |
| 14:07.03 | cresl1n | I guess it's better than ******** |
| 14:07.19 | file | truth |
| 14:12.22 | cresl1n | Which branches should tzafrir's cdr_mysql changes be cherry picked into? |
| 14:12.31 | cresl1n | 13 and 14? |
| 14:12.55 | cresl1n | file: |
| 14:12.58 | file | 11, 13, and 14 I believe |
| 14:13.12 | tzafrir | ok |
| 14:14.51 | cresl1n | Thanks file |
| 14:14.58 | cresl1n | tzafrir do you want to handle that? |
| 14:15.16 | cresl1n | or do you need assistance with it |
| 14:16.23 | tzafrir | I'll handle it |
| 14:16.48 | cresl1n | long time no see by the way :-) |
| 14:16.56 | cresl1n | Are you planning on going to astricon this year? |
| 14:21.31 | file | Less than a week away. |
| 14:21.53 | cresl1n | Much maple syrup will be partaken of |
| 14:21.58 | cresl1n | I feel this to be true. |
| 14:22.08 | file | The mock tails club has grown btw |
| 14:22.13 | cresl1n | YES! |
| 14:22.17 | cresl1n | Who else joins us? |
| 14:22.22 | cresl1n | jsmith probably woul |
| 14:22.23 | cresl1n | would |
| 14:23.14 | file | newtonr has joined us as a full member |
| 14:23.24 | cresl1n | egg-celent, egg-celent |
| 14:23.34 | file | With all privileges and a Ferrero rocher welcome bonus |
| 14:23.44 | cresl1n | Maybe we can find a krispy kreme out there too |
| 14:23.45 | newtonr | I love ferrero rocher |
| 14:24.34 | file | Mmm donut |
| 14:27.05 | cresl1n | nudges tzafrir |
| 14:28.30 | *** join/#asterisk-dev sh_smith (~smuxi@cpe-76-174-26-91.socal.res.rr.com) |
| 14:31.35 | tzafrir | cresl1n, I can't seem to figure out how to cherry-pick with git-review |
| 14:32.43 | cresl1n | I was taught to do it through gerrit |
| 14:32.47 | cresl1n | the GUI |
| 14:33.02 | tzafrir | When I run 'git review --cherrypick 3908 11' I get an error |
| 14:33.19 | tzafrir | Yeah. But for 11 there seems to be a merge conflict |
| 14:33.32 | cresl1n | ah |
| 14:33.40 | tzafrir | ok, I'll try the GUI |
| 14:33.54 | gtjoseph | the gui will fail if there's a confloct |
| 14:34.02 | cresl1n | ok |
| 14:34.06 | file | Yeah, it can only do so much |
| 14:34.14 | cresl1n | yeah, your 13 and 14 cherry picks worked though |
| 14:34.19 | file | The Gui is just quicker for the case where it is clean |
| 14:34.27 | gtjoseph | do a clean checkout of 11 |
| 14:34.28 | cresl1n | I think the topic needs to be fixed though, right? |
| 14:34.40 | gtjoseph | then git review -X 3908 |
| 14:34.49 | cresl1n | I just updated it |
| 14:34.52 | cresl1n | the topic |
| 14:35.07 | gtjoseph | fix the conflicts then git commit -a --amend |
| 14:35.30 | gtjoseph | then git review -t ASTERISK-26359 11 |
| 14:37.12 | gtjoseph | tzafrir: |
| 14:37.13 | gtjoseph | git checkout 11 |
| 14:37.14 | gtjoseph | git review -X 3908 |
| 14:37.14 | gtjoseph | fix conflicts then |
| 14:37.14 | gtjoseph | got add <conflited files> |
| 14:37.15 | gtjoseph | git commit -a --amend |
| 14:37.15 | gtjoseph | git review -t ASTERISK-26359 11 |
| 14:37.38 | gtjoseph | fix my spelling mistakes of course. :) |
| 14:54.48 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qefsftgfvblhogey) |
| 15:15.55 | file | baby you can drive my carrrr |
| 15:17.12 | file | rmudgett, do you think you can have a yes/no on whether your thing is a regression or not by today? or even better - some path to a solution |
| 15:19.42 | rmudgett | I have an idea that it is a regression. I looked at PJPROJECT code and could not see a reason why the saved last_tx message is invalid. I think I know what did it in our code but I need to find the commit and the code location to verify if the change I'm thinking of could be the cause. |
| 15:21.02 | file | k, so it could be on our side? |
| 15:33.31 | file | cresl1n, . |
| 15:33.46 | cresl1n | file, ? |
| 15:34.13 | file | cresl1n, you were going to contemplate the meaning of our existence and whether we should add anything re: ODBC option deprecation and pooling changes in 14 |
| 15:34.26 | cresl1n | crud, yes |
| 15:34.35 | file | create retrieve update delete? |
| 15:34.42 | cresl1n | Always. |
| 15:44.24 | cresl1n | Ok, let me know if this is what you're looking for |
| 15:44.41 | cresl1n | we should have the angry warning in the code reference the correct file |
| 15:44.46 | cresl1n | IMHO |
| 15:45.01 | file | nods |
| 15:45.07 | cresl1n | anything else? |
| 15:45.15 | file | nope! |
| 15:45.20 | cresl1n | okey dokey |
| 15:45.24 | cresl1n | sorry that took so long :-P |
| 15:46.08 | file | cresl1n, are you like a time sliced mainframe? |
| 15:46.13 | cresl1n | some days |
| 15:46.45 | cresl1n | the CRESLIN-3000 is fully operational for time sliced data |
| 15:46.59 | file | hum |
| 15:47.05 | file | cresl1n, we don't have a correct file... |
| 15:47.21 | file | what about mentioning the new pooling option? |
| 15:47.27 | cresl1n | That's fine |
| 15:49.43 | file | sored |
| 15:49.45 | file | er sorted |
| 15:50.30 | file | I did it for all as it's more useful |
| 15:50.47 | cresl1n | merci |
| 16:10.22 | rmudgett | https://gerrit.asterisk.org/#/c/3862/ could use another review. It is the last for that issue. |
| 16:13.08 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 17:32.09 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 17:32.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:41.56 | gtjoseph | chan_sip (again) I think I have a solution that doesn't spinloop, deadlock, leak objects or crash on shutdown. |
| 17:42.10 | gtjoseph | but it only works for rtpcachefriends=yes |
| 17:42.31 | gtjoseph | rtpcachefriends=no has never worked since stasis was introduced. |
| 17:42.55 | file | what does =no do? |
| 17:43.01 | file | or rather, how doesn't it work |
| 17:43.06 | gtjoseph | it's what it doesn't do. :) |
| 17:43.23 | gtjoseph | since the peer is created every time it's referenced... |
| 17:43.34 | file | yes. |
| 17:44.01 | gtjoseph | if it has a mailbox a subscription is created... |
| 17:44.10 | gtjoseph | which causes the callback to run |
| 17:44.24 | gtjoseph | which has to recreate the peer |
| 17:44.30 | gtjoseph | which subscribes to mailboxes |
| 17:44.37 | gtjoseph | thich causes the callback to run |
| 17:44.42 | file | nods |
| 17:44.45 | gtjoseph | which has to recrete the peer |
| 17:44.45 | file | we need to fix that too :P |
| 17:44.57 | file | pours acid in the wound |
| 17:44.58 | gtjoseph | but i'm thinking not in this patch |
| 17:45.19 | gtjoseph | which was the question I was leading up to. |
| 17:45.40 | gtjoseph | should i try to fix that as well in this patch? |
| 17:45.58 | file | imo yes - we should ensure that there are no remaining issues in that functionality |
| 17:46.44 | gtjoseph | yeah, ok |
| 17:47.18 | gtjoseph | this is going ot be another head scratcher |
| 17:48.57 | coreyfarrell | gtjoseph: is the new mailbox/subscription created before the old is destroyed? |
| 17:49.25 | gtjoseph | yep |
| 17:49.56 | file | if you are not caching is it useful to subscribe? |
| 17:49.57 | gtjoseph | we wind up with tons of peers and subscriptions for the same peer name and mailbox name |
| 17:50.27 | gtjoseph | why not |
| 17:50.45 | file | what will/would it do? |
| 17:51.25 | gtjoseph | that's the rub. it doesn't actually do anything because we destroy the peer object (and the subscriptions) when we're done with it |
| 17:51.43 | file | right, so the question stands |
| 17:52.06 | gtjoseph | well, if you don't use a memory cache for pjsip, you can still scribe to a mailbox correct? |
| 17:52.21 | file | you can explicitly subscribe |
| 17:52.36 | gtjoseph | just because the object disappeared doesn't mean that the actual peer device has gone away |
| 17:52.50 | file | right, I was more leaning towards the unsolicited MWI scenario |
| 17:53.11 | file | and if a device explicitly subscribes for MWI what does chan_sip do now? |
| 17:53.39 | gtjoseph | let's stick to unsolicited for now |
| 17:54.06 | gtjoseph | are you thinking that capabilities should change based on wheter you specified rtpcachefriends yes or no? |
| 17:54.24 | file | maybe - my question is simply this: without caching, has unsolicited MWI ever worked and can it work? |
| 17:55.15 | gtjoseph | as of 13.5 if rtpcache friends=no and you attempt to register with a mailbox specified, the chan_sip stack hangs |
| 17:55.36 | file | right, but that's 13 |
| 17:55.37 | file | how about 11? |
| 17:56.11 | gtjoseph | good question. let me test shat. since no stasis i'm guessing it worked but give me a few minutes. |
| 17:58.52 | file | it would not surprise me if caching had to occur for unsolicited to work |
| 18:00.02 | gtjoseph | you'd be incorrect. :) |
| 18:00.05 | gtjoseph | works fine |
| 18:00.35 | gtjoseph | well, let me say that i get notifies on register and unregister |
| 18:00.50 | gtjoseph | let me try registering and leaving a voicemail |
| 18:01.29 | file | do you get a NOTIFY each time the peer is created, though |
| 18:02.12 | file | matching behavior between 11 and 13 with no problems should be the goal here |
| 18:03.37 | gtjoseph | from a clean slate... |
| 18:03.42 | gtjoseph | register |
| 18:03.47 | gtjoseph | get notify |
| 18:03.51 | gtjoseph | send invite |
| 18:03.55 | gtjoseph | get notify |
| 18:04.04 | gtjoseph | send unregister |
| 18:04.08 | gtjoseph | get notify |
| 18:04.17 | gtjoseph | at each stage, sip show peers is empty |
| 18:04.25 | file | yup, so the act of creating the peer sends a NOTIFY |
| 18:04.31 | file | which could get a bit floody |
| 18:04.40 | file | that behavior should be maintained |
| 18:04.44 | gtjoseph | seems like it |
| 18:05.36 | gtjoseph | which may be tricky |
| 18:07.04 | gtjoseph | when the peer gets destroyed we have to keep the subscriptions active. |
| 18:07.13 | gtjoseph | until when though? |
| 18:07.14 | file | hmm? |
| 18:07.27 | gtjoseph | an unregister? |
| 18:07.33 | file | I don't understand the question. |
| 18:07.57 | gtjoseph | right now when the peer is cleaned up, the subscriptions get cleaned up. |
| 18:08.11 | file | if you change it such that the subscription has the peer (without a ref) you don't need to look it up from inside the callback |
| 18:08.18 | file | and since it's not looking it up, you can unsubscribe and join |
| 18:08.34 | file | which should guarantee that the callback won't get called after the unsubscribe and join returns, so the peer is valid |
| 18:08.58 | gtjoseph | th epeer is gone |
| 18:09.58 | gtjoseph | if i register and that transaction completes, the last ref to the peer is released so the destructor is run and cleans up the subscriptions |
| 18:10.04 | file | sure. |
| 18:10.13 | gtjoseph | i'll never get norified of unsolicited mwi |
| 18:10.18 | file | right. |
| 18:10.23 | file | which is the exact behavior that 11 has |
| 18:10.33 | file | the act of creating the peer creates the subscription which then sends it out |
| 18:10.36 | gtjoseph | no i haven't tested that yet |
| 18:10.37 | file | it gets destroyed, subscription goes away |
| 18:10.39 | file | rinse and repeat |
| 18:11.50 | gtjoseph | is there a way to fool voicemail so that it causes MWI to be sent? |
| 18:12.00 | file | leave a voicemail? |
| 18:12.11 | gtjoseph | i don't have enough devices atm. |
| 18:12.41 | file | don't think so, then, as you would need to do it through voicemail in order to trigger the event |
| 18:12.42 | gtjoseph | can't tou touch something in the spool dir? |
| 18:12.48 | gtjoseph | hmmm |
| 18:13.05 | file | you could turn polling on |
| 18:13.06 | file | it'd take a bit |
| 18:13.09 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-lcnmftleuuqyqcns) |
| 18:14.05 | gtjoseph | pollmailboxes=yes |
| 18:16.41 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pmdzvngapmwvfmbu) |
| 18:22.55 | tm1000 | file: do you know of any AMI core dumps in Asterisk 14. I have a reproducible one but if there is a ticket I dont want to duplicate it. |
| 18:23.02 | file | nope |
| 18:28.09 | tm1000 | file: https://issues.asterisk.org/jira/browse/ASTERISK-26397 if you're bored. |
| 18:29.22 | file | wishes he was bored |
| 18:30.00 | WIMPy | starts the file boring machine |
| 18:41.02 | tm1000 | file: does this affect 13.11.2 as well? |
| 18:41.07 | file | shouldn't |
| 18:41.22 | tm1000 | file: just curious saw the ticket update and you attached 13.11.2 on there |
| 18:41.33 | tm1000 | oh then you removed it >.< |
| 18:41.38 | file | I err on the side of assuming first, until after investigation, then I tweak further |
| 18:41.55 | tm1000 | were you able to reproduce? |
| 18:42.17 | file | no |
| 18:42.25 | file | but I compared the code based on the issue |
| 18:46.04 | gtjoseph | file: correct that there's no unsolicited mwi on 11 without cache |
| 18:47.50 | gtjoseph | still not sure how to prevent the run-away in 13 though |
| 18:48.30 | file | the MWI callback keeps a peer name and looks up the peer based on that - why? |
| 18:48.44 | gtjoseph | to see if it's in the cache |
| 18:48.59 | file | why can't it keep a pointer to the peer? |
| 18:49.05 | gtjoseph | it's gone |
| 18:49.19 | file | why? |
| 18:49.21 | gtjoseph | unless you're saying to bump the peer refcount |
| 18:49.25 | file | I'm not. |
| 18:49.44 | gtjoseph | with cache=no, the peer's refcount dropsa to 0 after the current transaction |
| 18:49.51 | file | right, which does what? |
| 18:50.16 | gtjoseph | destroys the peer?? |
| 18:50.21 | file | and unsubscribes |
| 18:50.22 | gtjoseph | what are you getting at? |
| 18:50.26 | gtjoseph | yes |
| 18:50.42 | file | if the destruction calls unsubscribe_and_join is there a guarantee that when it returns the MWI callback will no longer be invoked? |
| 18:50.55 | gtjoseph | the destruction doesn't call join |
| 18:50.58 | gtjoseph | anymore |
| 18:51.04 | file | right, but I'm saying if it did |
| 18:51.10 | gtjoseph | that's what we just removed |
| 18:51.15 | file | I realize this |
| 18:51.31 | file | because a peer could get destroyed within the MWI callback |
| 18:51.53 | file | however if it is guaranteed that this will not happen, you can unsubscribe_and_join from outside fine |
| 18:52.47 | gtjoseph | let me work on it for a bit. |
| 18:53.08 | file | if that guarantee proves correct - that fixes both problems and returns behavior back to what it was |
| 18:53.14 | file | and now I take my dog for a walk |
| 19:07.22 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rpzmowvtrpmajnqf) |
| 20:01.14 | gtjoseph | file: now having an issue with ast_endpoint_shutdown(peer->endpoint) getting run multiple times. :) |
| 20:04.32 | file | naturally |
| 20:05.49 | gtjoseph | doesn't look like there's a check in ast_endpoint_create for dups |
| 20:08.01 | rmudgett | file: There is a path where subtype and message won't get initialized. This is also with the AMI action presencestate |
| 20:08.05 | gtjoseph | so in cases where we have 2 separate peer objects existing simultaneously, should we reference the same endpoint? |
| 20:08.22 | file | rmudgett, I put a 13 review up already |
| 20:08.29 | file | gtjoseph, I think so |
| 20:08.56 | gtjoseph | makes sense. to bad there isn't a ast_endpoint_find(tech,id) |
| 20:09.01 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:09.53 | file | you'd want to do it inside of create, or else you risk a race condition where you still end up with two |
| 20:10.10 | gtjoseph | yeah was just thinking about that |
| 20:16.42 | *** join/#asterisk-dev acidfoo_ (~acidfoo@24-212-247-227.cable.teksavvy.com) |
| 20:21.25 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-qomuuckuuhbstwvz) |
| 20:51.49 | gtjoseph | file: ast_endpoint_find_by_id only looks in tech_endpoint. was that correct or should it have been looking in endpoints as well? |
| 20:52.04 | gtjoseph | oh, nevermind |
| 20:52.12 | gtjoseph | :) |
| 20:56.14 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 22:00.08 | gtjoseph | well, this is disconcerting... it doesn't matter if the 2 peer object use the same endpoint object or 2 different endpoint objects. the name's the same so you still get stasis_cache.c:845 caching_topic_exec: Attempting to remove an item from the SIP/1000-cached cache that isn't there: ast_endpoint_snapshot_type SIP/1000 |
| 23:04.56 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-zfcdxchhnmcjvqfz) |