Re: [asterisk-dev] Proposed Working Group Guidelines
On Fri, Dec 2, 2016 at 5:54 PM, Matt Fredrickson wrote: > Thanks for looking it over Leif, and for some of the general thoughts. > Let me digest your comments and figure out if there's anything > actionable I'd like to add to my original list :-) > > Hope you're doing well, > Matthew Fredrickson > > Sounds good! Feel free to ignore everything I'd said :) So far so good! Red Hat is pretty awesome, but I do miss Asterisk. Looking forward to what the community does going forward in this area! Take care! Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Proposed Working Group Guidelines
>From a first glance, this looks pretty good! I don't really have anything else to add to what you've got there. It's succinct, and doesn't seem overly complicated. I'd like to mention something like the OPNFV[1] project, which basically has a mandate to utilize OpenStack as an NFV platform, bringing together various projects in the NFV space, and essentially building out reference architectures for various situations. This might be style as well that would work well and help a lot of integrators get involved with building out more complicated scenarios while not having to really be worried about the core development aspects. It would also provide a nice platform where larger integration projects can be fused together to help understanding any gaps in functionality, or areas that could be simplified in a deployment scenario. Having a focus on working groups within the developer community I think makes a lot of sense, but perhaps an approach to building reference architectures in the open where several integrators could work together, would help steer the project going forward, and permit the community as a whole to have a better foundation for different styles of deployments. This would clearly be in addition to the working group concept for the developer community. For the meeting aspects, IRC is generally a pretty good venue, and the OpenStack project uses this quite a bit. There are meetbots[2] that allow the meetings to be recorded, action items taken, and areas of interest to be documented. I don't generally favour 'in person' vocal meetings for these types of situations because of both timezone restrictions, and the integration of people whose primary language isn't necessary English (or where accents can cause issues, etc). Plus it's hard to keep a long term record of the conversations without a secretary. Good luck! Leif. [1] https://www.opnfv.org/ [2] https://github.com/openstack-infra/meetbot On Fri, Nov 4, 2016 at 10:07 AM, Matt Fredrickson wrote: > Hey All, > > I've been thinking a lot about how working groups might work within > the context of the Asterisk project. Here are a few guidelines that I > have come up with governing working groups. Some of these guidelines > come from the Node project, as they have a lot of pre-existing > material on doing this. I deliberately avoided comprehensively > importing their structure and guidelines, but pulled from some of > their more essential core principles. > -- Leif Madsen http://www.oreilly.com/catalog/asterisk http://www.leifmadsen.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
This is getting to be an old thread, but the "magic" for adding multiple changes is as follows: * use your working branch * make changes * git commit -a --amend * save... * git review This way, the same branch, with the initial commit, will be preserved along with the same change ID. If you want to build upon an initial review, then you can do: * git checkout -b intial_changes * ...make changes and git review... * git checkout -b secondary_changes * ...make changes, git commit, git review... This will provide a second review, based upon the first one. If you need to change the first review, then that's fine. Follow the initial procedure with making changes, and then git commit -a --amend, along with git review. If upstream (master) changes, and you need to rebase, that's fine too. * git checkout master * git fetch upstream (assuming you've run a git remote add upstream ) * git rebase upstream/master * git review Then if you need to rebase the secondary patch, after rebasing your initial_changes branch, just rebase against origin/initial_changes, and run your git review again. This way, you can chain changes, and not have to duplicate work. As the reviews happen and you make changes, you just keep committing against the same change ID (which happens when you git commit -a --amend; git review), and eventually things get merged down from the initial branch to your secondary, tertiary, etc branches. Hope that helps. Let me know if you need any additional help... Leif. On Tue, Aug 23, 2016 at 5:45 AM, Joshua Colp wrote: > Dennis Guse wrote: > >> Hey, >> >> we adjusted the patch set (fftw3 is now a ifdef-ed). >> Precisely, these two commits have been modified (basically adding >> HAVE_FFTW3) >> >> https://gerrit.asterisk.org/#/c/3522/ >> https://gerrit.asterisk.org/#/c/3524/ >> >> Two questions: >> 1. It seems that we were working outside the commit tree by adjusting >> 3522 and 3524 - we pulled each one down using _git review -d _, >> applied the modifications, and submitted using _git review_ >> Is it necessary to also "re-commit" the subsequent patches (or does >> gerrit this automatically)? >> And if so, how? >> At the moment Gerrit does not try to rebuild the subsequent patches >> (i.e., 3523 and 3525). >> > > Gerrit does not automatically do this, it's up to you to rebase the > patches so that a review is rebased on the latest version of the one it is > dependent on. You can either do this from the web interface using the > Rebase button (if it will cleanly rebase) or you have to build up a patch > series on your system. This can be done by creating a local branch and > pulling down each patch into it using (git review -x ), making any > changes needed, committing, and doing git review again. This provides the > dependency information to Gerrit it needs. > > 2. How can we withdraw the OPUS patch from the patch set? >> https://gerrit.asterisk.org/#/c/3526/ >> > > You can click "Abandon" from the web interface and it will abandon that > specific review. > > Cheers, > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > Check us out at: www.digium.com & www.asterisk.org > > > -- > _____ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen http://www.oreilly.com/catalog/asterisk http://www.leifmadsen.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Usage of weak key algorithm on Gerrit
On Fri, Feb 26, 2016 at 5:43 PM, Joshua Colp wrote: > > This has been fixed. > I confirm said fixing. -- Leif Madsen http://www.oreilly.com/catalog/asterisk http://www.leifmadsen.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Usage of weak key algorithm on Gerrit
Apologies if this is a well known issue and I'm just stirring the pot :) Attempted to check out Asterisk from Gerrit today, and got a message I didn't recognize. >Cloning into 'asterisk'... >Unable to negotiate with 76.164.171.232: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 >fatal: Could not read from remote repository. > >Please make sure you have the correct access rights >and the repository exists. Quick search turned up the answer though. A weak key implementation on Gerrit (which my OpenSSH disables by default): http://www.openssh.com/legacy.html Workaround was to add to my ~/.ssh/config: >Host gerrit.asterisk.org >KexAlgorithms +diffie-hellman-group1-sha1 Perhaps this could be modified so that the key exchange is slightly more secure? It's all open source stuff here, so the exchange may not be THAT necessary, but might not be a bad idea :) Thanks! -- Leif Madsen http://www.oreilly.com/catalog/asterisk http://www.leifmadsen.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Plan for updating the ARI Swagger Version
On Wed, Feb 10, 2016 at 10:16 AM, Dan Jenkins wrote: > > > If that's the case, should we consider moving to another project? the JSON > API spec is pretty nice (1). Or open a dialogue with the swagger team now > that it's "Open API Spec" and see whether anything is going to change in > terms of how they update things? I completely agree with you on the not so > nice upgrade paths and breaking things within what I consider a minor > version bump. If we're going to stick with swagger/openAPI even though we > might not be fans of how they update the specification, then we can put > some time into helping upgrade the ARI interface but I'd rather think about > swapping out for another spec now rather than do the work and feel like > we're still painted into a corner. Sorry, I know that's a rather radical > move/statement but thought I'd put it out there. > > 1.http://jsonapi.org/ > > There is also http://raml.org/ as an alternative. (I personally like the JSON stuff better for APIs since it's easier to parse in Go.) -- Leif Madsen http://www.oreilly.com/catalog/asterisk http://www.leifmadsen.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Docker Containers: Phase 1
Absolutely! You would do that with an ENV (environment variable) setting in the Dockerfile. Once that was setup, you can override that at build time (basically you set a "default" value, and then you can override it from the docker build command when you're building the container image). So phase 1 is actually already dead. I've been busy working on a provisioning platform the last two weeks (on top of being sick), but I'm through enough of it that I should be able to get to my phase 2 blog post this week (ideally this afternoon). The preferred approach (as mentioned in my phase 1 blog post) is to actually base on an RPM package. One of the issues was just trying to deal with fedpkg (which is an awesome system btw) and getting custom changes, and whatever version of Asterisk you wanted. I've solved this with FPM and a companion container. More in the blog post, but basically the essence is that you run a docker build command in your local Asterisk source directory, it compiles it and packages it into an RPM that is stored back on your local host. Then you run one more docker build command to install that RPM into your Asterisk container image, and the result is your own custom Asterisk container image with your local mods (or custom menuselect flags, etc). It's pretty slick actually, and solves a lot of the problems I was having with my original approach. Thanks to Alan Graham who pointed out an excellent Git repo that builds the RPMs using FPM with minimal effort. Thanks! Leif. On Tue, Nov 24, 2015 at 5:26 PM, Corey Farrell wrote: > Leif, > > Thanks for explaining I should have read your blog post before replying to > Jared's email about the RPM's. I didn't realize EPEL was that strict with > version freezes to stay with a no longer supported version. > > I do not know too much about Docker yet but I took a look anyways. Can > variables be used in Dockerfile.asterisk? The idea is to be able to use a > new version of Asterisk without having to update the version on 40 lines. > Also when someone forks your GIT repo to add/remove packages from the > install list, they won't face 'git rebase' conflicts after you update the > version. > > Thanks, > Corey > > On Thursday, November 19, 2015, Leif Madsen wrote: > >> Hey Corey! >> >> The way it works is that major versions of Asterisk (and same with other >> packages) are associated with specific releases of Fedora and RHEL, which >> means the major versions are "stuck" to those releases. >> >> However, you can still build the newer version of Asterisk by pulling the >> spec file and sources from later Fedora versions (Fedora 23 for instance). >> >> You can rebuild the RPMs supplied using fedpkg, as I've done in phase 1 >> of my blog post. There are other ways you can do it was well, like with >> mock etc. >> >> (You'll need some dependencies in order to build everything). >> >> If you look at my buildit.sh script, it provides the primitives for >> building the dependencies. I'm doing this via a local build with rpmbuild >> (because the script is run in the Docker container), but you could also >> replace this with a fedpkg mock build which would build the RPMs in the >> chroot for you. There might be some things that are slightly more >> complicated in that method, because you'd have to get the resulting >> dependency RPMs into the chroot (possible, it's just not super straight >> forward if you haven't done it before). >> >> I'd probably still suggest doing it in the Docker container, simply >> because it's super simple to get things spun up. You can even use the >> local.repo file I'm providing as well. Basically everything you need to >> build Asterisk for your platform (Red Hat based) is in the repo linked >> above. >> >> Note: this won't work on CentOS 6. There are some oddities with CentOS 6 >> in Docker that resulted in me not being able to build Asterisk in the >> CentOS 6 container (gcc complained about not being able to result in a >> binary or something). >> >> Long story short, use fedpkg to build the RPMs from the Fedora >> repositories. Just clone the Fedora 23 version (which gets you Asterisk >> 13.3.2 as of now), and then build it on top of the system you want (CentOS >> 6 or 7 for example). >> >> Thanks! >> Leif. >> >> On Thu, Nov 19, 2015 at 2:23 PM, Corey Farrell wrote: >> > >> > Jared, >> > >> > I just looked through the EPEL website at EPEL6 and EPEL7, only found >> > Asterisk 1.8. Can you point me to the spec file you are using or an >> >
Re: [asterisk-dev] Asterisk Docker Containers: Phase 1
Hey Corey! The way it works is that major versions of Asterisk (and same with other packages) are associated with specific releases of Fedora and RHEL, which means the major versions are "stuck" to those releases. However, you can still build the newer version of Asterisk by pulling the spec file and sources from later Fedora versions (Fedora 23 for instance). You can rebuild the RPMs supplied using fedpkg, as I've done in phase 1 of my blog post. There are other ways you can do it was well, like with mock etc. (You'll need some dependencies in order to build everything). If you look at my buildit.sh script, it provides the primitives for building the dependencies. I'm doing this via a local build with rpmbuild (because the script is run in the Docker container), but you could also replace this with a fedpkg mock build which would build the RPMs in the chroot for you. There might be some things that are slightly more complicated in that method, because you'd have to get the resulting dependency RPMs into the chroot (possible, it's just not super straight forward if you haven't done it before). I'd probably still suggest doing it in the Docker container, simply because it's super simple to get things spun up. You can even use the local.repo file I'm providing as well. Basically everything you need to build Asterisk for your platform (Red Hat based) is in the repo linked above. Note: this won't work on CentOS 6. There are some oddities with CentOS 6 in Docker that resulted in me not being able to build Asterisk in the CentOS 6 container (gcc complained about not being able to result in a binary or something). Long story short, use fedpkg to build the RPMs from the Fedora repositories. Just clone the Fedora 23 version (which gets you Asterisk 13.3.2 as of now), and then build it on top of the system you want (CentOS 6 or 7 for example). Thanks! Leif. On Thu, Nov 19, 2015 at 2:23 PM, Corey Farrell wrote: > > Jared, > > I just looked through the EPEL website at EPEL6 and EPEL7, only found > Asterisk 1.8. Can you point me to the spec file you are using or an > SRPM? > > Thanks, > Corey > > On Thu, Nov 19, 2015 at 2:02 PM, Jared Smith wrote: > > > > On Thu, Nov 19, 2015 at 10:14 AM, Matthew Jordan wrote: > >> > >> Would it be appropriate to summarize the current state of things as "we > >> need a spec file for Asterisk"? > > > > > > > > At one point, there was an awful .spec file in the Asterisk sources... > > hopefully it's not around any more. > > > > That being said, I just took over as the main maintainer/contact for the > > Asterisk packages in Fedora/EPEL -- It's one of the most complicated spec > > files in Fedora, but that obviously hasn't scared me off. > > > > I'd love feedback on things we can do to make those packages better, and get > > a tighter feedback loop between the Asterisk development community and the > > packagers in Fedora/RHEL/CentOS/etc. > -- Leif Madsen Director of Engineering, Product Development http://avoxi.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Bug marshals back !
As far as I'm aware, bug marshals never went away. It's possible there has been less involvement than previously, but I'm not sure anything has ever happened to preclude a bug marshal from acting in the project. I believe Rusty Newton is kind of the "de facto" bug marshal, as he's been doing the job since I moved out of that role. Leif. On Wed, Nov 18, 2015 at 7:58 AM, Olle E. Johansson wrote: > Yay! > > I notice in a bug report that the response talks about a Bug Marshal. I > am very happy that we have bug marshals back in the process. Is there a > document somewhere outlining the process of becoming one and what they do > nowadays? > > Cheers, > /O > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen Director of Engineering, Product Development http://avoxi.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Docker Containers: Phase 1
On Thu, Nov 19, 2015 at 10:14 AM, Matthew Jordan wrote: > > > > >> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards > > wrote: >> >>> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards < >>>> asterisk@sedwards.com> wrote: >>>> > >>>> > On Mon, 16 Nov 2015, Leif Madsen wrote: >>>> > >>>> >> I wrote up a lengthy blog post that likely borders on ranting: >>>> >> >>>> >> >>>> http://blog.leifmadsen.com/blog/2015/11/10/asterisk-docker-container-phase-1/ >>>> > >>>> > >>>> >>> > Great blog post :-) > > Would it be appropriate to summarize the current state of things as "we > need a spec file for Asterisk"? > > Yes, that would be fair. Good thing Alan Graham pointed me at a project that will build one for us pretty simply from the source directory. I need to work on another blog post, but basically I have sorted out the main sticking points, and it doesn't require the Fedora .spec file at all. I'm trying to work with tools that will generate the package, simply for the purposes of getting it into the Docker container image (it's probably not appropriate for further distribution as a "de facto" image, but that's another problem to solve at another time). > > Just to address Steve's point: > > Packages aren't going anywhere. I do think we can all agree that the state > of Asterisk packaging could use some improvement, but that's a separate > discussion. > > Docker is another way to deploy Asterisk, that may or may not use > packages. (And as Chad pointed out, we're using Docker here at Digium for > that purpose.) As Leif mentioned in his blog post, there's definitely > benefits to using packages with Docker, as it reduces the size of the > Docker images. If the goal is to have a universally accepted Docker file > for the Asterisk project, then it probably make sense to use packages; that > would necessitate either having dependable packages for a variety of > distros, or include a .spec file with the project. > > Leif: Does that sound correct? > > Yes that does sound correct, and you're right that *my* goal is to provide a Dockerfile that can be shipped with the Asterisk source. In my adventures earlier this week, I found a project that uses Docker to package up the Asterisk source that you're running from (which means you can generate a package for the source you've modified, if that's your thing), and then use the resulting package as the basis of your Asterisk container image you're going to build. This is VERY useful when you start wanting to avoid having to modify spec files for every change you make, or every version of Asterisk, meaning that a good chunk, if not the entire process, could be automated. This is good news, because then the Asterisk project could actually use these files to generate "official" Docker container images. We're not that far yet, but I don't think we're far off. Hopefully tomorrow I can spend an hour or so working on a phase 2 blog post, and then start learning how to submit some files back to the project :) Here is a preview of the workflow (copy / pasta of the README.md I created): # Building Asterisk into a Docker Container Image Build the package container image. This uses FPM so no `spec` files and such are necessary. ``` docker build --pull -f contrib/docker/Dockerfile.packager -t asterisk-build . ``` Build the Asterisk RPM from the resulting container image. ``` docker run -ti -v $(pwd):/application:ro -v $(pwd)/out:/build -w /application asterisk-build /application/contrib/docker/make-package.sh 13.6.0 ``` Now create your own Asterisk container image from the resulting RPM. ``` docker build --rm -t madsen/asterisk:13.6.0-1 -f contrib/docker/Dockerfile.asterisk . ``` -- Leif Madsen Director of Engineering, Product Development http://avoxi.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Docker Containers: Phase 1
On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards wrote: > > On Mon, 16 Nov 2015, Leif Madsen wrote: > >> I wrote up a lengthy blog post that likely borders on ranting: >> >> http://blog.leifmadsen.com/blog/2015/11/10/asterisk-docker-container-phase-1/ > > > I've only read the first x paragraphs (I'll read more later), and I hope I'm not flying off the handle. > > I used to make source level changes for some of my projects. Fortunately, all the functionality I now need is provided by the RPMs. > > All of my current clients are 'from packages' and I'd hate for the results of the referenced poll to lead to the demise of the packages. I'm not sure what "demise" you're talking about. There is also no "poll" going on, but rather feedback on building containers for Asterisk in the most flexible way possible. Nothing that I'm doing will stop people from building packages, so I'm really confused by your statement. Not one thing I am proposing will change your workflow. -- Leif Madsen Director of Engineering, Product Development http://avoxi.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk Docker Containers: Phase 1
== Overview == Hey all, I've been working on ways of producing Asterisk Docker container images since AstriDevCon when it was brought up as a pretty fundamental aspect of what a lot of integrators are doing. In AstriDevCon room alone, I believe there were at least 5 separate organizations that had taken an approach to building Asterisk Docker container images, probably much of which was overlapping functionality. I spent a good chunk of time going through and figuring out an initial solution to building Asterisk container images (can I just call them ACI now?). There are some things to get us there, but primarily it centres around building them from packages. But what packages? And what happens when I have a change I want to make to the source and get that into my own container? I wrote up a lengthy blog post that likely borders on ranting: http://blog.leifmadsen.com/blog/2015/11/10/asterisk-docker-container-phase-1/ Primarily I wanted to get as many thoughts down as I had encountered recently to build the story around some of the "gotchas" that surround this space. Let me try and distil it for the list though. == What's completed and outstanding == * there is an Asterisk 13.3.2 container image[1] that is the result of fedpkg per the Fedora project * it is the result of two Dockerfile; the first builds the RPMs, and the second builds the ACI from those RPMs[2] * it does *not* yet build from local source (a goal) * it is not ready for inclusion in the Asterisk project due to some more research == Goals == The primary goals of the container project (from my viewpoint) include: * reproducibility * low to zero infrastructure burden outside of being able to run docker commands * ability to check out Asterisk source, make modification to the source, run a couple commands, and result in a custom container image with those local modifications * small container image for distribution purposes for those without custom modifications == What's next == Next up is to gather feedback, even if it is silence. I will take silence to mean "great job, keep going!", "I don't care what you're doing", or "I have no idea what you're talking about; keep going!". Perhaps my approach is wrong. I would love to hear why that might be, and what should be done about that. Maybe I'm making things too complicated, or there is another project I should be aware of so that I'm not duplicating work? Overall, the idea here is to provide the files required to result in Asterisk container images for people to consume, without having to put a burden on the Asterisk project to build out infrastructure to build and host RPMs simply to make the building of container images available (although a nice side effect of this might be that building RPMs and other packages may be significantly easier if there is still a desire to have "official" packages, but my gut tells me it's not really necessary). I would love to hear what you're up to with Docker, and what issues you've had with building container images, and how this project might be able to help move a lot of this work into a more centralized location. [1] https://hub.docker.com/r/leifmadsen/asterisk/ [2] https://github.com/leifmadsen/asterisk-docker-builder -- Leif Madsen Director of Engineering, Product Development http://avoxi.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] contrib/realtime sources
https://wiki.asterisk.org/wiki/display/AST/Managing+Realtime+Databases+with+Alembic On Fri, Oct 9, 2015 at 7:28 PM, Joshua Colp wrote: > On 15-10-09 08:22 PM, James Cloos wrote: > >> "JC" == Joshua Colp writes: >>>>>>> >>>>>> >> JC> Schemas are now managed using alembic[1]. They exist within the >> JC> contrib/ast-db-manage directory. >> >> There are no sql files therein. >> > > That's correct, they are produced as part of the release process itself > and not kept under version control. What produces the schemas is alembic. > Alembic can also be used directly against a database. > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > Check us out at: www.digium.com & www.asterisk.org > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > -- *Leif Madsen* Director of Engineering, Product Development -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Mon, Jun 8, 2015 at 9:35 AM, Russell Bryant wrote: > On Tue, Jun 2, 2015 at 8:05 PM, Matthew Jordan wrote: > >> Personally, I'd like some way to present any user of Asterisk with a >> > one-time only, non-annoying "please help the project and opt in" >> question, and then move on forever. Unfortunately, I don't have a good >> idea on making this suggestion work. If the only way to opt in is to >> provide a .conf file and set "enable = true", then I can't see >> anywhere near sufficient numbers of people being aware of the >> configuration choice, much less making the choice to enable it, to >> justify the creation of the module itself. >> >> If someone has a good proposal on making the suggestion work, then I'd >> love to entertain it further. >> > > I feel that "opt-out" is fundamentally wrong from a privacy perspective. > Further, I think the potential backlash and resulting damage to the project > is pretty severe. > > I also don't think "opt-in is hard" is an acceptable reason not to do it. > If it's too hard to make an opt-in solution useful, then maybe it shouldn't > be done at all. This sort of thing really doesn't seem very common, and > this is probably a big reason why. > > One alternative would be to issue periodic user surveys that are promoted > on the mailing lists, twitter, etc. I don't think you'll ever get a > reliable "absolute numbers" measure. A survey could still produce useful > relative numbers and help identify some trends over time. > First, I think the idea of a quarterly survey makes a lot of sense. You would probably get a bunch of useful information in one go rather than a slow trickle of information. You could also make this something people do on the website when downloading Asterisk from there. Other projects I've seen this on (Bower for example), do it during the installation process. The way I would picture this working with the Makefile is that you provide a prompt with a Y/N selection asking if you want to opt-in. If someone wants to automate this process, provide a flag option that allows them to --opt-in or --opt-out in order to provide a selection while also skipping human input. Then you can "override" that compiled in default with the below suggestion. Around the configuration file approach (which I think is also useful for those wanting to override the default compile time option, which will be selected during SOME sort of compile time process, whether that be on the machine, or during the package creation process), I would expect it to be a file provided via the 'make samples' option. Then on the console when you connect, you could provide output that looks similar to the following: $ asterisk -r Asterisk 1.8.11-cert9, Copyright (C) 1999 - 2012 Digium, Inc. and others. Created by Mark Spencer Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. = Connected to Asterisk 1.8.11-cert9 currently running on localhost (pid = 4364) Verbosity is at least 5 Asterisk Beacon: Enabled (see core show help beacon) *CLI> With a separate configuration file and module, you could then provide the following option: beacon set opt in beacon set opt out This would then write out to the configuration beacon.conf with enabled=yes or no and reload the module. Thanks, Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] OFF TOPIC: GitHub vs. BitBucket vs. GitLab
My experience with workflow is to have Gerrit as the gatekeeper of the code, which then handles the code review and merges it into whatever Git repo you want (I've previously used it with GitHub, recently with a private locally hosted repo). Can you elaborate on what you're having troubles with? Sounds like your workflow might just be more complex than it needs to be. Either way, if you use Gerrit, it merges to the approach branches for you and rejects it if it can't be merged cleanly (and needs to be rebased against the branch it's trying to merge to etc). It's really pretty straight forward. We don't allow direct merging, only Gerrit is allowed to merge. Leif. On 18 January 2015 at 08:32, Nir Simionovich wrote: > Hi all, > > This is somewhat of an off topic discussion, however, I'm putting it > here - as most of your have more experience than me when it comes to using > git. > > So, we've been using GitHub for a year now as our Git repository and are > fairly happy with it. At the same time, we're using BitBucket for some of > our projects, specifically those who are not of Open Source nature. > > Recently, I've become frustrated with both platforms - specifically when > it comes to managing code within teams - specifically when code reviews are > required from multiple entry points - code review becomes longer than > actual coding. > > So, I was wondering what you guys are using and working with? You are > welcome to answer this off-list, but I do believe that some of us may > benefit from the discussion. > > Nir > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] asterisknow-version
On 27 December 2014 at 19:15, Matthew Jordan wrote: > If that doesn't work for you, I'd suggest making your own packages. > > This is what we've ended up doing. I took the SRPM file from the Fedora repository and hacked the SPEC[1] file to suit my own needs. It only builds what I need now, and does it in a way that I expect. From there, I then pump it and the dependencies into mock[2] and it spits out the resulting RPMs for me. I even built a wrapper bash script that lets me pass in arguments such as build number and Asterisk version so that I have a single RPM spec file that I can pass various bits of info into. From there I added it to our Jenkins[3] server and now commits that are merged via Gerrit[4] automatically build in Jenkins and are pushed to our Pulp[5] server for distribution to our various data centres. [1] http://pkgs.fedoraproject.org/cgit/asterisk.git/tree/ [2] https://fedoraproject.org/wiki/Projects/Mock [3] http://jenkins-ci.org/ [4] https://code.google.com/p/gerrit/ [5] http://www.pulpproject.org/ -- Leif Madsen -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] git migration update
On 22 December 2014 at 18:34, Russell Bryant
wrote:
> On Mon, Dec 22, 2014 at 3:08 PM, George Joseph <
> george.jos...@fairview5.com> wrote:
>
>> On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau > > wrote:
>>
>>> 2 - we have a few options as far as team branches go. We could configure
>>> user branches using refs/heads/team/${username}/* permissions in Gerrit to
>>> allow users to create branches. This would prohibit other users from
>>> pushing to a user branch, but they would still be visible. This would most
>>> likely involve reproducing some sort of automerge/autorebase process. The
>>> other option is to use github as another remote for team branches, with a
>>> remote pointing to Gerrit for code reviews. Is there a preference between
>>> these two approaches, or perhaps a better setup we could follow?
>>>
>>>
>> I don't think there's any need for you to host users' repos any more.
>> It may have made sense for SVN but I don't think it does for GIT. Let
>> users make their own arrangements be it GitHub or in my case, my own GIT
>> infrastructure.
>>
>>
> +1. I don't think it makes sense with git. github or whatever should
> work just fine for that purpose.
>
>
>
Another +1 here. The beautiful thing about git is that you're not going to
need to do that. Anyone can use whatever git method they want (local,
github, stash, etc) and just rebase against the origin branch with a
remote. If people want to work together, then there are various ways of
doing that, one of which github makes incredibly straight forward.
--
Leif Madsen
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
On 18 December 2014 at 11:07, Paul Belanger wrote: > On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich > wrote: > > New question: Do we want to enable legacy features inside ARI? > > > New answer: I don't believe so. > > I think this issue / question is the hardest thing to understand about > ARI. There really isn't any sort of link to existing Asterisk > application or features; not yet any ways. Somebody has to build it > again a top of ARI. > > When I first dreamed of using ARI I was looking at it from a > configuration management tool mindset. Oh, I could create a new peer > in chan_sip over HTTP or let me reconfigure features.conf using ARI. > However, as I started playing with it more I found that was not what > it did. And, changing it to do something like that doesn't feel like > the right approach. > > Now, that being said. Creating some sort of interface to control > sorcery objects, now that would be cool. Having sorcery connect to > redis and change key / values directly in redis for sip peers would be > hotness. However, I'm not sure I would want to have Asterisk serve up > that interface directly. Feels more like an external application > would serve up the REST interface into redis, allowing the user to > change key/pairs. > > I also believe, until there are some standard ARI libraries / > application (for example app_dial replacement). It will feel like a > large task to build anything in ARI, because some of the core > application basically need to be written from scratch. And I think > this is the main reason people are slow to move to ARI or fearful from > dropping the dialplan. Because doing: > > exten => s,1,NoOp() > same => n,Dial(SIP/f...@example.org) > > is a lot easier then origination a channel over ARI, creating bridges > and playing any tones needed using ARI. Easier might not be the right > work, more steps required is. > I also agree that we do not want to start making ARI start talking to legacy applications. As discussed at AstriDevCon, the push is really to start making Asterisk a media communications platform. The way to do that is to move away from the dialplan centric driven applications and to move to a decentralized model of applications and business logic being separated from Asterisk, and essentially making Asterisk much dumber in terms of the actual business logic and routing logic, and making it a lean mean media communications machine. The way forward sometimes is to stop looking back. Currently both AMI and AGI are still happily co-existant in Asterisk, and should be considered the defacto interface to traditional methods of writing Asterisk business logic (dialplan, etc). When flipping to ARI, it is a different mind set that does take some time to get around. Much like Paul I had my own preconceived notions about what ARI was and was initially disappointed it didn't match what I thought it should have been. However over the last few months of watching what Paul has been doing along with some small side POC stuff to better understand what ARI is intended for, it definitely has become a lot clearer. At the most basic levels, ARI to me is a bridge control interface that allows you to hook channels together while not worrying about transcoding, media characteristics etc. You have two or more channels that may or may not speak the same language, and your external applications stick them together, and Asterisk acts as the universal translator for those channels. By writing all your business logic and controls outside of Asterisk, it makes the API much simpler to interoperate with, and allows great scaling possibilities. Admittedly I'm still a bit naive on a lot of the ARI front, but one thing my gut tells me, is it is a new interface, and should not be confused as a replacement to the legacy (term used loosely) methods of building Asterisk systems. This is one of those situations that I feel avoiding legacy and backwards compatibility with the traditional methods is going to really open up a better realm of possibilities with ARI. If someone truly just needs an HTTP based interface for controlling dialplan and such, I feel a translation application (library) should just be written for AMI and AGI that permits that and has that goal. Overloading what ARI is supposed to be doing is a step backwards in my opinion. -- Leif "The Dialplan Is Dead" Madsen -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] FW: Asterisk Developers Mailing List
Yea, that link looks legit. That does not look legit at all. On 28 November 2014 at 00:58, marcotasto wrote: > http://epub-libros.com/sygd/advmxukdydrcqjcqjjrhygqyduj.bfeumhcymiqdaxiaer > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
On 16 November 2014 at 17:34, Matthew Jordan wrote: > On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen > wrote: > > Would it also make sense to require new features be listed in the CHANGES > > file for the point release? I don't want to add lots of work here, but > when > > you're developing against a major version release and new features are > going > > to be added, it would be great to have a go to spot (rather than browsing > > all the ChangeLogs) for new features in case those deploying want to > rebase > > their work against a new point release in order to get a set of features. > > Yup! We faced this with Asterisk 12 as well. To handle it for that > version, we > did the following: > * CHANGES files were updated for each point release with the new features. > As an > example, you can see the new features that went into 12.2 here: > > http://svn.asterisk.org/svn/asterisk/tags/12.2.0/CHANGES > > At the same time, we don't really know which version people will be > using when > they upgrade to the next major version. A feature may be introduced in > 12.5.0, > and a person upgrading from 12.3.0 to 13.0.0 would not be aware of it. > Since > all new features are also merged into trunk, new feature are listed as > being > 'new' in the first major version as well. > * Release announcements for point releases also include an 'improvements' > and > 'new features' section, which correlate to the issue type in JIRA. The > announcement for 12.5.0 is a good example: > > > http://lists.digium.com/pipermail/asterisk-announce/2014-August/000552.html > > As well, the announcements made on asterisk.org also call out the > different > types of issues included in the release: > > > http://www.asterisk.org/downloads/asterisk-news/asterisk-1250-now-available > > Beyond that, I'm not sure what else we should do - other than encourage > people > to write wiki pages for new features when they are developed. > > I think this is perfectly reasonable. Thanks! > > Last thing, regarding the old text block of "Asterisk 12 is Different" > that > > explains that changes are allowed towards the goals of that version; I > think > > it would be a good thing to have another similar block of text for > Asterisk > > 14. While the new policy is certainly more relaxed than the "no new > > features", I also don't think it goes quite far enough for Standard > releases > > whereby larger architecture changes appeared to be allowed within the > > Standard release, at least where required to support the lofty goals of > > Asterisk 12. I understand Asterisk 14 goals haven't been finalized, but > this > > is something to keep in mind for this page in the future. > > I had thought about having something like that on there, but I'm not quite > sure > how to phrase it in a fashion that is globally useful as a policy. The > section > earlier on the page does call out the differences between the two release > types. > Also, we do call out that certain features aren't appropriate for an LTS > release > on the new feature guidelines page: > > https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines > > The Roadmap, as well, calls out the goals for a particular version that > were > decided upon at AstriDevCon: > > https://wiki.asterisk.org/wiki/display/AST/Roadmap > > So the information may all be there, if on a few different pages. Maybe > links > to the appropriate pages would be sufficient Perhaps? I'm not exactly sure how to phrase it either. I suppose this was the general consensus at AstriDevCon, but I wonder how we go about making it a little more clear. What is there now I think is sufficient, and those working on the project every day have a pretty good idea around what is acceptable. Thanks! Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
; it must be removed from the release. > > Hopefully, this strikes the right balance of allowing the project to > keep pace with end user's needs, without introducing substantial risk > into release branches. > > The full text of the proposed process changes has been made to the > Software Configuration Management Policies page on the Asterisk wiki > [2], with the proposed text put side-by-side with the existing text > for comparison. If we reach a consensus that this is a "good thing", > I'll remove the old text. > > Thoughts? Concerns? > > [1] > http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html > [2] > https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies > > -- > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] The state of Asterisk (new topic)
On 8 November 2014 07:18, Olle E. Johansson wrote: > > On 28 Oct 2014, at 17:44, Russell Bryant > wrote: > > > I said this in my talk last week and will reiterate it here. I think the > Asterisk dev community has been doing an amazing job over the last few > years. Internal refactorings have been achieved that we used to dream of. > A new SIP channel driver finally exists. The new API work just totally > rocks. It's an absolutely critical piece of what is needed from Asterisk > to fit in to the way future telephony applications should be architected in > my view. > > Well done, dev community. Keep kicking ass. > > I do agree with Russell here. We're making enormous progress and see > changes we've been discussing for years actually happening. > It's fantastic. > > I wish to add a Thank You to Digium for financing most of this work. I do > hope we can come up with a cooperative > way of producing code in the future to make it easier to work together and > get new code in. > > > I'm confused by this statement. What kind of cooperation is not already been achieved here? What barriers cause you to feel that you're not able to contribute in a meaningful manner already? Sure, I want to see tools that make it easier to contribute (who doesn't?) but what do you perceive as non-cooperative in the present model? -- Leif Madsen -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AstriDevCon 2014: Agenda itemDeprecate AMI/AGI(Ben Klang)
On 22 October 2014 14:55, Paul Albrecht wrote: > > On Oct 22, 2014, at 11:31 AM, Matthew Jordan wrote: > > This is an open source project. Communication is done in an open, > transparent manner. People should feel like they can bring up interesting, > radical, and yes - even crazy - ideas. > > > By the same token, when you propose ideas, you must be prepared for honest > criticism and accept it in graciously rather than simply resorting to > argument ad hominem. > I don't think that word means what you think it means. > > If you don't like that, you don't have to participate in the discussion. > > > You haven’t really responded to the substance of my post, that is, is > asterisk abandoning the dial plan? > Someone proposed an idea during the devcon. Nothing has been decided or even discussed yet. What you're reading and freaking out about is simply a list of ideas mentioned during the devcon, and noted in a document. That's as far as it has gotten; a list of minutes you're reading without further context based on actual participation in the conference itself. Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Queue discussion at Astricon
Your encouragement is noted and discarded. See you all at AstriCon! :) On 17 October 2014 16:00, Billy Chia wrote: > There will actually be an opportunity to grab a beer at the Hackathon > Reception in the same room as AstriDevCon immediately following AstriDevCon > on Tuesday (Cherry Lounge 5PM - 7PM) > (and as always we encourage people to partake responsibly during > opportunities where beers will be offered at AstriCon) > > More info: http://astriconhackathon.challengepost.com/ > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP Configuration Wizard (Was: Opinions Needed: PJSIP Outboud Registration with multiple server_uris)
My gut tells me no, mostly because if you're using the realtime interface, you're most likely inserting the records programatically (which I believe is your point). Of course having functionality in one method and not another is always somewhat annoying, but in this case, I think the point of the wizard is to limit the amount of typing and complexities in setting up PJSIP right? When you start getting into realtime, you're already into a more complicated abstraction layer, and the ability to understand the various components of your deployment are probably assumed. Leif. On 7 October 2014 12:10, George Joseph wrote: > Although the ast_sorcery_* API doesn't expose it, an object can be mapped > to multiple wizards, right? What if the compound object was stored in, and > retrieved from, one of the concrete wizards but the objects it creates are > created in a memory wizard that's added to the object_type's wizards > container. > > Unfortunately, this doesn't address the real time aspect of realtime. If > you make a change to the backing compound object data store it's not > automatically propagated to the created objects. This brings be back to > my question above... If you're using realtime are you likely to even need > the wizard approach. > > I'm still thinking. > > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP Configuration Wizard (Was: Opinions Needed: PJSIP Outboud Registration with multiple server_uris)
Agreed. I also much prefer the second proposal as it is more intuitive to how you would expect the configuration to look. Templates ftw. On 2 October 2014 13:45, Brad Watkins wrote: > As we talked about in #asterisk-dev, I like the proposal generally and > prefer the second style specifically. Just as a matter of eventual > documentation, it'd be nice to see examples using a hierarchy of templates > that shows how to minimize duplication of configuration. > > - Brad > > On Wed, Oct 1, 2014 at 8:54 PM, George Joseph > wrote: > >> This is a followup to the discussion we had in this thread... >> Opinions Needed: PJSIP Outboud Registration with multiple server_uris >> <http://lists.digium.com/pipermail/asterisk-dev/2014-September/070426.html> >> >> I started with wanting to allow multiple server_uris in a single >> registration object but where we wound up was with the creation of a new >> module that would provide a configuration layer on top of the existing >> pjsip configuration mechanism. The purpose of the layer is to make >> configuration of the most common pjsip scenarios, and the transition from >> chan_sip, easier. As a happy side effect, it also allows easier >> manipulation of pjsip contifuration from scripts and AMI. >> >> Basically, the new module creates a 'wizard' object that lets you >> configure common scenarios like 'phone' and 'trunk' with a single object >> rather than defining a separate endpoint, aor, identify, auth, >> registration, etc. It does NOT replace or alter the existing object >> model. The wizard in fact just creates all the normal objects behind the >> scenes. >> >> Showing examples will be much easier than trying to describe it. >> >> PJSIP Configuration Wizard Proposal 1 >> <https://gist.github.com/gtjoseph/f11e1cdf261d93ef5516#file-pjsip_wizard_1-conf> >> PJSIP Configuration Wizard Proposal 2 >> <https://gist.github.com/gtjoseph/e09978f8085091513115#file-pjsip_wizard_2-conf> >> >> The difference between the 2 proposals is that the first one actually >> defines types called 'trunk', 'phone', and 'phone-static' which are used >> later in the config. After staring at it a while though I thought there's >> really no benefit to the types if you use templates. Hence the second >> proposal which I favor. To see the real benefit of the whole approach, >> look down at sections starting at [myitsp]. >> >> I know there are going to be questions and controversy so fire away! >> >> george >> >> >> >> >> >> >> >> >> >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-dev >> > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Confbridge Performance using G722 @ max 3 Party in 1 conference.
Why not just use another Asterisk machine that you front with SIPp? Trigger the channels from SIPp into Asterisk box A, have that box call Asterisk box B via G.722, then you can measure the performance of Asterisk box B. Asterisk box A would just be a transcoder essentially for you. Leif. On 29 September 2014 16:35, bala murugan wrote: > hi , > > Has anyone tried measuring the asterisk (10 or 11 or12) performance > against the Confbrdige Application using G722 HD codec with atleast 3 party > in 1 conference . If yes can you please provide me what tool was used to > measure this performance , it is hard to get a tool that supports g722 . > I appreciate your help on this. > > thanks, > B > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Git Migration
I'm not adding much to the conversation, other than to echo both Russell and Paul that what they've described works very well. At Thinking Phones we moved to this same model as well from a subversion based system. The management of our reviews (which didn't exist really before) and the deployment of code, automatic merging, and integration into GitHub for branching and pull requests. The fact that Openstack is essentially managing the tools for you is kind of nice too :) I can give some feedback at AstriCon on what we like and don't like as well, especially since I have some familiarity with the Asterisk release process :) Leif. On 18 September 2014 20:06, Paul Belanger wrote: > On Thu, Sep 18, 2014 at 5:12 PM, Russell Bryant > wrote: > > On Thu, Sep 18, 2014 at 3:01 PM, Samuel Galarneau > > > wrote: > >>> > >>> > >>> A couple more comments about the magic happening here ... > >>> > >>> First, "git review" knows where to push based on a file checked in to > the > >>> repo: > >>> > >>> $ cat .gitreview > >>> [gerrit] > >>> host=review.openstack.org > >>> port=29418 > >>> project=openstack/nova.git > >>> > >>> "git review" also sets up a local commit hook that adds a "Change-Id" > >>> header to your commit message. That Change-Id is what links multiple > >>> revisions of the same change together. So, if you edit your change > and push > >>> it again, as long as the Change-Id remains the same, gerrit treats it > as the > >>> same review request and not a new one. > >> > >> > >> Sounds good to me. So it doesn't really matter from which repo you post > a > >> review so long as it's a clone of the original with that .gitreview > file. > >> > >> I have another question unrelated to reviews. Does your setup make it > easy > >> to mirror a repo? In a more complicated scenario, what if someone had a > >> private fork but they wanted to get public commits to master mirrored > to > >> their repo? Would they have to treat the original repo as upstream and > >> manually pull changes and rebase their private branch off of it? > > > > > > Mirroring, sure. I don't remember exactly how we do it, but all > OpenStack > > repos are mirrored to github for convenience, for example. > > > Technically, the repos on github for Openstack are the mirrors of a > mirror, I know :) > > The basic idea is the upstream repo lives either in gerrit or zuul, > then can mirror the repos to any system. Thing to remember, everything > goes through gerrit and zuul. So, if you mirrored to github, PR are > useless since it is only read-only. > > For internal projects, I host a cgit server and public I just mirror to > github. > > > Regarding private branches, git generally makes that kind of thing > > ***MUCH*** easier than svn. You can easily track the exact commits that > are > > applied on top of upstream. You could either periodically rebase your > > changes on top of upstream (re-applying the commits, rewriting history > but a > > cleaner history), or periodically merge from upstream. In either case, > I > > personally wouldn't automate it. You want some sanity checking around > that > > stuff. Conflicts happen. Really, I think this is going to be MUCH > better > > no matter what specific infrastructure you go with. > > > > -- > > Russell Bryant > > > > -- > > _ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > asterisk-dev mailing list > > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Leif Madsen CoreUC Lead Systems Engineer p: +1-613-800-7610 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3438: Implement SIP TImer C in Asterisk
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3438/#review11904 --- I just opened ASTERISK-23746 which would have been "helped" by a Timer C. We ran the same test through OpenSIPS and things tore down correctly because of the availability of Timer C there. Not sure if this particular review would have helped, but at least it provides an example of a situation where Timer C could have helped with port exhaustion. Of course the issue also identifies a problem with what Asterisk is doing as well, so this would not be the solution, but would certainly have helped. - Leif Madsen On May 16, 2014, 12:32 p.m., Olle E Johansson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3438/ > --- > > (Updated May 16, 2014, 12:32 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > SIP Timer C is defined for proxys that forward messages. In some ways, we > forward calls. It is activated when we receive a 100 trying and wait for any > other message. If that's not received, timer C triggers and cancels the call > attempt. > > This is required in an interoperability test I'm working with. > > Red dots will be handled in the way they deserve. > > > Diffs > - > > /trunk/configs/sip.conf.sample 414046 > /trunk/channels/sip/include/sip.h 414046 > /trunk/channels/chan_sip.c 414046 > /trunk/CHANGES 414046 > > Diff: https://reviewboard.asterisk.org/r/3438/diff/ > > > Testing > --- > > Passed interoperability testing with funky test tool. > > > Thanks, > > Olle E Johansson > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3300: Don't crash on lack of bridged rtp instance
> On March 6, 2014, 9:20 p.m., Mark Michelson wrote:
> > I'm not a fan of this change, because I think it's not really fixing the
> > root problem. bridge_p2p_rtp_write() is called in only one place in
> > res_rtp_asterisk.c, and it's called like this:
> >
> > /* If we are directly bridged to another instance send the audio
> > directly out */
> > if (ast_rtp_instance_get_bridged(instance) &&
> > !bridge_p2p_rtp_write(instance, rtpheader, res, hdrlen)) {
> > return &ast_null_frame;
> > }
> >
> > In other words, before entering bridge_p2p_rtp_write(),
> > ast_rtp_instance_get_bridged() was returning non-NULL. So something is
> > NULLing out the pointer between its initial check and the call to
> > bridge_p2p_rtp_write(). This means that adding a second check for the same
> > thing is likely not to actually catch the problem and instead just make the
> > crash happen less often.
> >
> > Looking at the linked issue, the crash is occurring outside of bridging
> > code, when a channel is read from in app_dial(). My guess is that this
> > channel had been RTP bridged but was yanked out of the bridge via a
> > masquerade and thrown into the dial application. The dial application
> > attempted to read from the channel before the previous local bridge loop
> > had finished with the channel, thus resulting in crashiness.
> >
> > The crash on the linked issue seems to verify this. The crashing thread has
> > channel 0x7f5e943a3cc0 being read from while simultaneously in thread 7380,
> > the same channel is part of a masquerade that occured as a result of a SIP
> > attended transfer.
I have to agree, and have to thank you for your analysis of the situation. For
now this patch may help us stabilize some of our platform, but I definitely
would prefer to figure out what the underlying problem is.
We just had another crash today with the same type of issue. What else can I do
to help debug this further?
- Leif
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3300/#review11120
---
On March 5, 2014, 6:49 p.m., Russell Bryant wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3300/
> ---
>
> (Updated March 5, 2014, 6:49 p.m.)
>
>
> Review request for Asterisk Developers and leifmadsen.
>
>
> Bugs: ASTERISK-23419
> https://issues.asterisk.org/jira/browse/ASTERISK-23419
>
>
> Repository: Asterisk
>
>
> Description
> ---
>
> This bug shows a crash in bridge_p2p_rtp_write(). There is no bridged rtp
> instance so it goes boom. The patch just catches the case and returns. I'm
> not really sure *why* there's no bridged instance, but this seems like a
> pretty safe function input sanity check.
>
>
> Diffs
> -
>
> /tags/1.8.18.1/res/res_rtp_asterisk.c 405155
>
> Diff: https://reviewboard.asterisk.org/r/3300/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Russell Bryant
>
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3279: Iterate through logger.conf [general] section
> On Feb. 28, 2014, 12:51 p.m., Matt Jordan wrote: > > I'm not sure I understand the need for this patch. > > > > Setting a configuration option twice - when that option doesn't support > > being set multiple times - would generally have undefined behaviour. Your > > patch changes it so that Asterisk reads the last defined value, as opposed > > to the first. How is that better? It's better when you want to deploy Asterisk in a DevOps environment. What happens is you define the "default" behavior in the main file that gets deployed. From there you then override that behavior in an included file which is defined and built via DevOps (usually through a template of some sort that contains information for the particular machine you're deploying). The example is not a good one, because obviously you would never deploy the file in the example provided. ; logger.conf [general] queue_log=no #include logger.conf.d/logger.conf.local ; logger.conf.d/logger.conf.local [general] queue_log=yes ; we've deployed a queue server, so enable queue logging Primary example of it in use available at https://github.com/kickstandproject/kickstandproject-asterisk/tree/master/templates/etc/asterisk - Leif --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3279/#review10991 --- On Feb. 28, 2014, 1:44 a.m., Paul Belanger wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3279/ > --- > > (Updated Feb. 28, 2014, 1:44 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch allows you to override the [general] section of logger.conf, > making it the same functionality as the [logfiles] sections. > > > Diffs > - > > trunk/main/logger.c 409111 > > Diff: https://reviewboard.asterisk.org/r/3279/diff/ > > > Testing > --- > > local development. Setup > > [general] > queue_log = no > queue_log = yes > > Queue logfiles were created. > > > Thanks, > > Paul Belanger > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3186: AMI Security Events: document the events; add optional IEs to the events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3186/#review10783 --- Ship it! Other than the s/, security/, 'security'/ in the CHANGES file, this looks good to me! - Leif Madsen On Feb. 5, 2014, 10:51 p.m., Matt Jordan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3186/ > --- > > (Updated Feb. 5, 2014, 10:51 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch: > (1) Adds optional IEs to the AMI events. The optional fields are documented > as not being required. > (2) Adds documentation for all of the Security Events. > > > Diffs > - > > /branches/12/main/security_events.c 407401 > /branches/12/UPGRADE.txt 407402 > /branches/12/CHANGES 407402 > > Diff: https://reviewboard.asterisk.org/r/3186/diff/ > > > Testing > --- > > Tests that use the AMI events in the testsuite continue to pass. > > Tested documentation through the CLI. > > > Thanks, > > Matt Jordan > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] devicestate
> > I agree for real devices. However i wonder - why i can't change state > for Local channels. > > Funny enough, I had this same issue today within Queue(). I'm using queue_member in extconfig.conf (realtime members) which delivers calls to a Local channel which then finds the physical location in the cluster and delivers the call there. The problem I was having was that when the Local channel would be ringing a device, the device status was set to (Unknown), which would cause that same device to be called multiple times when there were multiple people waiting in the Queue(). Once the call was answered the status changed to In Use, and then everything worked as expected. I had a patch made that caused Queue() to not deliver calls to members with a status of Unknown -or- In Use, and that solved my problem for now, but not entirely sure what issues I'll run into in the future because of it :) Leif Madsen. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] app_addon_sql_mysql maintenance
Tony Plack wrote: > Just wondering if this list supports modifications to the > app_addon_sql_mysql.c code. Please post your changes to a bug in bugs.digium.com. Thanks! Leif Madsen. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] extensions.conf included contexts priorities
On Tuesday 24 April 2007 20:26:25 Jared Smith wrote:
> On 4/24/07, Steve Murphy <[EMAIL PROTECTED]> wrote:
> > Trouble is, is this desired behavior? Or is having the contexts checked
> > level by level until a match of any kind is found, the better procedure?
>
> Well, I for one desire the current behavior. Everyone else can speak
> for themselves, but it makes it easy to override an extension included
> in a more-deeply-nested extension by putting its replacement in a
> less-deeply-nested context. If they were all pulled together into one
> big ball of wax, we'd lose a lot of functionality.
I also agree here. If you change this functionality, people who depend upon it
might come find you and do not such nice things to you :)
> Here's just one example of the many ways I use the current behavior.
>
> [long-distance]
> exten => _1NXXNXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})
> include => local
>
> [local]
> exten => _NXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
> exten => _1NXXNXX,1,Dial(no-permissions-to-make-this-type-of-call)
Or this:
[long_distance]
exten => _1NXXNXX,1,Dial(IAX2/${UPSTEAM}/${EXTEN})
exten => h,1,Verbose(1|This would actually get hit, and not the _. pattern)
include => match_all
[match_all]
exten => _.,1,NoOp()
exten => _.,n,Playback(cant-let-you-do-that)
Only the order of includes should matter, and not where they are placed in the
dialplan in relation to extensions in the same context.
Leif.
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RealTime, Large Dialplans, and headaches... got any ideas?
On Tuesday 27 March 2007 19:16:10 Nicholas Campion wrote: > You could create another table in the database that would hold the last > write times of these tables. Create a separate table with the columns > "table name" and "mod date", then create or modify the wrapper which you > use to write information to the RT tables to, before they write to the > appropriate real time table, update the time in the mod access time for > that table to the current time. Then, when a call comes in, check that > table entry and see if it needs to be reloaded. > > I don't know if that makes this a good idea, but it seems possible. I know this isn't really the solution at all, but just the whole premise of extensions.conf in realtime doesn't really seem ideal. I've found func_odbc to be much more flexible and dynamic, and not require reloads, plus it doesn't have this problem with large databases. Probably doesn't help a lot, but in my experience, func_odbc seems to be the better way to go when wanting to databaseitize your dialplan. Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] BRIDGE the Existing twocall
On Monday 19 March 2007 13:21:25 Wai Wu wrote: > I just redirect both calls to an extension the leads to a meetme > conference. The issue with that is if you want to transfer the call again (I used app_bridge to simulate mutli-lot call parking in a vPBX environment), it fails because you're trying to transfer the entire conference (or something to that effect). By simply bridging the two calls together, you don't lose any functionality. Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Parsing in Asterisk
On Monday 19 March 2007 12:24:33 Philipp Kempgen wrote: > >> I'd probably be only half as confused if my favorite text editor > >> had syntax highlighting for Asterisk's .conf and .ael files. :) > > > > Maybe you should be using vim. > > http://www.voip-info.org/wiki/view/vim+syntax+highlighting > > Thanks for the pointer. vim is ok but i prefer BB-Edit > / TextWrangler on my Mac. > But let's not start a religious war. :) I use vim without syntax highlighting because I'm a masochist. It's just a matter of getting comfortable with how the dialplan works I guess. Although I have seen vim with syntax highlighting... it is nce. Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Parsing in Asterisk
On Monday 19 March 2007 10:28:11 Philipp Kempgen wrote: > Leif Madsen wrote: > > On Tuesday 13 March 2007 13:25:11 Steve Murphy wrote: > >> On Mon, 2007-03-12 at 14:33 -0600, Tilghman Lesher wrote: > >>> exten => s,n,Set(ODBC_TEST3(foo)=123\,\\"456\,789\\"\,012) > > What I miss most is "real" strings as you know them from other > languages - quoted in single or double quotes with escaping > only being necessary for the quotes themselves (and maybe > chars in hex notation). > > exten => s,n,Set(ODBC_TEST3(foo) = 123, "456,789", 012 ) > > And it's really unusal to *write* to functions. Something > like this would be my favorite: > > ODBC_TEST3( "foo", [123, "456,789", 012] ) Actually I would disagree with that. The format for writing a value to a function is quite logical if you understand other parts of Asterisk dialplan logic (i.e. it's intuitive). The format you proposed, to me, is confusing and counter intuitive. Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RE: [asterisk-users] deprecated - CLI help vs. source code
On Tuesday 27 February 2007 05:21:51 Philipp Kempgen wrote: > Bala Neelakantan wrote: > > Usage of LookupBlackList is deprecated. This means, the usage will work, > > but there is no guarantee that it will work in future. You might want to > > try using BLACKLIST() instead. > > Is this always true? Is the CLI help potentially outdated? > I don't expect the average user to look at the source code > to find out if something is deprecated. When things are deprecated, this is always true. It means a better alternative is available than the original implementation of the functionality. It should not be necessary to view the source code to realize something is deprecated, but sometimes things get missed. It is unlikely the development team would remove functionality from Asterisk without any sort of warning. It looks like Tilghman fixed this in r56922 in the 1.4 branch. So this is resolved. Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] CLI filtering
On Thursday 18 January 2007 12:54, Clod Patry wrote: > Im aware that all ast_log and ast_verbose will have to receive a pointer to > the ast_channel. That bored job is almost done at this point. > That patch is > 24 000 lines just for ast_log and without any channel > drivers changed for now. > > > The second idea is to filter per session. When you have 2 persons in the > CLI, if one person is doing a RTP debug, the other one will be like WTF! so > it's to separate all that. > > I know a lot of person will say we could debug via log files and via > ethereal, but that knowledge isnt given to all * users (like we all know). > That stuff will be really simple to use I'm fully in support of such an idea and have wanted that functionality for quite some time! Let's take back the CLI! Leif Madsen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Question about uniqueid
On Thursday 07 December 2006 07:13, dmb wrote:
> The sipcallid not solve my problem. I show you the problem with an scenario
> (example):
>
> 1.SIP/1005 calls to 102 queue. That generate a call with uniqueid:
> 1165492430.2
> 2.In app_queue.so a second call is delivered to agent/5004. That call
> has uniqueid 1165492431.0 (in that step a new channel is generated without
> relation with channel in step 1)
> 3.In app_queue.so a third call is delivered to local/1004. That call
> has uniqueid 1165492430.3 (in that step a new channel is generated without
> relation with channel in step 1).
> 4.When SIP/1006 answers the call a link is produced with uniqueid
> 1165492430.2
>
> You can see that the uniqueid in 1. and 5. is the same uniqueid, but from
> 2. to 3. the uniqueids are diferents and the channels for that steps
> havent got any field to relation the current call with the call in step 1.
> I need obtain the uniqueid 1165492430.2 in steps 2 and 3.
Try this:
Set(__UNIQUENUM=${UNIQUEID})
Then you should be able to access the original unique ID across channels as it
is now inherited inside the ${UNIQUENUM} variable.
Leif Madsen.
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Agent withdrawal codes for PauseQueueMember
On Sunday 03 December 2006 23:43, Lucas Barbuto wrote: > I didn't do a careful job, but it worked as a proof-of-concept. I'd > appreciate it if anyone could suggest if I'm going about this in a > reasonable way and if it's a feature that might likely be accepted > for merging into the 1.12 branch. I could then try to tighten up the > code and submit a patch. FYI, features never go into a release branch, only into trunk, so unfortunately your feature can't make it into releases 1.2 or 1.4. Leif. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 1.2.13 under FC6 - chan_phone.c wants compiler.h
On Tuesday 28 November 2006 18:56, Juan Carlos Castro y Castro wrote: > ...a header file I understand it's deprecated. I solved the problem by > eliminating chan_phone from channels/Makefile, but what is the real fix? > Just removing the #include in chan_phone.c? > > gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT > -D_GNU_SOURCE -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS > -fomit-frame-pointer -Wno-missing-prototypes -Wno-missing-declarations > -DZAPATA_PRI -DIAX_TRUNKING -DCRYPTO -fPIC-c -o chan_phone.o > chan_phone.c > chan_phone.c:41:29: error: linux/compiler.h: No such file or directory > make[1]: *** [chan_phone.o] Error 1 > make[1]: Leaving directory `/usr/src/asterisk/asterisk-1.2.13/channels' > make: *** [subdirs] Error 1 You are correct, and 'file' has fixed it in all the branches as of revision 48087-48089 for 1.2, 1.4, and trunk branches. The fix was simply to remove it as we never really needed it. Leif. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Loss of functionality with depreciation of DBGet/Put?
On 5/16/05, Kevin P. Fleming <[EMAIL PROTECTED]> wrote:
> exten => 100,1,Set(temp=${DB(CFIM/200)})
> exten => 100,n,GotoIF(${temp} = "" ? novalue)
> exten => 100,n,...
> exten => 100,n(novalue),...
I've been trying to figure out the best way of replacing the DBget()
n+101 functionality in the IRC channel - thanks to MikeJ, jsmith and
drumkilla for the help. I don't like the idea of having to set a
temporary variable, so here's a possibly better way of handling the
n+101 syntax (works like the ${DIALSTATUS} channel variable for the
Dial() application).
exten => 100,1,Set(DB(foo/bar)=blah)
exten => 100,n,GotoIf(${EXISTS(${DB(foo/bar)})}?:novalue)
exten => 100,n,...
exten => 100,n(novalue),...
Also of interest is that you don't actually need the GotoIf()
application at all, replace with:
exten => 100,n,Goto(${IF(${EXISTS(${DB(foo/bar)})})}?:novalue)
Nope, you won't get any argument from me that the syntax is ugly and
error prone - however the use of functions is very powerful and a
great addition - but I hate the syntax :)
--
Leif Madsen
http://www.leifmadsen.com
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] [PATCH] busy detect toneonly typpo
On Tue, 11 Jan 2005 03:18:08 +, Julian J. M. <[EMAIL PROTECTED]> wrote: > Hello, Regards Julian! > I'm new to this list. My name is Julian J. M., and i've been playing > with asterisk and a Digium TDM400P (TDM11B) for 2 weeks... I've had > problems with busy detect, here in Spain. According to some cisco > documentation, here are the diferent signals reported by the telco: The formal way to apply for a patch to be submitted is via the bug tracker at http://bugs.digium.com. Once you sign up, read the bug submission guidelines. There is also a disclaimer to sign, so read the two versions and pick the one which makes you most comfortable. Hope this helps, Leif Madsen. http://www.leifmadsen.com ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] RFC: Moderating the Asterisk Mailing Lists
On Fri, 7 Jan 2005 10:42:03 +, Brian Wilkins <[EMAIL PROTECTED]> wrote: > If the project is ongoing, why are the docs on the www.asterisk.org website > outdated? The Asterisk Handbook: Second Draft was last published in March, > 2003! Unfortunately, the guys at Digium are busy working on other things - like coding Asterisk. I can understand their dilemma in not being able to contribute more to the documentation effort. However, there is documentation which is updated fairly regularily in the source code. And of course, there is always the source itself (which I admit to not really knowing all that well - but that will soon change as I become more involved with the newly forming development group). > I don't think the list is the problem, it's simple lack of good, solid > documentation. Newbies will always have questions, but we can't blame them > for asking when a lot of the information on the wiki is outdated, plus we > don't even have a recent handbook published. Look at the mysql website > (another open source project), they have loads of documentation and it is > easily searchable. Well, the MySQL project has been around a lot longer than the Asterisk project. Plus, I'm pretty sure they have a lot more funding. More $$$ means more docs and code. The wiki is a damn good resource, and I'd like to think the Docs project is a decent resource as an introduction as well (although I do agree that its a bit sparse, but we are working on that). The documentation that exists now is also easily searchable. Just type site:voip-info.org into Google before your search phrase. Works fantastic. BTW: Have you submitted documentation to the Wiki or Docs project lately? :) Thanks, Leif Madsen. http://www.leifmadsen.com ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk Source Code Intensive - Proposal for Astricon
Brian West said the following in another thread: > Leif and I have done one on one code/doc writing line by line in some cases. And Jim Van Meggelen said in another thread: > You know what, if we could pick an app and pick the brains of the dev > team as to what it does, we could possibly have a weekly conference call > of, say and hour or two, go through it line by line, and document the > code as the minutes of the meeting. Nothing heavy, just a few lines per > night - no more than an hour. Betcha we'd end up with an awesome amount > of source code comments. Once started, it'll become much easier to > maintain. I think this is a fantastic idea. Have someone "in the know" lead the conference call, have someone dedicated to the actual writing of the documentation (someone with fast typing skills), and the others would participate in the conference either as silent observers or actively speaking. Certain people will obviously choose how to participate. As Brian said... start at A and document to Zed. Thanks, Leif Madsen. http://www.leifmadsen.com. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk Source Code Intensive - Proposal for Astricon
Originally posted in was RE: [Asterisk-Dev] Bug Tracker / Feature Requests (my take) On Mon, 3 Jan 2005 01:24:23 -0500, Jim Van Meggelen <[EMAIL PROTECTED]> wrote: > I'd truly love to get my head deeper into that stuff. Actually, when you > said ". . . this looks like our chance to get involved . . ." the first > thought that popped into my head was "yeah, we can document the source > code, like every good programmer should" Funny enough bkw mentioned the same thing tonight on the conference. I think going through and documenting the code would be a great way to learn it, and help to lower the learning curve for those who come after. Thanks, Leif Madsen. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk Source Code Intensive - Proposal for Astricon
On Mon, 3 Jan 2005 01:25:43 -0500, Jim Van Meggelen <[EMAIL PROTECTED]> wrote: > For everyone who was ignoring the pimpking thread, it has matured rather > tamely into something more constructive. Therefore, it made sense to me > to start a new, relevant thread. > > The idea was suggested that a one day seminar on the source code be > presented at Astricon. Sort of an extremely condensed tour of the > source, lovingly delivered by someone sufficiently sadistic to enjoy > such an activity. Kinda like a poetry reading. I still believe this to be a very good thing(tm) for Astricon. Someone also suggested a monthly or quarterly voice conference. While that may be a bit ambitious for something that hasn't happened yet, someone doing a presentation at Astricon would set a good base on which to base new quarterly meetings off of. This would provide the initial momentum and make sure someone creates a good base of knowledge in docs and slides (since they'd be doing it for a presentation... which I know makes me work a bit harder and take it more seriously :)) My one suggestion would that it NOT include any questions DURING the presentation, but only at the end. If people have questions or comments, they should write them down or remember them for the end so that the presentation is guarenteed to be completed and not taken off course. I can very well see it becoming a disaster if that were to happen. > BKW, naturally, pretty much volunteered. Of course he did :) My feeling is that because he started right at the beginning without knowing code, he'd probably be able to remember some of the first issues he had to figure out, plus he's an entertaining presenter :) > Anyone else feel like they want to contribute to the code, but feel > overwhelemed about were to begin? > > Perhaps the lack of contributors is due to the fact that many feel > unqualified to help, even though willing (I'd count myself in that > category). It'd be interesting to see if a "source code boot camp" would > help folks overcome their initial hesitation. It sure is a steep > mountain of knowledge to conemplate, when one is standing at the bottom. > > Of course, I'm not sure if having a bunch of untrained hacks descend on > the code is exacly what's needed, but everyone has to start somewhere. > > Thoughts? Hey, maybe there will be a lot of untrained hacks, but if even 1% of those which try out become active, valuable developers to the project, you've expanded the number of active developers. That is also a good thing(tm). Your thoughts are right in line with Russell's thoughts in his post to the mailing list. I would encourage you to reply and get involved as you always seem to have a lots of thoughts some of them are even good! :D Thanks, Leif Madsen. http://www.leifmadsen.com. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk Maintenance Crew
On Mon, 3 Jan 2005 01:15:31 -0500 (EST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have seen a lot of people ask in #asterisk for a "to-do" list or help > for how to get started with development, but I never had a good answer for > them. I'm hoping that we can come up with a way to provide an entrance > point for aspiring Asterisk developers. I think this would be a great portal to start including these types of people. > If we were to maintain the list of feature requests, I'm not sure it would > need to be that complicated. I think a page of feature requests could be > simple and wiki-style. If someone were to want to tackle the > implementation, the discussion could happen on this mailing list. Hrm, interesting. I'd like to see something a bit more structured than a wiki page though. Something that certain people could "sign up" to work on the bug where people can submit a patch, and have people test and submit comments much like happens in the bug tracker. Although perhaps a wiki might not be a bad idea where once a patch was created it just got submitted to the bug tracker... ? > I appreciate your input. Like I said in my original email, my first goal > for this group is to help with maintaining the stable branch by porting > patches. I also think that there is a lot of potential for recruiting > developers by providing a place with various options of ways to get > started. Well, I'd be quite interested in helping in any way I can. Just let me know what I can do to help! > In that same spirit, I think having a page full of users' feature requests > would fit right in. Agreed. The beginning of ADP^2? :) Thanks, Leif Madsen. http://www.leifmadsen.com. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
