| 01:03.11 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:03.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:11.58 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 05:17.11 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 06:14.21 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:14.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:14.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:306d:bcc7:9472:9b97) |
| 06:43.01 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:15.48 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 09:55.18 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 09:55.21 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 09:55.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 09:56.08 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-ldwofqimvvzbrxev) |
| 11:02.19 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 11:14.46 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:14.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:23.15 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ehvqawcjitxvjbah) |
| 11:56.08 | seanbright | X-Rob: i would argue that it is more typical to have asterisk machines without resolvable FQDNs than the opposite |
| 11:57.22 | seanbright | it all depends on how you are using asterisk |
| 12:06.25 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:44.06 | file | Tuesday Tuesday Tuesday |
| 12:54.35 | seanbright | it's tuesday?! shit |
| 13:18.37 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-118-98.user.veloxzone.com.br) |
| 13:25.23 | russellb | the good news is that we can safely set Monday on fire now that it's behind us |
| 13:32.22 | file | russellb, I'd prefer to melt it with a propane torch |
| 13:33.29 | russellb | file: will you pour the remains into some sort of mold? |
| 13:33.37 | russellb | perhaps in the shape of a bonus Friday? |
| 13:33.51 | file | yes! |
| 13:39.23 | jameswf | 99% of servers are multi tenant #trusstory #factsijustmadeup |
| 13:40.22 | malcolmd | jameswf: actually it's more like 120% |
| 13:40.52 | jameswf | malcolmd: we are working on over 9000% |
| 13:40.53 | malcolmd | since they're "multi" tenant, that means you've got more than one, so that's greater than 100%, o'course |
| 13:41.01 | malcolmd | jameswf: hard work pays off in the long run |
| 13:41.42 | malcolmd | unless you're running a business, and then paying for anything (developers, features important to your business process, office space, servers, etc.) just doesn't make any sense |
| 13:54.23 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:57.58 | Qwell | malcolmd: but, free coffee for all! |
| 13:59.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-spyqgivromgeiixt) |
| 14:14.02 | tzafrir | is happy to see svn:externals removed from Asterisk. Yey! |
| 14:15.07 | tzafrir | Another minor issue: the exception in the license of Asterisk allows building it with OpenSSL. But there are now some forks of it floating arounf (libressl, BoringSSL) |
| 14:15.36 | tzafrir | There are also some variations of the OpenSSL exception floating around. See e.g.: |
| 14:15.44 | tzafrir | https://lists.debian.org/debian-devel/2014/07/msg00825.html |
| 14:17.19 | seanbright | file: am i correct in saying that the dtls* options in sip.conf only apply to devices and not globally? |
| 14:17.22 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-xhqkviljryululxw) |
| 14:17.28 | file | correct |
| 14:17.32 | seanbright | k |
| 14:18.00 | file | if you are doing it from .conf just use templates |
| 14:18.03 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-wjpwihsitxdsbvkd) |
| 14:18.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:18.07 | seanbright | yeah |
| 14:26.34 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:26.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:27.20 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 14:29.50 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:34.03 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-uscvrchtpmqwahwu) |
| 14:34.14 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:35.38 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:35.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:38.24 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-33.kc.res.rr.com) |
| 14:42.13 | *** join/#asterisk-dev oej (~Adium@185.32.9.250) |
| 14:42.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:50.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wrcgsrivnywyvkta) |
| 14:50.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:54.19 | *** join/#asterisk-dev oej (~Adium@185.32.9.250) |
| 14:54.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:02.45 | sruffell | I may have already missed the discussion about this, but https://github.com/sruffell/asterisk-working/commit/720c59c321e2e01397ca04fa625572dac70760a2 sits the mother of all commit messages. |
| 15:04.54 | file | there was no discussion about the commit message |
| 15:05.16 | sruffell | :) |
| 15:05.29 | Qwell | It should have been reviewed. :p |
| 15:07.19 | sruffell | Qwell, how do you do reviews where you are now? |
| 15:07.35 | sruffell | Do you use a tool / process that allows you to include commit messages in the review? |
| 15:07.46 | sruffell | (oh, and I'm not complaining about the linked messageâ¦I like it) |
| 15:07.50 | Qwell | sruffell: well, we use git, so... |
| 15:08.18 | sruffell | Butâ¦.what about review? Even stash, when I looked at it a year or so ago, didn't make it easy to review the commit message with the commit. |
| 15:08.23 | Qwell | really though, I'm not sure. I was being a bit facetious. |
| 15:08.24 | sruffell | Only email. |
| 15:08.30 | sruffell | ahh..:) |
| 15:08.39 | Qwell | we use Fisheye, mostly |
| 15:08.53 | sruffell | Isn't that a repo browser? |
| 15:08.58 | sruffell | as opposed to a code review tool? |
| 15:09.24 | Qwell | err, sorry, no, you're right. Crucible |
| 15:09.40 | sruffell | ahh..Crucible, that's right. |
| 15:10.09 | Qwell | all Confluence, all the time |
| 15:10.24 | sruffell | heh |
| 15:10.35 | Qwell | or Atlassian. whatever. I haven't finished my redbull. |
| 15:10.37 | sruffell | It's the msword of wikis. |
| 15:12.21 | pabelanger | sruffell, git-review is fantastic |
| 15:12.37 | pabelanger | a simple frontend to gerrit2 |
| 15:12.38 | sruffell | that's not some gerrit nonesense is it? :) |
| 15:12.46 | pabelanger | Of course |
| 15:13.22 | sruffell | I do not think there is going to be much stomach for setting up another infrastructure for that. I think Atlassian has too much momentum behind it at this point. |
| 15:14.41 | pabelanger | Ya, if you are married to Atlassian you'll need to work around that. But honestly, it is just git so your upstream repos are in gerrit and they just replicate into Atlassian. Of course, it required time and energy to set it up |
| 15:15.28 | sruffell | nods |
| 15:17.10 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-qoxzcunkxtlxktsy) |
| 15:32.00 | *** join/#asterisk-dev anonymouz666 (~anonymouz@179.236.136.49) |
| 15:54.14 | *** join/#asterisk-dev vassilux (~vassilux@LMontsouris-656-01-80-156.w82-127.abo.wanadoo.fr) |
| 16:01.14 | seanbright | am i the only one that can't stay logged in to jira? |
| 16:01.39 | seanbright | i feel like i'm constantly putting in my credentials |
| 16:03.22 | opticron | do you click the little "remember me" box? |
| 16:03.26 | seanbright | yeah |
| 16:03.30 | opticron | I don't login but about once a month |
| 16:03.39 | seanbright | i should kill the cookies |
| 16:03.41 | seanbright | will do that |
| 16:03.47 | opticron | yeah, that usually has an effect |
| 16:06.03 | tm1000 | file: if I add the option âmedia_use_received_transportâ to a version of asterisk lower than when you added that option it seems that PJSIP gets upset and wont setup the endpoint |
| 16:06.42 | file | that is correct, you can't set unknown options OR options with invalid values (if they can know it at config time) |
| 16:10.27 | tm1000 | file: ah |
| 16:10.36 | tm1000 | file: welp thats different from chan_sip ;-) |
| 16:10.40 | file | yes. |
| 16:10.49 | file | newer stuff won't allow you to apply a potentially invalid configuration |
| 16:10.56 | tm1000 | file: thats good though |
| 16:11.24 | tm1000 | file: so media_use_ is only in 12.4.0 |
| 16:11.31 | file | yes |
| 16:13.53 | newtonr | seanbright, yeah you shouldn't have to constantly login. I suspect something browsery |
| 16:16.56 | pabelanger | seanbright, I had some issue when I was using my subversion cert when accessing JIRA, not sure if you do the same. |
| 16:18.57 | file | you can't use a subversion cert to access JIRA |
| 16:21.41 | pabelanger | there was some SSL cert at some point in time |
| 16:21.45 | pabelanger | like 4 years ago |
| 16:21.50 | pabelanger | not sure if that is a thing any more |
| 16:22.24 | file | it is for certain individuals |
| 16:22.46 | file | no community person, though |
| 16:22.48 | pabelanger | Right, I was just giving my feedback when I had issues |
| 16:22.54 | pabelanger | nods |
| 16:32.47 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 16:37.08 | *** join/#asterisk-dev oej (~Adium@185.32.9.250) |
| 16:37.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:57.23 | pabelanger | mjordan, I was thinking about your comments last night about the performance hit sending message across the internal bus in asterisk (disallow messages patch). How difficult would it be to move said message bus to an external system? For example, somebody wrote res_rabbitmq.so? I would imagine there must be some improvement by removing that part from the asterisk system |
| 16:59.16 | Qwell | You still have to generate the message, pass it out of the system, receive it again, and then parse. |
| 17:00.27 | pabelanger | Right. So my question in a round about way, where is the bottle neck. The parsing or the messaging backend |
| 17:03.44 | *** join/#asterisk-dev oej (~Adium@185.32.9.250) |
| 17:03.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:29.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:45.25 | mjordan | pabelanger: when I've profiled it, it has been in the generation & processing |
| 17:45.34 | mjordan | pabelanger: stasis as a message bus is leeaaannnn |
| 17:45.53 | mjordan | what you describe is theoretically possibly, but there are also a lot of complexities. |
| 17:46.31 | mjordan | (1) A large number of messages are used internally to synchronize activities (for example: attended transfers use bridge/channel messages to know the state of things and/or send messages to SIP endpoints) |
| 17:46.50 | mjordan | Those internal message use cases would be broken as hell by an external message bus, and/or would have radically different timing |
| 17:47.31 | mjordan | (2) The dialplan sometimes synchronizes on stasis messages (CDR function) and also will query things in the Stasis cache. I'm not sure how you'd manage that with an external message bus. It's probably doable, but non-trivial. |
| 17:48.44 | mjordan | (3) The benefit of going to an external message bus is that you can spread functionality across multiple systems. However, this doesn't really work well, as most of the systems that are consumers don't exist in a bottle (CDR/CEL have events and manipulation from dialplan; AMI is already a 'message bus' (in a limited sense) so moving it is somewhat superfluous, etc.) |
| 17:48.58 | mjordan | Say, for example, we wanted CDRs on another system |
| 17:49.22 | mjordan | If you're at the point where you want to generate CDRs in a central location from n systems, or you want to offload them, you've probably outgrown Asterisk CDRs already anyway |
| 17:49.33 | mjordan | In which case, what you really want is the data that makes up the Asterisk CDRs |
| 17:49.42 | mjordan | Which you already have (and you don't need another message bus) |
| 17:50.04 | mjordan | You'd disable CDRs on your system (which does improve performance, as it does a lot of work to build out that picture of the world) |
| 17:50.10 | mjordan | Then, you have two options: |
| 17:50.36 | mjordan | (1) Use an existing mechanism (such as AMI or CEL) to build out your CDRs wherever you want, as both support different or similar mechanisms to convey information to something external |
| 17:50.59 | mjordan | (2) Write your own. You could easily tie Stasis messages into RabbitMQ/reddis/whatever is the flavor de jeur |
| 17:51.22 | mjordan | I think anyone who looks at Stasis and says "I'll just replace that" will be surprised at how much work has gone on making Stasis work *for* Asterisk |
| 17:51.27 | mjordan | and all its peculiar edge cases. |
| 17:51.57 | file | writing something to connect the internal message bus to something external should not be hard at all |
| 17:52.03 | mjordan | see: corosync |
| 17:52.12 | file | just did it partially |
| 17:52.13 | mjordan | we even have a binary message format! |
| 17:52.22 | mjordan | and message formatters built natively into stasis message types! |
| 17:52.23 | mjordan | Or JSON! |
| 17:52.34 | mjordan | Or this strange key/value pair syntax ... |
| 17:53.30 | leifmadsen | yea, honestly anything you're going to drop on the bus you just want the raw data anyways, so if it is a binary blob or whatever it is, isn't an issue, because whatever is going to pull it off the bus is going to do the actual parsing and processing of the data |
| 17:53.58 | leifmadsen | so if you have the ability to just pick and choose what you're dropping on (or a "type", e.g. not-internal data) the bus, then it seems pretty straight forward |
| 17:54.30 | leifmadsen | you don't want any of the actual business logic or processing on the asterisk side, just access to the data |
| 17:54.33 | leifmadsen | whatever that data is |
| 17:54.47 | mjordan | yup |
| 17:54.53 | mjordan | looks for something real quick |
| 17:55.21 | mjordan | http://svn.asterisk.org/svn/asterisk/trunk/res/res_chan_stats.c |
| 17:55.36 | mjordan | This is a really good example of how easy it is to take data from Asterisk and pump it out to something else |
| 17:56.39 | mjordan | that gives you the total number of channels, as well as how long each channel was up, and sends the data out to a statsd server |
| 17:56.54 | mjordan | plus, it never touches the live channels. It's completely passive. |
| 17:57.00 | mjordan | Now, going the other direction is obviously much harder |
| 17:57.07 | mjordan | that is, you want to affect channels in Asterisk |
| 17:57.16 | mjordan | as the Stasis message bus is basically one way |
| 17:57.28 | mjordan | (which is another major difference from "generic" message busses) |
| 18:09.50 | *** join/#asterisk-dev oej (~Adium@185.32.9.250) |
| 18:09.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:22.14 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-ihmhgwbejozirfkw) |
| 18:30.36 | sgalarneau | for those who are interested, we are looking for feedback on a prototype voicemail application built with ARI and Node.js http://lists.digium.com/pipermail/asterisk-app-dev/2014-July/000514.html |
| 18:32.39 | opticron | would always welcome another review on https://reviewboard.asterisk.org/r/3812/ |
| 18:32.54 | file | sgalarneau, you have a tweet as well! |
| 18:34.48 | sgalarneau | file: just retweeted |
| 18:54.06 | skrusty | file: finally getting round to playing with Talk Detection in ARI |
| 18:54.45 | skrusty | updated my framework for 12.4.0 so events are included and modifying the sample conference application to pickup the new events |
| 18:54.52 | mjordan | cool |
| 18:57.27 | file | talk the talk, detect the not |
| 18:59.46 | skrusty | :) |
| 19:05.06 | leifmadsen | yay externalized apps! |
| 19:20.49 | skrusty | leifmadsen: :) |
| 19:21.20 | skrusty | i see someone posted a vm app to the list today also |
| 19:21.37 | file | yes, that sgalarneau dude posted a prototype |
| 19:22.34 | skrusty | all good! :) |
| 19:33.28 | mjordan | feedback on said prototype (emphasis: prototype) would be hugely appreciated :-) |
| 19:34.13 | leifmadsen | wait, I just put this into production |
| 19:34.31 | mjordan | lawl |
| 19:34.31 | leifmadsen | I am losing millons on this! I can't believe the Asterisk project would be so irresponsible! |
| 19:34.40 | mjordan | I believe I am entitled to compensation |
| 19:34.48 | leifmadsen | I am losing all my dailing minties! |
| 19:34.51 | mjordan | And I demand that the developers fix things for free |
| 19:35.04 | mjordan | we really should do a "quote and name that person" |
| 19:35.19 | seanbright | well that's a softball |
| 19:35.25 | leifmadsen | :D |
| 19:35.34 | mjordan | he really is a gold mine |
| 19:35.36 | leifmadsen | we just need a quotes page on the wiki |
| 19:35.37 | seanbright | immemorable. |
| 19:35.39 | pabelanger | Oh, so astricon moved to the Red Rock Resort |
| 19:35.43 | leifmadsen | moved? |
| 19:35.52 | pabelanger | Ya, no long near the strip |
| 19:35.56 | pabelanger | like 30mins or so now |
| 19:36.03 | skrusty | hehe :) |
| 19:36.18 | leifmadsen | I never put in a talk this year :( |
| 19:36.19 | leifmadsen | I waited too long |
| 19:36.24 | leifmadsen | luckily i get in for free anyways |
| 19:36.31 | mjordan | "free for life" |
| 19:36.43 | leifmadsen | s/life/Leif/ |
| 19:36.47 | skrusty | alright for some :) |
| 19:41.03 | file | the red rock has a shuttle back/forth from the strip |
| 19:41.15 | TazzNZ | hey all |
| 19:43.05 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 19:47.10 | file | hola |
| 19:51.14 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:51.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:56.00 | leifmadsen | file: I like this |
| 19:56.41 | leifmadsen | I would not want to be in the slot in the morning after the party |
| 19:57.19 | pabelanger | file, Yup, just some distance from it |
| 20:03.15 | mjordan | leifmadsen: no one likes that morning slot |
| 20:03.23 | mjordan | or really, the entire second day. WHoooo boy. |
| 20:03.41 | leifmadsen | late morning is ok |
| 20:03.42 | leifmadsen | just before lunch |
| 20:03.48 | leifmadsen | 11am is a good one |
| 20:03.56 | leifmadsen | most people are at least out of bed and downstairs by then |
| 20:04.12 | leifmadsen | the slot just after the slot after lunch is also good :) |
| 20:04.15 | leifmadsen | like 1:45pm |
| 20:04.30 | leifmadsen | I'm a bit of a pro when it comes to knowing the good speaking slots :) |
| 20:04.34 | leifmadsen | experience bwaaaaaaah |
| 20:05.03 | file | no drinking for meeeeee |
| 20:17.19 | leifmadsen | you're going to get pretty dehydrated |
| 20:18.13 | file | leifmadsen, as we are the same person you can do all the drinking |
| 20:18.22 | leifmadsen | FINE |
| 20:18.32 | leifmadsen | you can hydrate for us |
| 20:18.53 | mjordan | canada is only two people? |
| 20:19.02 | mjordan | I mean, I figured y'all had like, at least 3 |
| 20:19.03 | sgalarneau | nope! |
| 20:19.13 | sgalarneau | there are 3 yes |
| 20:19.22 | mjordan | sgalarneau: I forget, do you have dual citizenship? |
| 20:19.56 | sgalarneau | mjordan: yes |
| 20:20.26 | file | sgalarneau, ONE OF US! ONE OF US! (albeit tainted) |
| 20:20.28 | sgalarneau | I would have to write a formal letter to the Canadian government to renounce my citizenship |
| 20:20.55 | sgalarneau | file: I'm french, I was always tainted |
| 20:21.37 | mjordan | Wow. All of Canada is in this IRC room. |
| 20:21.57 | mjordan | file + leifmadsen == 1; sgalarneau +1, pabelanger +1 === 3 |
| 20:22.09 | mjordan | That's all of it. |
| 20:22.40 | leifmadsen | and if they're not, they're spies |
| 20:22.46 | sgalarneau | let's not forget shatner |
| 20:22.57 | mjordan | I'm not sure he's human |
| 20:23.06 | sgalarneau | he shares a home town with me |
| 20:26.50 | mjordan | sgalarneau: all that tells me is you are one of them |
| 20:26.52 | mjordan | *them* |
| 20:27.34 | sgalarneau | I am a hybrid: half my time spent there, half here, that balance will tip next year |
| 20:31.38 | pabelanger | Juggie, also Canadian |
| 20:31.58 | sgalarneau | Canadians++ |
| 20:33.02 | putnopvut | I'm not Canadian, but I was born in a state that borders Canada. |
| 20:33.19 | putnopvut | I have a contact taint |
| 20:33.38 | mjordan | putnopvut: me too! |
| 20:33.51 | sgalarneau | most Canadian provinces border the US |
| 20:34.08 | mjordan | Although we're much more in the realm of "the hand that threatens to swat Canadians back across the border" |
| 20:34.11 | sgalarneau | so most of Canada is tainted |
| 20:34.25 | mjordan | But most of the US probably isn't |
| 20:46.23 | file | rmudgett, I oppose the existence of the "bridge destroy" CLI command |
| 20:47.24 | putnopvut | In Stasis (as in the dialplan application), when a channel is removed from a bridge (either due to being kicked from the bridge or being removed via ARI), where, codewise, does this channel reside? I was under the impression that Stasis had an after bridge callback that it used, but I'm not seeing it if it exists. |
| 20:48.21 | rmudgett | putnopvut: It imparted the channel as DEPARTABLE. |
| 20:49.39 | putnopvut | Okay, let me rephrase. Is there a common portion of code that a channel falls back to after being removed from a stasis bridge? Is there some sort of holding loop that services frames or something? |
| 20:49.52 | mjordan | putnopvut: yes |
| 20:50.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 20:50.53 | mjordan | is looking for it |
| 20:50.57 | putnopvut | me too |
| 20:51.17 | putnopvut | perhaps stasis_app_exec in res/res_stasis.c? |
| 20:51.18 | mjordan | putnopvut: stasis_app_exec, res_stasis |
| 20:51.19 | mjordan | yes |
| 20:51.33 | mjordan | the control loops forever, waiting for commands to execute |
| 20:51.45 | mjordan | when you are removed from a bridge, that's an asynchronous command that is issued to the controller |
| 20:51.57 | mjordan | it just departs the channel from the bridge, which returns it to this loop |
| 20:52.09 | mjordan | hence why we have some magic 'bridge cleanup' code in there |
| 20:52.26 | mjordan | like, 'oh, hey, were you in a bridge? do you not want to be in one anymore? Let me unsubscribe you from that' |
| 20:52.36 | putnopvut | Excellent. Cool. |
| 20:52.43 | putnopvut | Thanks |
| 20:53.07 | mjordan | also... |
| 20:53.07 | mjordan | hm. |
| 20:53.15 | mjordan | methinks we should be calling ast_frfree after that ast_read in there. |
| 20:53.44 | mjordan | ew |
| 20:53.46 | mjordan | RAII_VAR. |
| 20:53.47 | mjordan | Nevermind. |
| 20:53.51 | mjordan | We should remove that RAII_VAR. |
| 20:53.58 | file | yes. |
| 20:54.14 | mjordan | that's overhead that is unnecessary... |
| 20:54.20 | mjordan | PROFILING! |
| 20:54.24 | mjordan | (some day, again) |
| 21:02.36 | file | rmudgett, what happens if you bridge destroy a ConfBridge or a Stasis bridge? |
| 21:04.08 | rmudgett | file: If you bridge destroy a ConfBridge all channels will leave and the bridge goes away. Stasis I'm not sure about but it probably isn't going to be aware that the bridge was dissolved out from under it. |
| 21:05.37 | file | so, same thing - with the difference being you could fix it by doing a DELETE on it in ARI |
| 21:08.28 | file | imo the "bridge destroy" CLI command should be only available in dev mode for testing, and a command should be available instead to kick all channels out of the bridge at all times |
| 21:12.41 | rmudgett | file: There is a "confbridge kick <participant|all>". There is a "bridge kick <bridge-id> <channel-name>". Could add an all to the bridge kick. |
| 21:15.00 | file | my point ultimately being: having the "bridge destroy" CLI command ultimately allows someone to put the users of bridges into a potentially undefined and useless state and thus should only exist for the purposes of development, while on the other hand a kick all is completely safe |
| 21:15.18 | file | unless they are paranoid. |
| 21:15.23 | file | (the users of bridges) |
| 21:15.51 | rmudgett | I supplied the rope. You can hang yourself with it if you want. :) |
| 21:16.23 | file | rmudgett, as your code review finding indicates - it's dictating how we have to think about and use bridges :P |
| 21:16.55 | rmudgett | file: ConfBridge didn't have to think about it because it naturally handles it. |
| 21:22.57 | file | by virtue of how it is implemented, yes |
| 21:31.02 | putnopvut | mjordan: opticron: out of curiosity, if a channel in a stasis bridge is AMI redirected to another CEP, does the channel currently exit Stasis? I would expect so, given how ast_async_goto() operates. |
| 21:32.09 | mjordan | I would expect so |
| 21:32.26 | putnopvut | Okay, so I don't need to try to probe into that as an issue then. |
| 21:32.27 | rmudgett | putnopvut: Yes it is a blind transfer and leaves the bridging system to goto the CEP. |
| 21:32.31 | mjordan | Although I'm not going to pretend like I've tested it |
| 21:32.34 | putnopvut | heh |
| 21:33.00 | putnopvut | I figured I'd ask since I'm not as intimately familiar with the "channel stays in stasis when we don't expect it to" situation as well as you guys :) |
| 21:33.07 | mjordan | I sometimes wonder if we shouldn't have had blind transfers just be handled by a control frame. |
| 21:33.11 | putnopvut | I can always test it myself, but I figured it's quicker to ask in case you already know. |
| 21:33.53 | putnopvut | They kind of are, at least in the context of the bridge. A bridge action is queued to perform the blind transfer. |
| 21:33.58 | mjordan | yup. |
| 21:34.02 | mjordan | I meant for apps as well. |
| 21:34.16 | mjordan | Hindsight! |
| 21:34.23 | putnopvut | The rest of the world sees it as a soft hangup with AST_SOFTHANGUP_ASYNCGOTO set. |
| 21:34.34 | file | mjordan, is bet served hot |
| 21:34.37 | file | wait... that's not right |
| 21:34.38 | mjordan | While I'm wishing for things, I'd like a clean separation between the control structure in the dialplan and the passing of media |
| 21:34.46 | putnopvut | And a pony |
| 21:34.51 | mjordan | with wings! |
| 21:35.02 | mjordan | "It's just software" |
| 21:35.14 | mjordan | laptop is acting up (again); I may eventually have to do something about this. |
| 21:35.15 | mjordan | reboot! |
| 21:36.04 | file | apparently I need to nudge him EVEN MORE about getting a new one |
| 21:38.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:38.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:59.29 | coreyfarrell | does anyone know why testsuite: ./run-local needs to use 'mktemp' to create it's temporary directory? It seems to me that only one instance can run on the system at a time, due to shared IP space. |
| 22:43.28 | coreyfarrell | wdoekes: ^^ if you are around that question was probably for you.. |
| 22:57.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:07.43 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-spyqgivromgeiixt) |
| 23:20.26 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 23:35.55 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:35.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |