Re: [asterisk-dev] Jira / Gerrit Integration Issue
Thanks. I’ll probably be digging in a bit later on today on this. Sent from my iPhone > On Jun 11, 2021, at 10:08 AM, George Joseph wrote: > > > Oh, If you want to build the plugin, you'll need the Atlassian Plugin SDK > that matches our Jira version (6.2.6) > You can get it from here... > https://marketplace.atlassian.com/apps/1210993/atlassian-plugin-sdk-tgz/version-history > > Untar it in /opt, then prepend "/opt/atlassian-plugin-sdk-6.2.6/bin" to your > path. > > You have to use the atlas-* tools to build, most of which are just wrappers > around maven. > atlas-compile and atlas-package will do it. > > > > > >> On Thu, Jun 10, 2021 at 10:37 AM George Joseph wrote: >> >> >>> On Thu, Jun 10, 2021 at 10:00 AM BJ Weschke wrote: >>> I’d be willing to take a look at it for you George. >> >> A Volunteer!!! THANKS! I didn't think anyone would respond so soon. :) >> >> Basically, the plugin uses the >> com.sonyericsson.hudson.plugins.gerrit.gerrit-events package to communicate >> with Gerrit. That in turn uses the com.jcraft.jsch library both through >> gerrit-events and directly. The gerrit-events package has since been split >> out of the old hudson/jenkins space into >> com.sonymobile.tools.gerrit.gerrit-events and that's actively maintained and >> is what Jenkins currently uses. I _think_, _possibly_, that moving the >> jira-gerrit-plugin from the old gerrit-events to the new gerrit-events might >> just fix the issue but I can't be sure.The plugin also has the >> capability to update Gerrit but we don't use that bit. It may then be >> easier to just change the plugin to use the Gerrit REST interface for the >> query stuff. The plugin already has configuration settings for gerrit url, >> username and password so why it doesn't use the REST interface already I'm >> not sure. Anyway, take a look and let me know what you think. >> >> https://github.com/MeetMe/jira-gerrit-plugin >> >> >>> >>> Sent from my iPhone >>> >>>>> On Jun 10, 2021, at 11:31 AM, George Joseph wrote: >>>>> >>>> >>>> >>>> You already know about the SSH host key issue related to the upgrade of >>>> Gerrit we did on May 28th.That issue we knew about in advance so we >>>> gave everyone advance notice. Well, we discovered another issue related >>>> to SSH but this one was after the fact... >>>> >>>> We use a Jira plugin to display open Gerrit reviews for issues. This >>>> plugin is quite old and we discovered last Tuesday that it was using SSH >>>> Key Exchange Algorithms (kex) that are also quite old and known to be >>>> insecure. With the Gerrit upgrade, those older kex algorithms were >>>> removed so Jira was no longer able to log into gerrit via ssh and retrieve >>>> the reviews. >>>> >>>> So we actually have two issues... First Gerrit really messed up with >>>> their release notes because there was absolutely no mention of the >>>> implications of their upgrading their SSH backend. I've taken that up >>>> with them. Second, the Gerrit plugin for Jira really needs an update but >>>> it's not well maintained and although we could fix it, we're not exactly >>>> overstaffed right now. The Gerrit team did agree to re-enable the older >>>> kex algorithms in their 3.4.1 release but that only helps us in the short >>>> term as they will eventually be deprecated for good. >>>> >>>> So while we should have the integration working again shortly, we're still >>>> not sure what to do in the long term. Would any of you with Java >>>> experience be able to take a look at the jira-gerrit-plugin[1]? It's >>>> actually not that complex but it needs its SSH backend (com.jcraft.jsch) >>>> replaced. If any of you are interested, let me know and I can give you >>>> the details. >>>> >>>> [1] https://github.com/MeetMe/jira-gerrit-plugin >>>> >>>> >>>> >>>> >>>> -- >>>> George Joseph >>>> Asterisk Software Developer >>>> direct/fax +1 256 428 6012 >>>> Check us out at www.sangoma.com and www.asterisk.org >>>> >>>> -- >>>> __
Re: [asterisk-dev] Jira / Gerrit Integration Issue
I’d be willing to take a look at it for you George. Sent from my iPhone > On Jun 10, 2021, at 11:31 AM, George Joseph wrote: > > > > You already know about the SSH host key issue related to the upgrade of > Gerrit we did on May 28th.That issue we knew about in advance so we gave > everyone advance notice. Well, we discovered another issue related to SSH > but this one was after the fact... > > We use a Jira plugin to display open Gerrit reviews for issues. This plugin > is quite old and we discovered last Tuesday that it was using SSH Key > Exchange Algorithms (kex) that are also quite old and known to be insecure. > With the Gerrit upgrade, those older kex algorithms were removed so Jira was > no longer able to log into gerrit via ssh and retrieve the reviews. > > So we actually have two issues... First Gerrit really messed up with their > release notes because there was absolutely no mention of the implications of > their upgrading their SSH backend. I've taken that up with them. Second, > the Gerrit plugin for Jira really needs an update but it's not well > maintained and although we could fix it, we're not exactly overstaffed right > now. The Gerrit team did agree to re-enable the older kex algorithms in > their 3.4.1 release but that only helps us in the short term as they will > eventually be deprecated for good. > > So while we should have the integration working again shortly, we're still > not sure what to do in the long term. Would any of you with Java experience > be able to take a look at the jira-gerrit-plugin[1]? It's actually not that > complex but it needs its SSH backend (com.jcraft.jsch) replaced. If any of > you are interested, let me know and I can give you the details. > > [1] https://github.com/MeetMe/jira-gerrit-plugin > > > > > -- > George Joseph > Asterisk Software Developer > direct/fax +1 256 428 6012 > Check us out at www.sangoma.com and 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 -- _ -- 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] Module Deprecation, Default Not Building, and Removal
Makes sense to me! Sent from my iPhone > On Nov 9, 2020, at 8:24 AM, Joshua C. Colp wrote: > > >> On Tue, Oct 13, 2020 at 7:55 AM Joshua C. Colp wrote: > >> Hey all, >> >> I just wanted to drop an email and say that this hasn't been dropped or >> anything. A 2 year option just isn't something I want to rush into without >> thinking through all the ripples, which since we're approaching AstriDevCon >> and AstriCon is something that occurs here and there at the moment. :D > > I'm back, back again. Josh is back. Tell a friend. > > After giving further thought to things and the opinions presented I think we > can safely try a 2 year approach since we have a notification mechanism in > the form of a standard release and notice in minor releases with the ability > to receive feedback from the community. This means the process would be: > > 1. Minor releases receive change to indicate that module is to be deprecated > in a future major release > 2. Module is marked deprecated and defaultenabled no in standard release > (19), which carries over to next LTS release (20) > 3. Announcement and documentation for each includes notice of deprecated > modules > 4. Standard release after this it is removed (21), which carries over to next > LTS release (22) > 5. Announcement and documentation for each includes notice of removed modules > > A wiki page would be kept to keep track of modules in process of being > removed, as well as history to show when things were actually removed. > > Since this is the first real time formalizing this once all the things are in > place (process documented on wiki, deprecation list created from existing > state of things) I'll likely send out an email to -users and also post on the > community forums so people are aware. > > Sound good to everyone? > > -- > Joshua C. Colp > Asterisk Technical Lead > Sangoma Technologies > Check us out at www.sangoma.com and 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 -- _ -- 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] Module Deprecation, Default Not Building, and Removal
I don’t think anyone would have suggested beginning any process of removal of the chan_sip module when development of chan_pjsip first began. In fact, the discussion and decision of deprecation of chan_sip didn’t come about until AstriDevCon 2018 which occurred nearly 27 months after that July 2016 milestone. (https://www.asterisk.org/astridevcon-2018-a-recap/) Sent from my iPhone > On Oct 1, 2020, at 5:03 PM, משרד GIS מערכות תקשורת > wrote: > > > as per my experience with systems built on top of asterisk not just vanilla > asterisk it took like 4 full years from starting implantation for pjsip > starting at Mon, 04 Jul 2016 12: > >Added PJSIP tables and started integrating itFirst round of changes to > >introduce PJSIP... wow... it will be a huge blood bath, for start, you need > >asterisk 13.10 and chan_sip is not usable on 13.10. Stay tuned for next > >releases > till recently on, > 11 May 2020 00:55:54 +0200 >Added a way to mass change the tech for > extensions from chan_sip to PJSIP and back. It is available on > Configuration/Extensions page > > and still fixing bugs 94 fixis in four years when doing major changes 4 > years is needed minor stuff could go faster > > think of all the guys who are running asterisk the last 5 years and need a > complete change you need time plan sometimes the latest os when you have just > another integration crm which for now can work only with the older os etc > >> On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp wrote: >>> On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke wrote: >> >>> Four years, is indeed, really long. I do agree with this. As an example, I >>> work with another project where the work involves some integrations with >>> software that is in the head units of vehicles. Right now, they’re working >>> to certify and lock down code and functionality for the 2023 vehicle model >>> year which will hit dealer lots for the first time in just about two years >>> from now. Once final certification occurs, in the vast majority of cases, >>> nothing changes and the vehicles roll off the assembly line with the >>> integration that was certified. If software that is involved in the >>> manufacturing of vehicles can manage change risk within a two year window, >>> it only seems reasonable that the Asterisk project should be able to do the >>> same. >> >> From the development side we certainly can. The question is really - is it >> fair to the Asterisk user base, will they they accept it, will there be >> substantial backlash? The answer could be its fine. I don't really have a >> concrete answer though at this moment and likely wouldn't until put into >> action. >> >> For a 2 year strategy I think it would go as such: >> >> 1. Minor releases receive change to indicate that module is to be deprecated >> in a future major release >> 2. Module is marked deprecated and defaultenabled no in standard release >> (19), which carries over to next LTS release (20) >> 3. Announcement and documentation for each includes notice of deprecated >> modules >> 4. Standard release after this it is removed (21), which carries over to >> next LTS release (22) >> 5. Announcement and documentation for each includes notice of removed modules >> >> A wiki page would still be kept to keep track of modules in process of being >> removed. >> >> Note that I'm just putting this out there so people see in comparison to the >> other one what the process would be like. >> >> -- >> Joshua C. Colp >> Asterisk Technical Lead >> Sangoma Technologies >> Check us out at www.sangoma.com and 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 > -- > _ > -- 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
I’d personally be OK with this. The more I think about this, two years is really long enough. With your approach below, someone would have an entire LTS release cycle to make any necessary integration changes that come as a result of a module that is removed. If someone complains about defaultenabled no in the LTS release of which it is set that way, it seems to me that it is unlikely that same person would pay attention to any other documentation telling them that they had an integration issue to address even if they had two more years to do so. On October 1, 2020 at 3:55:19 PM, Joshua C. Colp (jc...@sangoma.com) wrote: From the development side we certainly can. The question is really - is it fair to the Asterisk user base, will they they accept it, will there be substantial backlash? The answer could be its fine. I don't really have a concrete answer though at this moment and likely wouldn't until put into action. For a 2 year strategy I think it would go as such: 1. Minor releases receive change to indicate that module is to be deprecated in a future major release 2. Module is marked deprecated and defaultenabled no in standard release (19), which carries over to next LTS release (20) 3. Announcement and documentation for each includes notice of deprecated modules 4. Standard release after this it is removed (21), which carries over to next LTS release (22) 5. Announcement and documentation for each includes notice of removed modules A wiki page would still be kept to keep track of modules in process of being removed. Note that I'm just putting this out there so people see in comparison to the other one what the process would be like. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and 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-- _ -- 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] Module Deprecation, Default Not Building, and Removal
Four years, is indeed, really long. I do agree with this. As an example, I work with another project where the work involves some integrations with software that is in the head units of vehicles. Right now, they’re working to certify and lock down code and functionality for the 2023 vehicle model year which will hit dealer lots for the first time in just about two years from now. Once final certification occurs, in the vast majority of cases, nothing changes and the vehicles roll off the assembly line with the integration that was certified. If software that is involved in the manufacturing of vehicles can manage change risk within a two year window, it only seems reasonable that the Asterisk project should be able to do the same. On October 1, 2020 at 3:15:12 PM, Dan Jenkins (d...@nimblea.pe) wrote: I'd argue two years isn't exactly quick... Especially with warnings on previous minor releases after decisions have been made. 2 years is fair - 4 is just too long. But if everyone else feels like 4 is fine then I'll stop my protest ;) On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, wrote: On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins wrote: If there was an additional message attached to minor releases, does that mean we can accelerate the steps? On the question of why I'm opposed to 4 years? 4 years is an eternity to be in limbo - we've already seen this with chan_sip - even though its deprecated in 17, people still start using Asterisk today and use chan_sip because they don't know any better and a crap load of documentation out on the internet uses it. If the modules are deprecated, they're deprecated for a reason - kill them as quickly as reasonably possible and be done with it - it'll help everyone in the community long term. If someone disagrees with say getting rid of chan_sip then they can continue to run 17/18 or whatever - or they can take the contents of chan_sip, and apply them as a patch themselves. I'm picking on chan_sip here because its the current thing that caused these conversations in the first place. Okay, so you'd like to see it be faster because in your opinion its better for the user base long term to force the transition quickly. I think I personally hesitate to be so aggressive because long ago the project was that way. We would push to remove things faster and such, and the result was upset people and complaints. Years later I still had people coming up to me at AstriCon talking about that stuff and how it screwed them over. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and 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 -- _ -- 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
I’m in favor of this approach as well. On October 1, 2020 at 10:23:30 AM, Jared Smith (jaredsm...@jaredsmith.net) wrote: On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp wrote: Not really, and I think part of the problem is that this entire thing hasn't really been documented, communicated, or been a strict part of the release or development process. It's been more organic. Going forward it would be explicitly part of the steps when cutting the new branch, for example, and part of the announcement. OK, thanks for the clarification. Consider me in favor of the process as you outlined it, and also in favor of a more aggressive stance on deprecation of modules that obviously aren't being heavily used/maintained. -Jared -- _ -- 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
Re: [asterisk-dev] Video calling
I’ve been using it in several production systems for nearly a year now on the 16 branch and it has yet segfault. My remaining chan_sip Asterisk 13 systems dump code at least once or twice every 3 months or so. I feel very safe saying chan_pjsip is stable enough for my production needs. Sent from my iPhone > On Nov 15, 2019, at 8:38 PM, Troy Bowman wrote: > > >> On Fri, Nov 15, 2019 at 3:56 PM John Kiniston wrote: > >> I do not recommend using chan_sip, chan_sip is no longer receiving >> development. >> chan_pjsip is where the development focus is at. > > Sure, chan_pjsip is where the feature development focus is, but is it truly > stable enough for production now? It seems I still see a lot of bug fixes > for seemingly constant problems, while chan_sip's code is so mature that it > just works hands-off. I'm still afraid of using chan_pjsip in production > just like I am still afraid of Linux's btrfs in production, and btrfs has > been in development for over a decade. > > -- > _ > -- 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
Re: [asterisk-dev] write my self app. Debug
Are you using AEL with your native application where you’re achieving 50 CPS? What kind of CPS do you get when you just use the straight up dial plan along with func_odbc? It seems odd to me that you’re getting such a dramatic CPS difference between func_odbc used with an AEL dial plan and odbc within your native application. I’d have to imagine the bottleneck is somewhere else. As someone else indicated earlier on this thread, if you’re convinced that you need a native application to meet your needs, a backtrace taken against the core dump produced from the Asterisk crash would be your best bet to figure out what went wrong when the Asterisk instance crashed. -- BJ Weschke Sent with Airmail On September 12, 2018 at 3:37:24 PM, i...@magnussolution.com (i...@magnussolution.com) wrote: that’s correct. I wrote a ael context with func_odbc and this work very well. But, using my app_mbilling.c work more faster than ael and func_odbc. example: agi 15 CPS ael-func_odbc 30 CPS native application 50 CPS But my native application crash some times. I add in my code many ast_log(LOG_ERROR,”LINE number”); to try fond the issue, but each crash the line is different. And in /var/log/asterisk/full Log file not show any additional information. I’m test in production with more than 40 CPS. In test server I send 75 CPS with SIPP and work perfectly. Best regards On 12 Sep 2018, at 16:26, BJ Weschke wrote: AGI is limited in its TPS scalability because it needs to fork an external application to complete processing. func_odbc run from within the dial plan does not need to fork anything external so it does not have the same scalability issues that present with an AGI based solution. -- BJ Weschke Sent with Airmail On September 12, 2018 at 3:22:33 PM, i...@magnussolution.com (i...@magnussolution.com) wrote: i’m developing a native application to billing in realtime. I work many years with Asterisk Billing via AGI. But it is very limited to strong CPS. With 10-15 CPS the server crash. Server with 2 core and 4 GB RAM. With my actual native C application I can get on the same server more than 40 CPS. I wrote in C the same code that I have in php AGI. My name is Adilson Magnus, I’m developer from www.magnusbilling.com Opensource project to Asterisk Billing. https://github.com/magnussolution/magnusbilling6 Best regards. On 12 Sep 2018, at 16:11, Gaston Draque wrote: From the Asterisk side, I would start by looking into the different logging facilities provided[1] but as stated, which Asterisk API you are using will determine which logging facility to look for, how to complement it with your own app.logging and maybe some capturing may be needed during the learning process. Cheers, Gaston// [1] https://wiki.asterisk.org/wiki/display/AST/Logging [1] https://wiki.asterisk.org/wiki/display/AST/Logging+Configuration On Wed, Sep 12, 2018 at 3:11 PM, James Finstrom wrote: This is missing a lot of useful information. How is your app interfaced to asterisk? ARI? AGI? AMI? What language? Are you using a library? There simply isn't enough here to give a qualified answer On Wed, Sep 12, 2018 at 9:10 AM i...@magnussolution.com wrote: > > Hello. > > I’m developing a new app. But i’m a problem. The app crash and restart. This > cause that all call hangup. > > My question is about DEBUG, where or how, I can get details about errors? > > Exist any documentation to DEBUG. > > > My app overview: > > Connect mysql via ODBC, mount the DIAL command and execute the call, after > save call data in my mysql database via ODBC. > > > > Best regards. > > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Astricon is coming up October 9-11! Signup is available at: > https://www.asterisk.org/community/astricon-user-conference > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev -- James Finstrom Guy who does stuff that is sometimes cool gpg: https://github.com/jfinstrom.gpg This email was sent from a personal email account. The content of this email is not endorsed by my employer or any project I may be a part of. The contents of this email should be considered my opinion and not taken as any form of official response. Please keep your hands and feet in the ride while in motion. Please be sure to tip the wait staff. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev --
Re: [asterisk-dev] write my self app. Debug
AGI is limited in its TPS scalability because it needs to fork an external
application to complete processing. func_odbc run from within the dial plan
does not need to fork anything external so it does not have the same
scalability issues that present with an AGI based solution.
--
BJ Weschke
Sent with Airmail
On September 12, 2018 at 3:22:33 PM, i...@magnussolution.com
(i...@magnussolution.com) wrote:
i’m developing a native application to billing in realtime.
I work many years with Asterisk Billing via AGI. But it is very limited to
strong CPS. With 10-15 CPS the server crash. Server with 2 core and 4 GB RAM.
With my actual native C application I can get on the same server more than 40
CPS.
I wrote in C the same code that I have in php AGI.
My name is Adilson Magnus, I’m developer from www.magnusbilling.com Opensource
project to Asterisk Billing.
https://github.com/magnussolution/magnusbilling6
Best regards.
On 12 Sep 2018, at 16:11, Gaston Draque wrote:
From the Asterisk side, I would start by looking into the different logging
facilities provided[1] but as stated, which Asterisk API you are using will
determine which logging facility to look for, how to complement it with your
own app.logging and maybe some capturing may be needed during the learning
process.
Cheers,
Gaston//
[1] https://wiki.asterisk.org/wiki/display/AST/Logging
[1] https://wiki.asterisk.org/wiki/display/AST/Logging+Configuration
On Wed, Sep 12, 2018 at 3:11 PM, James Finstrom wrote:
This is missing a lot of useful information.
How is your app interfaced to asterisk?
ARI?
AGI?
AMI?
What language?
Are you using a library?
There simply isn't enough here to give a qualified answer
On Wed, Sep 12, 2018 at 9:10 AM i...@magnussolution.com
wrote:
>
> Hello.
>
> I’m developing a new app. But i’m a problem. The app crash and restart. This
> cause that all call hangup.
>
> My question is about DEBUG, where or how, I can get details about errors?
>
> Exist any documentation to DEBUG.
>
>
> My app overview:
>
> Connect mysql via ODBC, mount the DIAL command and execute the call, after
> save call data in my mysql database via ODBC.
>
>
>
> Best regards.
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Astricon is coming up October 9-11! Signup is available at:
> https://www.asterisk.org/community/astricon-user-conference
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
James Finstrom
Guy who does stuff that is sometimes cool
gpg: https://github.com/jfinstrom.gpg
This email was sent from a personal email account. The content of this
email is not endorsed by my employer or any project I may be a part
of. The contents of this email should be considered my opinion and not
taken as any form of official response. Please keep your hands and
feet in the ride while in motion. Please be sure to tip the wait
staff.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Astricon is coming up October 9-11! Signup is available at:
https://www.asterisk.org/community/astricon-user-conference
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
--
{
"fullName" : "Gaston Draque",
"email" : "gaston.dra...@gmail.com",
"twitter" : "@gdraque",
"job" : "VoIP Space Monkey",
"motto" : "Clouds are made of pizza & coffee"
}
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Astricon is coming up October 9-11! Signup is available at:
https://www.asterisk.org/community/astricon-user-conference
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 --
Astricon is coming up October 9-11! Signup is available at:
https://www.asterisk.org/community/astricon-user-conference
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 --
Astricon is coming up October 9-11! Signup is available at:
https://www.asterisk.org/community/astricon-user-conference
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] write my self app. Debug
Why a native application? What data are you looking to store in the DB? It seems like you could do what you’re looking to do in the dial plan with func_odbc. -- BJ Weschke Sent with Airmail On September 12, 2018 at 3:12:35 PM, i...@magnussolution.com (i...@magnussolution.com) wrote: hi, thanks for try help me. I using C. I’m create in Asterisk-13/apps/app_mbilling.c Native application to Asterisk. > On 12 Sep 2018, at 15:11, James Finstrom wrote: > > This is missing a lot of useful information. > > How is your app interfaced to asterisk? > ARI? > AGI? > AMI? > > What language? > Are you using a library? > > There simply isn't enough here to give a qualified answer > On Wed, Sep 12, 2018 at 9:10 AM i...@magnussolution.com > wrote: >> >> Hello. >> >> I’m developing a new app. But i’m a problem. The app crash and restart. This >> cause that all call hangup. >> >> My question is about DEBUG, where or how, I can get details about errors? >> >> Exist any documentation to DEBUG. >> >> >> My app overview: >> >> Connect mysql via ODBC, mount the DIAL command and execute the call, after >> save call data in my mysql database via ODBC. >> >> >> >> Best regards. >> >> >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> Astricon is coming up October 9-11! Signup is available at: >> https://www.asterisk.org/community/astricon-user-conference >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > -- > James Finstrom > Guy who does stuff that is sometimes cool > > gpg: https://github.com/jfinstrom.gpg > > This email was sent from a personal email account. The content of this > email is not endorsed by my employer or any project I may be a part > of. The contents of this email should be considered my opinion and not > taken as any form of official response. Please keep your hands and > feet in the ride while in motion. Please be sure to tip the wait > staff. > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Astricon is coming up October 9-11! Signup is available at: > https://www.asterisk.org/community/astricon-user-conference > > 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 -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference 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 -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk
I would have an immediate use case for something like func_redis. I think it would be very useful. On December 22, 2017 at 8:02:28 AM, Nir Simionovich (nir.simionov...@gmail.com) wrote: Abhay, Migrating astsb from SQLlite to redis isn't the topic here. I'm talking adding a new type of storage engine. For example, func_redis, that will implement the relevant key/value operations that are commonly used by people. Nir On Fri, Dec 22, 2017, 14:33 Abhay Gupta wrote: Hi All, I had a program where I have implemented a project using REDIS wherein the client is made using a socket library and no other third party client library in C . This REDIS database has 400 million records and performs extremely well though the memory requirement for such a large dataset goes to 48GB . So I strongly believe that for such key value pair REDIS will be the right choice for ASTDB. Regards, Abhay On 22-Dec-2017, at 5:52 PM, Nir Simionovich wrote: Hi All, Following a discussion on JIRA [https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly believe that adding a scaleable, robust and most importantly - accepted key/value store mechanism to the Asterisk dialplan is a worthwhile effort. Every, and I do mean every, Asterisk application requires a key/value store of some form. Most developers will basically butcher (would have used stronger words, but refraining from doing so) AstDB in the process, which will then result in a performance toll - specifically when dealing with a high capacity systems. Initially, I was under the impression this should be done as a sorcery module, but I'm not sure this is the correct approach or the required use case. I would like to hear if others believe this is a worth while effort? if others believe it is, I'll be ecstatic to work with others on this one (adding Redis support isn't as simple as it sounds). However, before I start working on something, I'd like to see if others believe this as strongly as I do. On the same note, I'll be in NYC second week of January - so if any of you are around that area and would like to combine forces to spear this - would love to do so. -- Kind Regards, Nir Simionovich GreenfieldTech (schedule) http://nirsimionovich.appointy.com/ (w) http://www.greenfieldtech.net (p) +972-73-2557799(MSN): n...@greenfieldtech.net (m) +972-54-6982826 (GTALK): nir.simionov...@gmail.com (f) +972-73-2557202 (SKYPE): greenfieldtech.nir -- Zero Your Inbox | Cloud Servers -- Disclaimer: This e-mail is intended solely for the person to whom it is addressed and may contain confidential or legally privileged information. Access to this e-mail by anyone else is unauthorized. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and destroy this e-mail and any attachments. E-mail may be susceptible to data corruption, interception, unauthorized amendment, viruses and delays or the consequences thereof. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. -- _ -- 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 -- Kind Regards, Nir Simionovich GreenfieldTech (schedule) http://nirsimionovich.appointy.com/ (w) http://www.greenfieldtech.net (p) +972-73-2557799(MSN): n...@greenfieldtech.net (m) +972-54-6982826 (GTALK): nir.simionov...@gmail.com (f) +972-73-2557202 (SKYPE): greenfieldtech.nir -- Zero Your Inbox | Cloud Servers -- Disclaimer: This e-mail is intended solely for the person to whom it is addressed and may contain confidential or legally privileged information. Access to this e-mail by anyone else is unauthorized. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and destroy this e-mail and any attachments. E-mail may be susceptible to data corruption, interception, unauthorized amendment, viruses and delays or the consequences thereof. If you are not the intended recipient, be advised that you have received this email in error and that any use,
Re: [asterisk-dev] ARI Bridge Behavior
I think you’re referring to the asterisk-app-dev mailing list where ARI, AGI, and AMI are all covered. http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev On January 16, 2017 at 3:40:53 PM, Phil Mickelson (p...@cbasoftware.com) wrote: Re asterisk-ari list. I don't believe there is one but it sure would be great if there was! Thanks Phil Mickelson CBA Software On Jan 16, 2017 3:31 PM, "Matt Fredrickson" wrote: On Tue, Jan 10, 2017 at 8:00 PM, bala murugan wrote: Any idea how you disabled the channel_varset from stasis . can you provide the config or steps ? thanks, Hey Bala, First off, welcome to the Asterisk Development mailing list! This is a place typically to discuss C-level code issues and interesting protocol level development topics that affect code changes. Just so that you're aware, from a mailing list etiquette perspective usually you would start a new thread with your question instead of replying to two existing threads with a question about a new topic. I'm guessing that this is probably a question you might ask on the asterisk-ari mailing list or the asterisk-users mailing lists as well. So, to answer your question, and after talking with Josh Colp, in Asterisk 12 it does not look like it's possible. In Asterisk 13 you can disable it on a global basis, using stasis.conf as follows: [declined_message_types] decline=ast_channel_varset_type But I believe that will apply globally to all users of Stasis/ARI. -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA -- _ -- 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-- _ -- 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] Advanced feature query
Short answer: yes. However you'll probably want to take this to asterisk-users for the particulars and different ways it could be implemented. Sent from my iPhone > On Feb 6, 2015, at 10:26 AM, David Radcliffe > wrote: > > Hi, > > Does anyone know if Asterix has the ability to send a network message (TCP/IP > packet) indicating that a call is in progress through the PBX? > > Thanks > > David W. Radcliffe > Senior Developer > > Clockwork IT Ltd > tel: 08448 040950 > mob: 07764 155251 > > WWW.SUPPORTDESKPRO.CO.UK > > > Clockwork IT Ltd, Saturn Business Centre, 101 Lockhurst Lane, Coventry, CV6 > 5SF > NOTICE-This message contains information intended only for the use of the > addressee named above. It may also be confidential and/or privileged. If you > are not the addressee, you should not disclose, copy, distribute, take any > action or rely on this E-mail and should notify us immediately by return > E-mail to i...@clockworkit.co.uk The views expressed in this communication > may not necessarily be the views held by Clockwork IT > > -- > _ > -- 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
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
+1
This sounds more than reasonable to me.
Sent from my iPhone
> On Nov 10, 2014, at 5:57 PM, Matthew Jordan wrote:
>
> At AstriDevCon, we spent a good amount of time discussing whether or
> not we should allow new features or improvements to be made in release
> branches. As I summarized previously [1]:
>
> {quote}
> Draft a policy for allowing improvements in release branches.
>
> The Asterisk project today does not exist in the same world - and is
> not the same project - as when the "no new feature in release
> branches" policy was first employed. We have a rigorous peer review
> process, multiple test suites, continuous integration infrastructure,
> and more to help prevent regressions or other problems from occurring.
> In addition, the world today is also moving faster, and we'd like to
> make sure that Asterisk maintains pace with changes in the industry.
> At the same time, we have to ensure that release branches are stable
> and that a user can upgrade within a release branch and not worry
> about behavioural changes. We feel we can strike that balance with the
> right policy.
> {quote}
>
> Before everyone rejoices/panics too much, there are restrictions on
> proposing a new feature or improvement to a release branch:
> (1) Any new feature proposed for an existing release branch must have
> suitable test coverage using either the Asterisk Test Suite, the
> Asterisk Unit Test Framework, or both.
> (2) The new feature or improvement must be backwards compatible with
> the previous releases in those major versions. That is, users
> upgrading from one point release to the next should not be aware of
> any new feature or improvement unless they want to use said feature.
> Some things that should not be changed naturally follow from this:
> (2a) APIs that follow semantic versioning should not receive a major
> version increase.
> (2b) Configuration and database schemas can be added to or updated,
> but users should not be required to update their configuration or
> databases.
> (3) Any new features or improvements must be included in the first
> release candidate of a new version. First release candidate
> announcements must be made to the asterisk-users mailing lists, with
> at least a week of testing time allowed. If a new feature or
> improvement is deemed to cause an inappropriate burden on end-users,
> 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
--
_
-- 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 14 - Remote URI Playback
On 11/6/14, 4:04 PM, Matthew Jordan wrote: eg - Playback(http://myserver.com/monkeys.wav&http://myserver.com/can.wav&http://myserver.com/act.wav&http://myserver.com/like.wav&http://myserver.com/weasels.wav) <--- On an empty HTTP Media cache, the previous app invocation would probably sound pretty bad to the first caller going through this workflow. :-) Also, I think the inability to use & in a URI for playback really limits the usefulness of this change. I totally understand why the typical URI decode doesn't work, but perhaps a combination of a URI encoded & with an HTML entity representation is a suitable alternative? eg - (%26amp; == & in a URI in Playback and do that pattern replacement in the URI before any other URI decoding/encoding operations. Ya, I know, it's a hack, but not allowing multiple parameters in a loaded queryString URL is way too restricting IMHO). So I just replied to this part on Johan's e-mail - do you think we can skip supporting an '&' in a resource? (How many media files are going to be named tt-monkeys&weasels anyway?) Yes. I think that's perfectly reasonable. Well, kind of. I think you're still envisioning using CURL behind the scenes using the input provided in the JSON body of the PUT to /media_cache to go and grab the resource from the remote server. If you go that way, I think not only should we handle custom headers, but it's probably also not unreasonable to provide a way to do basic/digest authentication for the GET call as well. However, instead of that, I had envisioned being able to do a PUT to /media_cache as a multipart MIME request where one part is the JSON descriptor and the second part is the binary resource itself you're looking to place into HTTP Media cache. The advantage of doing things this way is that if you're running call control via some sort of API, that API will know for certain when files/resources are ready to be played back and you don't run the risk of the awkward blocking silence scenario that you have above. However, when you do it this way, the URI description/parameter itself doesn't make too much sense because it's not really where the resource came from. I guess there's also a question as to whether or not we follow the true REST practice with using POST for a brand new resource and PUT for updates to existing resources. I'd prefer that approach actually. Pushing media to the server is preferable to having Asterisk attempt to pull it. To do this correctly, I think we'll need a sorcery wizard that accepts push configuration/objects. We had previously talked about this with respect to a push configuration model for PJSIP, but this actually takes it one step further with a push wizard for buckets. Since buckets sits on top of sorcery, it feels like this is theoretically possible... but I'm not sure yet how it would play out completely. Josh may want to comment on this part. I look forward to his commentary. :-) As for the timestamps for deciding whether the local cache is dirty, I don't think we should try to reinvent the wheel here. We should stick what's already well established for stuff like this and use the entity tag (Etag) response header stored and then use the "If-None-Match" request header approach. Google does a much better job of explaining it than I can here: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching Agreed, as commented on Johan's e-mail. E-Tags for the win! I'll update the wiki from the conversation here shortly. -- _ -- 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 14 - Remote URI Playback
On 11/4/14, 3:40 PM, Matthew Jordan wrote: On Tue, Nov 4, 2014 at 12:57 PM, BJ Weschke wrote: Matt - This is a pretty neat idea, indeed, but I've got some questions/thoughts on implementation. :-) Apologies if all of this was already considered/accounted for already.. 1) Does the entire file need to be downloaded and in place on the HTTP Media Cache before you can call an ast_openstream on it? This could cause some problems with larger files not sitting on a fat pipe local to the Asterisk instance. It does need to be completely on the local file system, which would be a problem for extremely large files and/or slow network connections. The ability to do an 'asynchronous' version of this is not really present. The filestream code in the core of Asterisk doesn't have anything present that would allow it to buffer the file partially before playing back with some expected max size. If we went down that road, it'd almost be a completely separate filestream concept from what we have today, which is pretty non-trivial. I don't think I have a good solution for really large files just yet. There's some ways to do this using cURL (where we get back a chunk of binary data, buffer it, and immediately start turning it into frames for a channel) - but that feels like it would need a lot of work, since we'd be essentially creating a new remote filestream type. I know there's going to be a large population of Asterisk users that will want the simplicity of just specifying a URI for playback and expecting "sorcery" to happen. A decent number of them may even be OK with what may be a sub-second awkward silence to the caller on the line while things like the servicing thread synchronously queues the URI resource into the local HTTP media cache before playback. That's probably going to be an acceptable experience for a decent number of functional use cases. However, I think one somewhat common use case where this wouldn't go so well would be a list of URI resources that weren't already in HTTP media cache since they'd be fetched serially in-line at the time where playback really should be starting and block the channel with silence until the resource is set in media cache. eg - Playback(http://myserver.com/monkeys.wav&http://myserver.com/can.wav&http://myserver.com/act.wav&http://myserver.com/like.wav&http://myserver.com/weasels.wav) <--- On an empty HTTP Media cache, the previous app invocation would probably sound pretty bad to the first caller going through this workflow. :-) Also, I think the inability to use & in a URI for playback really limits the usefulness of this change. I totally understand why the typical URI decode doesn't work, but perhaps a combination of a URI encoded & with an HTML entity representation is a suitable alternative? eg - (%26amp; == & in a URI in Playback and do that pattern replacement in the URI before any other URI decoding/encoding operations. Ya, I know, it's a hack, but not allowing multiple parameters in a loaded queryString URL is way too restricting IMHO). 2) What kind of locking is in place on the design to prevent HTTP Media Cache from trying to update an expired resource that's already in the middle of being streamed to a channel? Items in the cache are reference counted, so if something is using an item in the cache while the cache is being purged, that is safely handled. The buckets API (which is based on sorcery) assumes a 'if you're using it, you can hold it safely while something else swaps it out' model of management - so it is safe to update the entry in the cache with something new while something else uses the old cached entry. The 'local file name' associated with the URI would be created with mkstemp, so the risk of collision with local file names is low. In the same fashion, a local file that is currently open and being streamed has a reference associated with it in the OS. Calling unlink on it will not cause the file to be disposed of until it is released. I had to do a little bit of reading up on the Bucket File API, but yes, that definitely resolves the concern I had, and that's pretty cool. :-) 3) I think you need to also introduce a PUT method on HTTP Media Cache because I can think of a bunch of scenarios where having a write operation on func_curl may be lacking in the file needing to be retrieved (eg - trying to pull ACL'd media from an S3 volume where you need custom HTTP request headers, etc). We shouldn't try to architect/design for all of these scenarios in Asterisk via a write operation on func_curl and a PUT to HTTP Media Cache seems like a reasonable approach to handle that. I had thought about this, but didn't have a strong use case for it - thanks for providing one! How about something like: GET /media_cache - retrieve a Li
Re: [asterisk-dev] Asterisk 14 - Remote URI Playback
Matt - This is a pretty neat idea, indeed, but I've got some questions/thoughts on implementation. :-) Apologies if all of this was already considered/accounted for already.. 1) Does the entire file need to be downloaded and in place on the HTTP Media Cache before you can call an ast_openstream on it? This could cause some problems with larger files not sitting on a fat pipe local to the Asterisk instance. 2) What kind of locking is in place on the design to prevent HTTP Media Cache from trying to update an expired resource that's already in the middle of being streamed to a channel? 3) I think you need to also introduce a PUT method on HTTP Media Cache because I can think of a bunch of scenarios where having a write operation on func_curl may be lacking in the file needing to be retrieved (eg - trying to pull ACL'd media from an S3 volume where you need custom HTTP request headers, etc). We shouldn't try to architect/design for all of these scenarios in Asterisk via a write operation on func_curl and a PUT to HTTP Media Cache seems like a reasonable approach to handle that. Thanks! BJ On 11/4/14, 1:09 PM, Matthew Jordan wrote: Hey everyone - One of the action items on the list from AstriDevCon was to flesh out some of the ARI feature proposals that had been made for Asterisk 13. I've just finished putting together a draft of the first one for Remote URI Playback. You can find the proposal page here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback Ben Langfeld has already given some excellent feedback on the proposed approach; I'd encourage everyone to chime in on the page as there are some interesting edge cases that have to be considered for the feature. If you'd like to participate in the development and/or testing, please let me know either by replying to this e-mail or by commenting on the wiki page. Thanks! Matt -- _ -- 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] AstriDevCon 2014: Agenda item DeprecateAMI/AGI(Ben Klang)
On 10/22/14, 3:06 PM, Paul Albrecht wrote: On Oct 22, 2014, at 11:47 AM, BJ Weschke wrote: On 10/22/14, 12:14 PM, Paul Albrecht wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that "what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. "It doesn't merit discussions and shouldn't be on the agenda in the first place." Really? Paul, aside from the Digium team, everyone else that's there at DevCon have spent outside funds to get there and I think the consortium is pretty well able to discuss whatever they'd like regardless of your dictator like statements which goes against everything that an open sourced project/community is supposed to be. There have been years where I'm able to attend DevCon and there have been other years, like this one, where I'm not able to attend because of prior business commitments. In the prior years where I haven't been able to attend, I don't personally feel like anything major was implemented without first being vetted with the list and community at large. I'm not really sure why you perceive the whole AstriDevCon event to be some kind of conspiracy theory against the community at large, but knowing both Josh, Leif, and many other people in that room for some number of years now, I can assure you that I've never seen anything other than 100% transparency. You've made more than clear in prior posts to this forum that you're not really a fan of ARI. I think we all get it. There are other people that are fans and, for them, they're in transition to using it in a more mainstream fashion because it's able to do things for them that AMI and AGI cannot. I personally still use AGI and AMI in many production scenarios with Asterisk today and I'm only just thinking lately about certain applications that I could transition to ARI. We cannot discount that there's a very large cost for the developers, testers, and the community at large to continue to keep AMI/AGI maintained and functionally up to date with all the Asterisk changes along with ARI given the way that AMI/AGI were originally implemented in the codebase. For people that are absolutely hooked on still using AMI/AGI in the longer term, perhaps a discussion could ensue at some point about a bridge with AMI/AGI functionality being built off of ARI itself, or maybe that's just crazy talk. I really don't know. The great thing about Asterisk and the community around it is that if there's enough participation and interest, anything can happen. What you’re discounting is the Asterisk community that have used and are using dial plans and AGI/AMI. If ARI can’t work in that environment, then ARI should be abandoned as simply unworkable. I'm not discounting that at all. As I stated already, I am part of that community that's still making very active use of dial plans and AGI/AMI on production systems. ARI, by itself, cannot replace that functionality. It wasn't ever intended to when it was conceived. Although I was admittedly not in the room nor did I hear any stream or recording of the event yesterday, I read from Leif's bullet point that "we" refers to the company and application that he's personally working with in the current day. "We" doesn't represent the Asterisk community at large. I think if you had read through the rest of the points and opinions documented by Matt and the rest of the Digium folks at https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014, that would have become abundantly clear. -- _ -- 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] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)
On 10/22/14, 12:14 PM, Paul Albrecht wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that "what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. "It doesn't merit discussions and shouldn't be on the agenda in the first place." Really? Paul, aside from the Digium team, everyone else that's there at DevCon have spent outside funds to get there and I think the consortium is pretty well able to discuss whatever they'd like regardless of your dictator like statements which goes against everything that an open sourced project/community is supposed to be. There have been years where I'm able to attend DevCon and there have been other years, like this one, where I'm not able to attend because of prior business commitments. In the prior years where I haven't been able to attend, I don't personally feel like anything major was implemented without first being vetted with the list and community at large. I'm not really sure why you perceive the whole AstriDevCon event to be some kind of conspiracy theory against the community at large, but knowing both Josh, Leif, and many other people in that room for some number of years now, I can assure you that I've never seen anything other than 100% transparency. You've made more than clear in prior posts to this forum that you're not really a fan of ARI. I think we all get it. There are other people that are fans and, for them, they're in transition to using it in a more mainstream fashion because it's able to do things for them that AMI and AGI cannot. I personally still use AGI and AMI in many production scenarios with Asterisk today and I'm only just thinking lately about certain applications that I could transition to ARI. We cannot discount that there's a very large cost for the developers, testers, and the community at large to continue to keep AMI/AGI maintained and functionally up to date with all the Asterisk changes along with ARI given the way that AMI/AGI were originally implemented in the codebase. For people that are absolutely hooked on still using AMI/AGI in the longer term, perhaps a discussion could ensue at some point about a bridge with AMI/AGI functionality being built off of ARI itself, or maybe that's just crazy talk. I really don't know. The great thing about Asterisk and the community around it is that if there's enough participation and interest, anything can happen. BJ -- _ -- 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] Deprecate every '* reload' CLI command?
Tilghman Lesher wrote: > On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote: > >> On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote: >> >>> Eliel Sardanons wrote: >>> We could start a janitor for creating a 'foo reload' and we could make de 'module reload *.so' do a module unload; module load >>> I would rather not change the behavior of "module reload". I think that >>> would be much worse than just removing it, as it changes behavior that >>> has existed for years. Running "module unload / module load" isn't that >>> bad. >>> >> So: >> - Start a janitor to implement 'foo reload' for every module that does >> something in the reload() handler function. >> - Deprecate CLI command 'module reload ' >> - Remove the 'reload()' handler function on every module. >> > > I wouldn't do this last one. That is the handler that is called when we do > a generic 'reload', for every single module. > > I agree with Tilghman. -- Bird's The Word Technologies, Inc. http://www.btwtech.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] Deprecating sip call-limit
Olle E Johansson wrote: > 20 nov 2007 kl. 22.58 skrev BJ Weschke: > > >> Johansson Olle E wrote: >> >>> Friends, >>> >>> Blitzrage and I had a discussion about busylevel and call-limit in >>> chan_sip on the IRC I wanted to expand to the rest of you deveopers >>> out there... >>> >>> >>> My proposal in this discussion was: >>> >>> - deprecate call-limit in chan_sip. No other channel driver has a >>> built-in call limit >>>and we now favour groupcount and dialplan control instead of >>> embedding this >>>into channel drivers. >>>The call-limit is history that has survived too long. >>> >>> - implement a new option to enable call counters for the subscribe/ >>> notify event system in chan_sip (channel specific) >>> >>> - implement busy-level in more channel drivers >>> >>> - implement a DEVICE() dial plan function that is cross-channel, like >>> CHANNEL(), >>> so we can check busylevel in chan_iax2 and other channels that can >>> handle multiple >>>channels per device. Busylevel can now be checked in the SIPPEER() >>> function only. >>> >>> >>> I know this is a lot of stuff at the same time, but it kind of >>> belongs >>> together. >>> >>> /O >>> >>> >> Olle / Leif - >> >> What are we going to do about things like app_queue that resolve on >> call-limit and limitonpeers being set correctly in order to make a >> proper response back to app_queue that the device is or is not busy >> to receive a queue call? >> > > App_queue doesn't do anything with the actual limit, but it needs the > call counter that is the basis behind the call limit. That counter > will stay, but get a new name. The actual enforcement of any call > limits in chan_sip will go. > > Ah! Ok. In that case, then yes, +1. -- -- Bird's The Word Technologies, Inc. http://www.btwtech.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] More "concise" CLI commands - something we really want?
Olle E Johansson wrote: > 15 nov 2007 kl. 13.22 skrev Tzafrir Cohen: > > >> On Thu, Nov 15, 2007 at 12:43:40PM +0100, Johansson Olle E wrote: >> >>> While browsing the bug tracker today, I found a patch for adding more >>> "concise" commands to the SIP channel. >>> >>> My personal opinion is that I don't like adapting the CLI for machine >>> parsing. If we're about to do that, we might >>> as well convert all CLI listings in one big janitor project. But we >>> already have the manager for that kind of >>> communication - machine-parseable. We could easily write a wrapper >>> for /utils that replaces "asterisk -x" >>> for web applications and other scripts. >>> >>> I propose that we deprecate the existing "concise" commands in trunk, >>> don't accept new ones and refer >>> users and developers to our lovely AMI solution. >>> >> I have two potential issues with this: >> >> 1. "concise" tend to better fit in a 80-column terminal (such as the >> Linux console). >> > That won't be the case with other listings - we have much more > information > than what fits. The normal listings try to handle that by cutting off > data. > > I think it's simple to enable manager. We just need to provide a good > script that outputs the data in many different ways, maybe using awk > or something classy? > > /O > > I'm going to agree with Olle here. I think there should really be only one way / format to present information from the CLI and everything else should be driven through interfaces designed to deliver multiple formats (eg AMI). -- Bird's The Word Technologies, Inc. http://www.btwtech.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] bweschke: branch 1.4 r87514 - /branches/1.4/apps/app_followme.c
Crap. Looks like I pulled in Dave's patch on a previous un-reverted version of app_followme I was messing around with to make it more multi-lingual capable. Sorry about that guys. I'll fix now. :( On Oct 30, 2007 7:35 AM, Joshua Colp <[EMAIL PROTECTED]> wrote: > > This patch is not complete! It adds language in some places but not all. > > This is no longer valid code as your arguments are now wrong. > > > >Andrew > > > > Hi Andrew, > > I've already fixed it up so app_followme will at least compile in 1.4 and > I've also emailed BJ a note about it. Thanks for noticing though and perhaps > this will make it show up on his radar twice :) > > Joshua Colp > Software Developer > Digium, Inc. > > ___ > --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 > -- Bird's The Word Technologies, Inc. http://www.btwtech.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] Call Specific MOH
On 3/29/07, Tilghman Lesher <[EMAIL PROTECTED]> wrote: On Wednesday 28 March 2007 11:08, Vadim Lebedev wrote: > I hope it can be integrated in mainline Why not just use the SetMusicOnHold application in the dialplan? Because app_queue won't observe that. This patch is valid, but we need to follow protocol to get it in. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] Support for Agent channels in Bridge manager and dial plan patch
On 1/3/07, Moises Silva <[EMAIL PROTECTED]> wrote: Hi, I have been working with the patch for the Bridge manager action and dial plan application. So far it seems to work, however, more testing is needed, this bug/feature has more than 1 year on the bugtracker, plz if someone has the time, test it. A known issue is that does not work with Agent channels. It seems Agent channel is like a proxy, and hides the real channel. So this does not work: Bridge(Agent/something) Because I use the routine ast_get_channel_by_name_locked on the argument to try to get the channel and do_masquerade() on it. So the channel is not found because the real channel is hidden, and the call to Bridge fails. Should I write a call similar to ast_get_channel_by_name_locked() that supports the proxy concept? or something like that already exists? Any advice will be appreciated. Local channels probably pose the same issue for you as well. This was talked about in the dev sessions at Astricon this year and while everyone acknowledged the work put in to the Bridge action and the need to have such a feature, I think the outcome of the discussion was that for the same reason you're having issues now, a core "Bridging API" is necessary is really necessary to put this kind of thing to rest once and for all. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] Bug marshals - won't you take a look at 8188
On 11/2/06, Jared Smith <[EMAIL PROTECTED]> wrote: On Thu, 2 Nov 2006, Stephen Davies wrote: > I posted up a change that gets chan_iax2 to log jitter buffer stats > into the logs regularly during active calls. I've also responded to the bug (#8188), but I'll repost my comments below as they're likely to get a greater audience of developers: Interesting... John Todd and I were discussing something similar at AstriCon, but in a more generic sense. What we'd like to see written is CQDR -- Call Quality Detail Records. Think of them as sitting side-by-side the CDR records, but showing information about the Call Quality. In the case of IAX, we get all kinds of useful information, which we don't currently capture (and your patch logs to the verbose log). In the case of SIP, we have RTCP reports (as well as call quality reports in the BYE messages of some endpoints). Wouldn't it be cool to see all this information logged to a CQDR table? Jared - Totally agree with you here. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] Possible app_transcribe?
On 9/13/06, Slim Shady <[EMAIL PROTECTED]> wrote: Hello all, I would like to know if anyone is interested in doing a quick and dirty custom application module to be used similar to the monitor application within features.conf. The application is for the medical industry and in my oppinion I think would be great for the medical proffessionals/businesses, but I am doing this for the company I work for. I am currently working for a medical affinity group in which I have developed most of the applications via scripting with the dial plan, however I think that what I am trying to do now may require some help from the development community. Requirement: The application should really be the same as the monitor application but I need the monitor application with a different name because as I understand I can not use the monitor application twice in features.conf. If you have any suggestions I would really appreciate it. Have you taken a look at app_dictate ? -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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: agi segfaults 1.2.9.1
On 6/22/06, Thomas Kenyon <[EMAIL PROTECTED]> wrote: > > In regards to the AddQueueMember, I simply forgot to add @context to > the end of the device name. I don't think that this should cause a > segfault. On the other hand, I wouldn't expect you to be testing for > @averyververylongcontextthatcouldbe1000millioncharacterslong > either. > Weird, I could have sworn that the context wasn't neccesary (as in the example shown in show application AddQueueMember in the CLI). You're reading this out of context. @context is required for Local/ interfaces specified in AddQueueMember. The segfault condition has been corrected and you get a warning on the CLI now when you do something that you should not. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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
[asterisk-dev] The app_lock mutex in chan_agent.c
Short of a dev conference call earlier this week to discuss, based on JackEStorm's posts in #asterisk-bugs about his research into deadlock issues with chan_agent/app_queue I've now also taken a harder look at chan_agent.c this past week and I'm coming up with blanks at this point trying to understand why we need to make use of the app_lock mutex at all on a chan_agent channel when the agent is working in callback mode. When not in callback mode, we definitely need this to forego competition between the login app and the "owning" channel, but in callback mode, the login app has already long ago exited the scene and there seems to already be adequate protection that exists today within the code that prevents a second call from getting built on top of an agent_pvt that already has an active call up. With the ever changing ways that we're trying to manage transfers and other complex operations within the channel technologies, it seems like it's becoming more common place that the thread handling agent_hangup(...) for a given agent channel is not always going to be the same thread that locked the app_lock mutex within agent_request(...). That being the case, I'm seeking advice/comments on doing away with the use of the app_lock mutex with agent channels when in call back mode. Comments greatly appreciated. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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 instability - resolved - res_features.c
On 4/17/06, Dov Bigio <[EMAIL PROTECTED]> wrote: > > Hello, I made the following changes on my res_features.c to resolve an > instability I had with atxfer... > (Actually, I wasn't the one who did it cause I don't know C, but this > worked, so I am forwarding to you so that you can confirm it makes sense and > include it in the Subversion system) > > /usr/src/asterisk-1.2.6/res/res_features.c > Hi Dov - Looking at the code for 1.2.7.1 (or the 1.2 branch) we're already checking to see if 'f' is a valid structure up at line 1412 in the code of res_features.c. That being the case, I'm not sure this code you've provided is really necessary. Maybe this a relatively new change to res_features.c that wasn't present in 1.2.6. Have you tested to see whether the crashes still exist for you in 1.2.7.1 ? BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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 Developers' Conference Call Proposal
On 4/11/06, Russell Bryant <[EMAIL PROTECTED]> wrote: > Hello everyone, > > We've had various attempts to have ongoing developers' conference calls > in the past. Josh Colp, Kevin Fleming, and I were talking about this > again today and would like to propose that we start this up again. > > The first issue is a matter of organization of the conference calls. I > would like to propose that we allocate 1.5 hours each week for this > call. The first hour will be for discussion of a predetermined agenda > of topics. The last 30 minutes would be reserved for open discussion > about topics not on the official agenda. Anyone would be welcome to ask > questions and bring up topics in this session. > > The topic agenda would be set at least 24 hours ahead of time and posted > on asterisk.org. Developers that would like to get a topic on the > agenda would contact me, or whoever keeps track of this, during the week > before the call. There would also be someone on the call acting as a > moderator, to keep track of time and make sure that we follow the schedule. > > The other big issue is finding a time that would be suitable for as many > of the core developers as possible. In hopes of serving both the > developers in North America and Europe, I would like to go ahead and > propose Tuesday, at 10 AM Central Time. > > All of these conference calls would be recorded and placed on > asterisk.org. We would also make the recordings available through an > RSS feed. > > Thoughts? > Sounds good! We start next week? :) -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] DSP pci board.
On 3/22/06, Matt Florell <[EMAIL PROTECTED]> wrote: > From: http://www.tmcnet.com/usubmit/2006/03/14/1456373.htm > > Digium Inc., the creator of Asterisk(TM), and pioneer of open source > telephony, today announced the availability of new hardware solutions > to enhance Asterisk transcoding and echo cancellation performance for > VoIP and PSTN gateways. These new products include the TC400P VoIP > transcoding card... > > > > The TC400P provides hardware transcoding of VoIP codecs; decreasing > Asterisk's work load and providing improved CPU efficiency and an > increase in channel density over a software-only solution. The TC400P > provides Asterisk with full transcoding support and hardware > acceleration for the G.723.1 and G.729A codecs. > > > Can't wait for more info on this one. > I saw the board at VON. Wasn't sure if it was public yet. Sounds very, very cool. :) -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] DSP pci board.
On 3/22/06, Wai Wu <[EMAIL PROTECTED]> wrote: > > Hi all, > > Has been poking through the * source code a bit and trying to identify the > most CPU demanding piece of code. Is trans-coding the most CPU demanding? I > happen to have access to a DSP pci board. If I can move the encoder/decoder > off the host processor onto the DSP board, will I get a decent performance > boost for an * PSTN gateway for VoIP phones (assuming all VoIP phones are > using say g732, g729 or gsm)? > ___ You will get a performance increase, but then you'd also have to write Asterisk drivers for it. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] What to do with RTCP ????
On 2/27/06, Andreas Sikkema <[EMAIL PROTECTED]> wrote: > > The RTCP branch includes improved support of RTCP, but also a > > reporting facility we do not use currently. Would it be > > useful to add > > this to a channel variable - or even better a CDR variable - so you > > can add it to CDRs and make reports based on it? > > I don't mind how it's reports, als long as it's relatively easy to > correlate RTCP data to users. So adding some information to a CDR > is fine. > Some integration with the CDR is fine, but I'd rather we make it available via a function so people can grab the data and do what they want with it. To have an RTCP logging channel via the existing logger facility might be an interesting thing too. I'd proably use that to throw it to some facility that throws up mrtg type graphs,etc. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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: Repost: Re: [asterisk-dev] How does RFC2833 get indicated to the SIP peer
On 2/17/06, Ed Greenberg <[EMAIL PROTECTED]> wrote: > Can somebody who understands chan_sip.c please explain this to me? THanks. > > --On Thursday, February 16, 2006 6:20 AM -0800 Ed Greenberg > <[EMAIL PROTECTED]> wrote: > > > Back in Asterisk 1.0.5, when we sent our SDP packet to the distant end, > > we sent > > m=audio RTP/AVP 101 > > where the 101 which indicated that we wanted to get RFC2833 DTMF from our > > other end. > > > > Now it's missing, and my peer (level3) is sending me inband DTMF. > > > > It's not obvious to me from reading channels/chan_sip.c (in either the > > old 1.0.5 or the current 1.2.4) how this 101 gets on the end of my Media > > Description line or how else the peer is supposed to know that I need > > rfc2833 DTMF. > > > > Can somebody please explain? Do you have dtmfmode=rfc2833 in sip.conf for this peer? If so, let's get a sip debug and open a bug on bugs.digium.com. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] Outgoing call from MeetMe?
On 2/15/06, Tony Mountifield <[EMAIL PROTECTED]> wrote: > Has anyone done any work on enhancing the MeetMe keypad menu to allow > the initiation of an outgoing call which will be connected to the > conference? e.g. *5 followed by the number to call. > > This would be very useful for adding participants to the conference > without the aid of some external control interface. > > I thought I had seen some talk of such a feature in the past, but can't > find any reference to it now. > Tony - There was a patch up that did this pre 1.2. I'll see if I can dig it up again. I'm sure it probably needs a little work now to get it working with /trunk. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] COMPILE ERROR - branch 1.2 r9861 - /branches/1.2/asterisk.c
On 2/13/06, Aryanto Rachmad <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> I tried to get into branch 1.2 r9861, but when I compiled asterisk I got the
> following error:
>
> asterisk.c: In function 'main':
> asterisk.c:2213: error: 'ast_opt_dump_core' undeclared (first use in this
> function)
> asterisk.c:2213: error: (Each undeclared identifier is reported only once
> asterisk.c:2213: error: for each function it appears in.)
> make: *** [asterisk.o] Error 1
>
> It complied and running fine when I commented the following lines to revert
> asterisk.c to r9860:
>
> Line 78:
> #include
>
> Line 2213:
> if (geteuid() && ast_opt_dump_core) {
> if (prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) < 0) {
> ast_log(LOG_WARNING, "Unable to set the process for
> core dumps after changing to a non-root user. %s\n", strerror(errno));
> }
> }
>
> I am just curious. What those lines suppose to do actually?
>
Fixed with r9870. The intent of the patch is to make certain that a
core is still dumped when the option to dump core is specified and the
Asterisk process isn't running as root.
--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
___
--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.3 Released - Critical Update... Thanks for the stability!
On 1/27/06, tim panton <[EMAIL PROTECTED]> wrote: > > > On 26 Jan 2006, at 12:22, Rich Adamson wrote: > > > However, in addition to the magic, anyone moving complete new code into > a high visibility production network without "first" testing it is nuts. > > > > I agree with you, but in this case, we test 1.2 stable, but not test in > "time machine" mode, i mean moving the system clock forward and > backward. I thing this bug take many people by Surprise. > > Obviously, it already did. Luckily out of all deployed systems, there were > not that many implementors that upgraded to v1.2.2 within the couple of > days since it was released. > > (Puts head above parapet and gets ready to be 'corrected'...) > > These sorts of time dependent bugs are almost impossible to find in > testing - this one only occurs every 48 days, so you'd have to have a > 7 week beta period to have tested it. And this is a 'simple' one > compared to leap seconds or whatever. > > If I read the patch right this was a bug where a signed 32bit quantity was > treated as if it were unsigned (or the other was around). > > You'll only catch this kind of thing with lint, and/or strict use of > macros/functions to do time comparisons. > > For the first time in 10 years I understand why all integer types in Java > are signed, which is ironic, I've just been grumbling about all those > 64 bit ints I need to represent IAX 32bit (unsigned) timestamps! > > (P.S. I love the hint that Mark contributed to the fix over a 9600baud > GPRS connection) > Mark has certainly had a busy week this week. In addition to the bug fix, he's also been on both coasts to do keynotes at the ITExpo sure in FL and then San Fran for O'Reilly's ETel. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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: click-to-call cleint
On 1/17/06, Phil Menico <[EMAIL PROTECTED]> wrote: > Paul, > > Can you give us the details on this: > > "a .call file is sent to asterisk, which then calls you, detects pickup, and > then calls the remote party. " > > I am interested in making this work. > http://www.voip-info.org/wiki-Asterisk+auto-dial+out -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] [PATCH] Fix bug in handle_request_info
On 1/13/06, Marc Haisenko <[EMAIL PROTECTED]> wrote: > Hi folks, > I spotted a bug in handle_request_info: in an "if" condition the code assumes > to receive NULL on error, while in fact it receives an empty string. The > attached trivial patch fixes this. > > Patch is done against chan_sip.c from r8023. > Patched. Thank you! In the future, please also check out http://bugs.digium.com/ for bug reports and patch posting so we've got a better cyber-papertrail of these types of reports. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] ztdummy? is it necessary?
On 12/28/05, Jason DiCioccio <[EMAIL PROTECTED]> wrote: > Greetings, > I was having a conversation with someone the other day and was informed > that ztdummy is basically unnecessary in BSD and perhaps in more recent > linux kernels. Is this indeed the case? Would you need to run asterisk > at a realtime priority for this to work? Getting rid of the ztdummy > requirement would be an amazing win for OS portability, as long as it > could rely on the OS's realtime timer. > This is more a question for asterisk-users, but there are certain applications (app_meetme) that require ztdummy if you don't already have a valid Zaptel timing source. They will not operate without it. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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 extra logging to file
You can set the debug and verbosity level either via command line param (-vvv [verbose] -ddd [debug) or via the CLI "set verbose " "set debug " On 12/28/05, ast guy <[EMAIL PROTECTED]> wrote: > /etc/asterisk/logger.conf, does it allow to set verbosity level input > to log file ? > > messages => notice,warning,error,debug,verbose > > but still extra detail is not logged into file! > > > > On 12/28/05, BJ Weschke <[EMAIL PROTECTED]> wrote: > > On 12/28/05, ast guy <[EMAIL PROTECTED]> wrote: > > > Hi! > > > Connecting to asterisk through command > > > # asterisk -r > > > > > > ( using ast_log fxn with LOG_VERBOSE option in code ) > > > > > > Gives me much logging for debug, even to the called functions line > > > number of included files on runtime at CONSOLE, but I'm unable to log > > > this level information to asterisk log file > > > (/var/log/asterisk/messages) > > > > > > > Yes. Take a look at the logger.conf file in /etc/asterisk to see what > > logging channels you'd like to put into what files. > > > > -- > > Bird's The Word Technologies, Inc. > > http://www.btwtech.com/ > > ___ > > --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 > > > ___ > --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 > -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] default value of ast_opt_priority_jumping
On 12/20/05, Russell Bryant <[EMAIL PROTECTED]> wrote: > As we all already know, the n+101 priority jumping behavior of > applications is being deprecated. > > For Asterisk 1.2, we made the default value of the global priority > jumping option to be on. However, if it was a new installation, > extensions.conf.sample has it turned off. > > I think it's time to make it off by default in the code in the > trunk. Agree? > Agree. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] New Jersey ATT Vocie T1 Asterisk Toll free not working
On 12/1/05, Charles Huang <[EMAIL PROTECTED]> wrote: > Hi, Alex: > > After taking your suggestion change from e&m to fxoks, it still did not > work, and this time even calling to normal PSTN number also failed? > > Any more suggestion? > > Charles > Is this a dedicated LD trunk or a DID PRI trunk from AT&T? If a dedicated LD trunk, many carriers often don't let you dial another provider's 8XX numbers off of it. Please take this thread to the -users forum for additional feedback on it. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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] app_page
On 11/17/05, Michael Anderson <[EMAIL PROTECTED]> wrote:
> I'm wanting to alter app_page so that I can specify an Alert Info sip
> header to send (our Polycoms are set to auto answer on that one).
> Eventually I would want to make it customizable, but for a first test
> I thought I'd try the following:
>
>
> static void *page_thread(void *data)
> {
>struct calloutdata *cd = data;
>struct ast_variable *var = ast_variable_new("Alert Info",
> "Ring Answer");
>
>ast_pbx_outgoing_app(cd->tech, AST_FORMAT_SLINEAR, cd->resource, 3,
>"MeetMe", cd->meetmeopts, NULL, 0, cd->cidnum,
> cd->cidname, var, NULL);
>free(cd);
>return NULL;
> }
>
>
> The variable doesn't seem to be delivered to the paged phone(s). Am I
> missing something, or perhaps using the wrong call?
>
> Thanks,
>
Michael,
I think you're looking for the pbx_builtin_setvar_helper function.
Doxygen docs about Asterisk functions can be found at
http://www.asterisk.org/doxygen/
BJ
--
Bird's The Word Technologies, Inc.
http://www.btwtech.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] Delphi ActiveX component
On 11/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi everybody. > > I need develop a IAX softphone with Delphi, but i didnt find a OCX component. > Anyone know how can I > find this component ? > > Tomas I don't believe one exists as part of the standard distribution. You're welcome to roll your own though around IAXLib. -- Bird's The Word Technologies, Inc. http://www.btwtech.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] How to start?
Welcome! You can go here for some initial information about the Asterisk architecture: http://www.digium.com/downloads/AstriconEurope2005Tutorial.pdf And once you're ready, you can visit this link for information on how to contribute: http://www.asterisk.org/developers On 11/8/05, Isack Waserman <[EMAIL PROTECTED]> wrote: > Hello All, > I am new to all of this. > I want to devlope a "C" application using the asterisk API. > I also want to (try) writ my own hardware driver for Asterisk. > Is it possible? > what steps i should take in order to start? > Thanks in advance > Isack > ___ > 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 > ___ 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] Current HEAD: res_config_odbc.c compilation failure
Please post a bug for this in bugs.digium.com. On 11/8/05, Patrick <[EMAIL PROTECTED]> wrote: > Hi all, > > I hope this is not considered a -users question. If so please accept my > apologies for the noise. Compilation of cvs HEAD from about two hours > ago fails in res_config_odbc.c with the following messages: > > gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -g -Iinclude -I../include -D_REENTRANT > -D_GNU_SOURCE -O6 -march=k8 -DZAPTEL_OPTIMIZATIONS -m64 > -fomit-frame-pointer -DZAPATA_MOH -DOPENSSL_NO_KRB5 -fPIC -c -o > res_config_odbc.o res_config_odbc.c > In file included from res_config_odbc.c:36: > ../include/asterisk/file.h:52: error: syntax error before '*' token > ../include/asterisk/file.h:52: warning: function declaration isn't a > prototype > ../include/asterisk/file.h:53: error: syntax error before '*' token > ../include/asterisk/file.h:53: warning: function declaration isn't a > prototype > res_config_odbc.c: In function 'realtime_odbc': > res_config_odbc.c:98: warning: implicit declaration of function > 'snprintf' > res_config_odbc.c:98: warning: incompatible implicit declaration of > built-in function 'snprintf' > res_config_odbc.c:105: warning: pointer targets in passing argument 2 of > 'SQLPrepare' differ in signedness > res_config_odbc.c:149: warning: pointer targets in passing argument 3 of > 'SQLDescribeCol' differ in signedness > res_config_odbc.c: In function 'realtime_multi_odbc': > res_config_odbc.c:242: warning: incompatible implicit declaration of > built-in function 'snprintf' > res_config_odbc.c:251: warning: pointer targets in passing argument 2 of > 'SQLPrepare' differ in signedness > res_config_odbc.c:303: warning: pointer targets in passing argument 3 of > 'SQLDescribeCol' differ in signedness > res_config_odbc.c: In function 'update_odbc': > res_config_odbc.c:370: warning: incompatible implicit declaration of > built-in function 'snprintf' > res_config_odbc.c:378: warning: pointer targets in passing argument 2 of > 'SQLPrepare' differ in signedness > res_config_odbc.c: In function 'config_odbc': > res_config_odbc.c:448: warning: incompatible implicit declaration of > built-in function 'snprintf' > make[1]: *** [res_config_odbc.o] Error 1 > > Any suggestions for a quick fix? > > Thanks and regards, > Patrick > > ___ > 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 > ___ 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] musiconhold -vs- musicclass problems setting the differnt class of music
You're right. The discrepancy does exist in the 1.0 tree. It was fixed recently in CVS-HEAD and should certainly be in 1.2b2 and later. On 11/5/05, Tilghman Lesher <[EMAIL PROTECTED]> wrote: > On Saturday 05 November 2005 12:45, Ronald Hartmann wrote: > > Please accept my apology regarding posting in this list, however > > I have posted in the users list and in the irc channel with no > > response. > > This list is not an appeals process for "I asked elsewhere and got > no response." It is the list for development issues. This is very > clearly a user issue. > > > Problem I am unable to set different music classes for different > > extensions. > > Problem is that you never set the musiconhold class for the incoming > call. You set the musiconhold class only for the channel ANSWERING > the call. See application SetMusicOnHold. > > -- > Tilghman > ___ > 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 > ___ 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] Bug 4301 - ztdummy accuracy problem
Are you using the name/record playback option? On 10/18/05, Chih-Wei Huang <[EMAIL PROTECTED]> wrote: BJ Weschke wrote:>> The bug was closed because the ztdummy behavior is not the specific cause > for the delay problem. That patch with USE_RTC was intended to make use of> the real time resource available within the kernel >= 2.6.13 instead of> relying on a OHCI USB resource which was the case previously. But USE_RTC also compile for kernel < 2.6.13..(at least, 2.6.9 in my system)Is kernel >= 2.6.13 necessary?> If you're looking for a "fix" in MeetMe, some have reported success with > applying the patches available in bug 5374.Thank you for the info.I tried that patch.Unfortunately, it seems not improve the increasing delay problemof meetme.Any suggestion or experience for the delay problem? especially using with OH323 channel driver.___Asterisk-Dev mailing listAsterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-devTo UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ 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] Open source time card application for Asterisk
From an infrastructure perspective, you're right. From an ASP perspective, you're wrong. http://www.spooftel.com/ - "Spoof your own Caller ID for $0.10/min" If you're using GMail a number of other providers come advertised alongside this thread. :-) For that very reason, the only way one could truly verify someone's location via CID would be to do a callback to the CID supplied. On 9/23/05, Gilmore, Gerry <[EMAIL PROTECTED]> wrote: Chuck, Actually, Caller ID cannot – so far as I know – "easily be spoofed". While you can usually disable sending "caller ID" by the *6x method, be aware that if you call an 800 number, that 800 number * will* get the calling party number. It's needed for billing the 800# recipient. With PRI, if you have it correctly provisioned by the carrier and they support it, etc., you can legitimately spoof a caller name and number, but I doubt a nurse or janitor would maintain a PRI line to do this. J Gerry There are 10 kinds of people in the world, those who understand binary and those who don't. Gerry Gilmore Field Applications Engineer Intel Corporation (http://www.intel.com ) From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Chuck BunnSent: Friday, September 23, 2005 12:14 PM To: Asterisk Developers Mailing ListSubject: Re: [Asterisk-Dev] Open source time card application for Asterisk Joseph wrote: On Fri, 2005-09-23 at 09:34 -0600, Chuck Bunn wrote: Hi, I am in the process of developing a time card application that integrates with Asterisk and I would like to know if anyone has done this and if so can you recommend an open source time card application that might reduce the amount of work required to connect it to Asterisk. I do not want to reinvent the wheel and write a WEB based time card app, I would rather spend my time getting Asterisk to connect to it. I will be using LAMP so it will be written in PHP instead of C... Thanks Do you mean employee time-card? With mysql database this would be very interesting project.Do you have a short description of what it would do? Hi,Thanks for responding. The basic system would work as follows. An employee would call in and would transfer to a menu (either via an operator or via the phone system if no operator is available). Something like press 1 for sales and service press 2 for accounting and press 3 if you are an employee. Upon pressing three the user would be asked to enter their employee ID and password. The system would capture the employee ID , time of day and if available the caller ID from the location they are calling from. When they are finished they would repeat the process thus capturing the finish data for filling out a time card. The usage is a group of field nurses that need an easy way to enter data into there time cards since the Internet is not always available from the locations they call from. Although the caller ID can easily be spoofed this is not as important as capture of the time and employee data for filling out a time card. A second application uses the same theory but for janitors. The caller ID helps confirm they are where they are supposed to be. There are several PHP time cards out there but I am trying to find the best for interfacing with Asterisk. Phase one would be to capture the data to a flat file phase 2 would be to get it into a database, phase three would interface it to an existing LAMP based time card apt and phase 4 would allow for phone access to information stored in the time card such as how many hours worked, hours by day etc. A final phase would interface these to both Peachtree and Quickbooks. I am working on a more definitive outline right now but I wanted some feedback from the development community before doing so, so that I did not reinvent the wheel.Thanks ___Asterisk-Dev mailing listAsterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-devTo UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ 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] SIP REINVITE
On 5/16/05, Olle E. Johansson <[EMAIL PROTECTED]> wrote: > BJ Weschke wrote: > > Server A (IP 192.168.1.1) > > Server B (IP(s) 192.168.1.2 [actual] 192.168.1.3 [vip]) > > Server C (IP(s) 192.168.1.4) > > > > All servers are Asterisk installs. All servers have SIP canreinvite=yes. > > > > Server A calls Server B on his VIP. The call sets up fine, but the > > 3rd of 4th step in the dial plan is to then transfer that call on to > > Server C. Server B dials server C and then begins to attempt a native > > bridge between Server A and C. Server A responds back with "SIP/2.0 > > 482 Loop Detected" assumably because the man in the middle has > > different terminating/originating IP addresses and has sent an > > improper invite back to A to start the briding process. > Can you send me a packet trace of this? Sure. You want a raw packet trace, or just a "sip debug" trace from *? I won't be able to get packet traces from server A right off the bat, as that one is my carrier's and not my own, but my guess is the problem originates with server B. > > > Does ANTHM's patch from a few weeks back to chan_sip fix this > > problem, or is this still a "live" issue? If it is patched, who needs > > the patch in the scenario above? Just server B? or Servers A and C > > too? > I haven't seen the loop detected issue, but understand where it's coming > from. Anthm's patch is more to be seen as a proof-of-concept than > something you want to use. I'm trying to continue the work based on his > patch, but it will require a lot of changes to chan_sip. > > I'm glad to see another person wanting to transfer calls from Asterisk > to another SIP domain - I just had a question from a core developer on > the theme "why would anyone want to do that?"... So I needed your mail > to prove that's it is not only me and my customers that need that function. > > Digging into how chan_sip handles transfers I'm amazed that it work with > anything... ;-) > > /Olle > Well, looking at the code, it looks that it was designed to work under very simple circumstances. If we present any kind of complex setup, the logic there is going to fall down. My guess is that if server B used it's VIP as the originating IP as oppsed to it's native IP when it makes that initial dial to server C, the logic in place now would work when server B was told to bridge the two calls from Server A to B and B to C together natively. That's a "quick and dirty" for just my scenario, but I'd by interested in contributing time and resources towards "doing it right" if that effort is underway already. BJ ___ 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
