| 00:53.41 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xozaobasolatpvfn) |
| 00:54.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.175) |
| 01:37.35 | *** join/#asterisk-dev snuff-work (~snuffy@1.136.61.119) |
| 01:37.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:48.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:48.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:15.21 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 06:15.21 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:21.10 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:21.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:24.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.166) |
| 06:32.55 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 06:44.56 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 07:09.42 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:09.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:24.25 | oej | Morning folks |
| 07:38.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.147) |
| 07:52.30 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 09:00.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.147) |
| 09:15.00 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 09:15.01 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 10:11.53 | *** join/#asterisk-dev tzafrir (~tzafrir@37.26.146.245) |
| 10:11.53 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:25.44 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:58.58 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:58.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:59.03 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:15.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.146) |
| 12:15.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.146) |
| 13:07.02 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.146) |
| 13:55.34 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:55.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.54 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-kdytkjjcgqhmhdwp) |
| 14:09.56 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-beomnbhcglauxfir) |
| 14:09.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:21.48 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:21.48 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:23.23 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 14:41.57 | nubbie | file: Is https://reviewboard.asterisk.org/r/2645/ more about improving performance in asterisk or reducing how many things directly access data structures? |
| 14:42.18 | file | both |
| 14:43.14 | nubbie | Won't moving things into stasis core mean asterisk is going to use more memory? I assume we just cache it there |
| 14:43.54 | file | for that stuff, yes |
| 14:44.33 | nubbie | how long do we use cache before it expires, or is it configurable? |
| 14:45.02 | file | they are cached for the lifetime of the object they are a snapshot of |
| 14:46.10 | nubbie | OIC |
| 14:47.12 | nubbie | Where is the wiki page about stasis cache? Figured I'll read that first to better understand what it does |
| 14:48.11 | file | I don't have an immediate link so I would have to search |
| 14:48.33 | nubbie | okay |
| 14:48.44 | leedm777 | nubbie: http://doxygen.asterisk.org/trunk/stasis.html |
| 14:48.53 | leedm777 | Also https://wiki.asterisk.org/wiki/display/AST/Using+the+Stasis+Message+Bus |
| 14:48.59 | nubbie | leedm777: thanks |
| 14:49.07 | nubbie | Also, what is ARI mean? |
| 14:49.07 | leedm777 | Sorry, meant https://wiki.asterisk.org/wiki/display/AST/Stasis+Message+Bus for the second link |
| 14:49.12 | nubbie | seen that a few times now |
| 14:49.13 | leedm777 | Asterisk REST Interface |
| 14:49.34 | leedm777 | It's the RESTful HTTP interface on top of Stasis |
| 14:49.48 | leedm777 | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+RESTful+API |
| 14:50.11 | nubbie | Oooo |
| 14:50.11 | nubbie | that makes sense |
| 14:50.17 | jrose_atDigium | file: https://reviewboard.asterisk.org/r/2648/ - the reson for case insensitivity in this review is because this set of feature flags only applies to the channel the function is called on rather than having the whole mess of applying features to the peer and the caller simultaneously. I'm not whether matching only upper case letters is appropriate or not in this case. |
| 14:50.21 | jrose_atDigium | *reason |
| 14:50.32 | putnopvut | mjordan: Hey, I've been seeing an occasional crash in CDR code when a transferer channel is re-called. It doesn't always happen (yay race condition!) but I figured I'd post a backtrace for you. |
| 14:50.41 | jrose_atDigium | s/I'm not whether/I'm not sure whether/ |
| 14:50.45 | nubbie | leedm777: Ya, tried it a few weeks ago. |
| 14:50.55 | leedm777 | :-D |
| 14:51.07 | leedm777 | nubbie: and your thoughts on it? |
| 14:51.13 | file | jrose_atDigium, oic |
| 14:51.22 | putnopvut | mjordan: fpaste.org/21669/24309891/ |
| 14:51.35 | jrose_atDigium | I discussed case sensitivity with Richard, but he didn't really mind one way or another. |
| 14:51.41 | nubbie | leedm777: not bad, I could only query asterisk information. Don't think much else was implemented.... eg: playback of audio |
| 14:51.46 | nubbie | I think you recently added it |
| 14:51.52 | nubbie | so, need to give it a run again |
| 14:52.00 | putnopvut | Not sure whether that's just a CDR bug or if I'm doing something that's causing that to happen. |
| 14:52.13 | file | jrose_atDigium, since you specifically document that the flags are that of Dial() I'd prefer case sensitive |
| 14:52.24 | jrose_atDigium | Alright then. |
| 14:52.28 | leedm777 | nubbie: Playback has been in there forever. Like maybe a whole week; or even two :-P |
| 14:52.34 | file | unless I'm overruled |
| 14:53.03 | nubbie | leedm777: Ya, think I did it 6 weeks ago |
| 14:53.10 | leedm777 | nubbie: bridging support should also be in there now. So you should be able to create a bridge, put two channels into it, and they can talk to each other. |
| 14:53.42 | leedm777 | recording is still in review - https://reviewboard.asterisk.org/r/2612/ |
| 14:54.00 | leedm777 | And I'm posting the review for authentication now. |
| 14:54.00 | nubbie | cool |
| 14:54.10 | nubbie | music on hold? |
| 14:54.27 | file | Qwell has a review up for putting a channel on hold and taking them off hold |
| 14:54.36 | Qwell | file: I have like 4 ARI reviews up :p |
| 14:55.14 | Qwell | 26{26,34,41,47} |
| 14:55.46 | leedm777 | makes a note to do some code reviews today |
| 14:57.47 | Qwell | leedm777: Your feedback would be useful on r2626, in response to comments from putnopvut. |
| 14:57.51 | jrose_atDigium | file: On the topic of failures for finding a particular feature - one thing I worry about there is that if we have users swapping dial plans from future versions back into earlier versions lacking a feature for whatever reason, I'm don't think they would want to get the whole function rejected purely based on a feature they wanted to apply that doesn't exist in the version they are using. |
| 14:57.54 | Qwell | whenever you're able |
| 14:58.47 | file | yeah - that's the other side of the coin... you can either accept a broken config and do what you can, or reject it because it won't do what they want |
| 14:59.02 | leedm777 | Qwell: Mark's right. If invalid input is given, then you should respond with 400 Bad Request |
| 14:59.51 | leedm777 | If the request would have been good if the referenced objects were in a different state, then it's a 409 Conflict |
| 15:15.29 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:15.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:23.23 | Qwell | leedm777: Should I fix the other places where it does 5xx errors with bad input then? |
| 15:23.33 | Qwell | (outside the scope of this review) |
| 15:23.43 | mjordan | putnopvut: your dial message has snapshots that are either bad, or aren't in the places I expected |
| 15:24.05 | mjordan | putnopvut: do you have a caller/peer snapshot, just a peer snapshot, or just a caller snapshot in that message? |
| 15:25.43 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-pjwiltkgsulqpxcp) |
| 15:29.17 | putnopvut | mjordan: just a sec... |
| 15:29.30 | putnopvut | Got Richard in the office. |
| 15:30.27 | putnopvut | Okay, I'm free now. |
| 15:31.27 | nubbie | RUN |
| 15:31.29 | putnopvut | mjordan: I'm not 100% sure, but I'd expect that I just have a peer snapshot. The reason is that I'm using the dial API similar to how an originate works, in that I give no requestor channel for the outbound dial. |
| 15:32.27 | putnopvut | I should add that I see this crash occur when I answer the dialed channel. |
| 15:34.45 | leedm777 | Qwell: I say go ahead an fix the other 500's directly in trunk |
| 15:35.36 | file | salts leedm777 |
| 15:35.41 | mjordan | putnopvut: ah |
| 15:35.55 | mjordan | I think I have this fixed already |
| 15:36.08 | mjordan | putnopvut: Jonathan ran into something similarish |
| 15:36.48 | putnopvut | Okay, so perhaps an svn update would pull in the fix? |
| 15:36.52 | mjordan | it actually has more to do with outbound channels not getting cleared |
| 15:36.58 | mjordan | in just a few seconds :-) |
| 15:37.18 | putnopvut | Okay. |
| 15:37.20 | leedm777 | peppers file |
| 15:51.09 | mjordan | putnopvut: updated |
| 15:51.40 | putnopvut | mjordan: I'll give it some test runs. |
| 16:05.11 | putnopvut | mjordan: crash still happens. I'll get a CDR debug and pastebin that mother. |
| 16:07.46 | mjordan | thanks |
| 16:09.42 | putnopvut | mjordan: http://ur1.ca/egux0 |
| 16:10.26 | putnopvut | Scenario: Alice calls Bob. Alice transfers Bob to Carol. While Carol is ringing, Alice hangs up. Carol's ringing times out. We originate a new call to Alice. Alice answers. Crash. |
| 16:11.24 | putnopvut | The new call to Alice also means a new Alice channel (the original is alice-00000004, the new one is alice-00000007) |
| 16:11.38 | mjordan | huh |
| 16:11.40 | mjordan | that is odd |
| 16:11.52 | mjordan | pretty sure I had a unit test for that case too |
| 16:11.56 | mjordan | looks |
| 16:12.24 | mjordan | AH |
| 16:13.05 | mjordan | My unit test might not cover this correctly. I'll update it. |
| 16:13.16 | putnopvut | okiedokie |
| 16:14.03 | putnopvut | So one thing to note is that this had been a randomly-occurring race condition-esque thing. Since my update, I've tried the scenario twice and have triggered the crash both times. |
| 16:14.17 | putnopvut | So it may actually be a bit more deterministic now at least. |
| 16:14.29 | file | All Hail mjordan, CDR Master! |
| 16:15.18 | Qwell | oh, that reminds me |
| 16:15.20 | putnopvut | Yeah, attempt number three crashed as well. I think we're looking at a constant crash instead of a random one now (which is good) |
| 16:15.54 | Qwell | <.< |
| 16:15.55 | Qwell | >.> |
| 16:16.18 | mjordan | putnovput: I can either give you a patch now and you can test it, or you can wait for me to write the unit tests to cover this scenario |
| 16:16.34 | putnopvut | mjordan: either way works. |
| 16:16.55 | putnopvut | (and for the record, attempt number four did not crash. This apparently is still a race condition :() |
| 16:18.09 | mjordan | that is.... odd. Messages are generally serialized to CDR land |
| 16:19.13 | putnopvut | What I can do is get a CDR debug in the non-crash case then. |
| 16:19.19 | putnopvut | hold please! |
| 16:19.43 | file | plays hold music |
| 16:20.46 | putnopvut | dangit, three crashes in a row. This may be difficult. |
| 16:22.56 | putnopvut | mjordan: here's the no crash scenario: http://ur1.ca/egv17 |
| 16:23.39 | putnopvut | oh and btw, you can ignore those FRACKs from bridging_basic.c It's an invalid assertion that I need to get rid of. |
| 16:27.18 | mjordan | hrm. |
| 16:27.21 | mjordan | looks again. |
| 16:27.33 | mjordan | I have a unit test now, will run that too. |
| 16:29.00 | mjordan | I suspect the difference is that in one scenario, gulp/alice is the first one in the bridge, in the crashing scenario they are the second |
| 16:29.06 | mjordan | have you applied to the patch I sent you? |
| 16:33.53 | putnopvut | mjordan: I have not. |
| 16:34.12 | putnopvut | mjordan: and actually, where is this patch you sent me? |
| 16:34.48 | file | putnopvut, see swdev :P |
| 16:35.42 | putnopvut | I don't see it there either? |
| 16:35.49 | Qwell | putnopvut: jabber |
| 16:36.22 | putnopvut | I DON"T UNDERSTAND! THERE IS NO PATCH THERE! |
| 16:41.12 | mjordan | email |
| 16:41.17 | mjordan | which probably didn't reach you |
| 16:41.19 | mjordan | hysterical |
| 16:41.22 | putnopvut | yeah, e-mail be broken |
| 16:41.30 | mjordan | hold on |
| 16:43.17 | mjordan | http://fpaste.org/21716/72437790/ |
| 16:43.46 | putnopvut | Heh, the simple fix. Check for NULL :) |
| 16:44.19 | mjordan | also the correct one |
| 16:44.34 | mjordan | the point of that routine is to figure out if the channel's party B is one of the participants in the bridge |
| 16:44.44 | mjordan | but, the channel has no Party B. It was originated. |
| 16:44.59 | mjordan | ergo, no one in the bridge is its Party B |
| 16:45.35 | putnopvut | Yeah, what's funny is that I had contemplated that change since there is a lot of code that checks for the existence of the party B snapshot but this one particular routine did not. |
| 16:45.50 | putnopvut | But I figured I'd leave it to you. As it turns out, my inclination was right. |
| 16:46.40 | mjordan | dialing is weird |
| 16:46.47 | putnopvut | Pretty sure I won't be seeing that crash any more. |
| 16:46.51 | mjordan | If I did it all over again (again!), I might make origination its own state |
| 16:47.11 | mjordan | if we had an early bridge, this would have been much easier |
| 17:43.45 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-tbssbjdqhlgnwlti) |
| 17:48.29 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:48.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:14.57 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.168) |
| 18:17.45 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:17.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:20.55 | putnopvut | mjordan: so that patch appears to be working well. Are you planning to just commit that to trunk? |
| 18:29.35 | mjordan | already did |
| 18:29.44 | mjordan | r393164 |
| 18:29.49 | mjordan | had to get my unit test passing as well :-) |
| 19:13.56 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:13.56 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:32.04 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:32.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:35.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:35.14 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:09.53 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.125.168) |
| 20:13.07 | putnopvut | mjordan: new CDR issue. In my latest convoluted-ass transfer situation, I can reliably trigger an assertion in cdr.c in base_process_bridge_leave(). The assertion is triggered *because* base_process_bridge_leave() is being called. |
| 20:16.44 | mjordan | yay! |
| 20:16.56 | mjordan | you told a CDR to leave the bridge when it didn't think the channel was in a bridge |
| 20:17.13 | putnopvut | Since I don't have DO_CRASH defined, it means I really don't actually see anything go wrong. I just see the FRACK on the console. |
| 20:17.17 | mjordan | yup |
| 20:17.22 | mjordan | cdr debug me if you can |
| 20:17.28 | putnopvut | Will do! |
| 20:17.36 | putnopvut | Give me a sec to get my shizzle in order. |
| 20:17.40 | mjordan | for rizzle |
| 20:19.07 | putnopvut | mjordan: http://ur1.ca/egxct |
| 20:20.07 | putnopvut | Scenario: Alice calls Bob. Alice transfers Bob to Carol. While Carol is ringing Alice hangs up. Carol's ringing times out. Alice starts ringing. Alice's ringing times out. Carol starts ringing again. Carol answers. Carol and Bob talk. Carol hangs up. Bob hangs up. It's when Bob hangs up that the FRACK occurs. |
| 20:21.25 | WIMPy | I've got a little issue with sip qualifys. Looks like unreachable events are only logged sometimes. |
| 20:22.04 | WIMPy | When I look at the logs I see a lot more reachable lines than unreachable, no lagged. |
| 20:23.25 | WIMPy | And I've just seen an even on the console, where I get a notice about the hint being updated to unavailable and 2min later to idle again, but only a reachable notice, no unreachable or legged before. |
| 20:29.52 | WIMPy | event |
| 20:32.50 | mjordan | interesting |
| 20:33.04 | mjordan | we never got the Bridge Enter message for Local/6000@default-00000001;1 |
| 20:33.34 | mjordan | WIMPy: When you say unreachable events, what events are you referring to? AMI? |
| 20:34.04 | WIMPy | The event itself. Looking at logfile and console. |
| 20:34.14 | mjordan | So, a log message |
| 20:34.45 | mjordan | Or is it that the peer is staying "unreachable" even after it has been qualified? |
| 20:34.56 | WIMPy | If I'm fast enough I can take a look at what happened on AMI. |
| 20:35.06 | mjordan | putnopvut: How did that Local channel get put into the bridge? |
| 20:35.08 | WIMPy | How so? |
| 20:36.59 | putnopvut | mjordan: The local channels involved in the call were imparted into the bridge after ast_request() and ast_call(). |
| 20:39.05 | mjordan | welll.... it appears as if we didn't get a Bridge Enter message for it |
| 20:39.19 | mjordan | putnopvut: if you connect with AMI, can you see a Bridge Enter message for that channel? |
| 20:40.13 | mjordan | wait wait wait. |
| 20:40.14 | mjordan | Hm. |
| 20:40.35 | putnopvut | waits intently |
| 20:40.51 | mjordan | yeah. I only see a single Bridge Enter message, and two Bridge Leave messages for that channel |
| 20:41.07 | putnopvut | Want me to look at what AMI reports? |
| 20:41.08 | mjordan | that would be a 'bad thing' |
| 20:41.09 | mjordan | yeah |
| 20:41.13 | putnopvut | all righty |
| 20:41.41 | mjordan | I'm honestly amazed its handled attended transfers this well |
| 20:42.08 | mjordan | WIMPy: I guess I'm just confused about what you're saying is happening. Do you have a log snippet that shows what you're describing? |
| 20:42.19 | putnopvut | mjordan: so am I looking for a BridgeEnter for Local/6000@default-00000001;1 ? |
| 20:42.23 | putnopvut | Because I see that in AMI |
| 20:42.33 | mjordan | you should see two |
| 20:42.49 | putnopvut | Why two? |
| 20:42.51 | mjordan | because somehow it sent two BridgeLeave messages |
| 20:43.05 | putnopvut | okay |
| 20:43.26 | putnopvut | Ah, I see two BridgeEnters |
| 20:44.38 | putnopvut | And two BridgeLeaves |
| 20:45.23 | putnopvut | I should double-check to make sure I'm not doing some silly double-imparting of the channel, since I'd only expect a single BridgeEnter. |
| 20:45.40 | WIMPy | mjordan: http://wimpy.yeti.dk/pastebin |
| 20:47.31 | mjordan | Did anything try to use flelfvis when it was unreachable? |
| 20:47.49 | WIMPy | Nope. Only qualifying. |
| 20:49.02 | putnopvut | Hm, I believe I did double-impart the channel. Testing again. |
| 20:49.43 | putnopvut | Yep, no FRACK any more. Sorry for wasting your time, mjordan |
| 20:50.30 | pabelanger | WIMPy: the logic to determine statechanged for logging it is a little weird. Check it out |
| 20:51.14 | mjordan | phew |
| 20:51.21 | mjordan | I'm still amazed it's working |
| 20:51.32 | file | wait... the CDR code found a bug in putnopvut's code |
| 20:51.48 | mjordan | hides |
| 20:51.52 | mjordan | actually... |
| 20:51.58 | mjordan | we should declare mission success and go have beer |
| 20:52.00 | mjordan | \o/ |
| 20:52.10 | pabelanger | WIMPy: which might explain why there is more reachable messages then unreachable |
| 20:52.27 | WIMPy | mjordan: The interesting thing is that it seems to work for the hint, but not for logging. |
| 20:52.44 | WIMPy | Err, sorry, pabelanger |
| 21:24.11 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 22:11.30 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-beomnbhcglauxfir) |
| 22:19.42 | file | leedm777, first class resource... INTERESTING THOUGHT |
| 22:23.19 | leedm777 | I thought so to. Which is why I thought it. |
| 22:41.37 | *** join/#asterisk-dev micols (~t@shell1.rlogin.dk) |
| 22:46.57 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.169) |
| 22:51.18 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-kdytkjjcgqhmhdwp) |
| 23:22.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:22.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:30.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |