Re: [asterisk-dev] Jira / Gerrit Integration Issue

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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 

Re: [asterisk-dev] ARI Bridge Behavior

[BJ Weschke]

 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

[BJ Weschke]

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 
 david.radcli...@clockworkit.co.uk 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
 image001.jpg
 Clockwork IT Ltd
 tel: 08448 040950
 mob: 07764 155251
 image002.jpg 
  WWW.SUPPORTDESKPRO.CO.UK
 image003.png  image004.pngimage005.jpg
 image006.gif
 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

[BJ Weschke]

+1

This sounds more than reasonable to me.

Sent from my iPhone

 On Nov 10, 2014, at 5:57 PM, Matthew Jordan mjor...@digium.com 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

[BJ Weschke]

On 11/6/14, 4:04 PM, Matthew Jordan wrote:



  eg -
Playback(http://myserver.com/monkeys.wavhttp://myserver.com/can.wavhttp://myserver.com/act.wavhttp://myserver.com/like.wavhttp://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-monkeysweasels anyway?)

snip


 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

[BJ Weschke]

 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] Asterisk 14 - Remote URI Playback

[BJ Weschke]

On 11/4/14, 3:40 PM, Matthew Jordan wrote:

On Tue, Nov 4, 2014 at 12:57 PM, BJ Weschke bwesc...@btwtech.com 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.wavhttp://myserver.com/can.wavhttp://myserver.com/act.wavhttp://myserver.com/like.wavhttp://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 List of [Sound] in the cache
PUT /media_cache (note: would need to have parameters passed in the body)
 uri=URI to retrieve the media from
 headers=JSON

Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)

[BJ Weschke]

On 10/22/14, 12:14 PM, Paul Albrecht wrote:

On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com 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] AstriDevCon 2014: Agenda item DeprecateAMI/AGI(Ben Klang)

[BJ Weschke]

On 10/22/14, 3:06 PM, Paul Albrecht wrote:

On Oct 22, 2014, at 11:47 AM, BJ Weschke bwesc...@btwtech.com wrote:


On 10/22/14, 12:14 PM, Paul Albrecht wrote:

On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com 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] Deprecate every '* reload' CLI command?

[BJ Weschke]

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 modulename'
 - 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

[BJ Weschke]

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?

[BJ Weschke]

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] Call Specific MOH

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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?

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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.

[BJ Weschke]

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] DSP pci board.

[BJ Weschke]

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...

 snip

 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] What to do with RTCP ????

[BJ Weschke]

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

[BJ Weschke]

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 port RTP/AVP codec 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?

[BJ Weschke]

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] Asterisk 1.2.3 Released - Critical Update... Thanks for the stability!

[BJ Weschke]

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

[BJ Weschke]

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

[BJ Weschke]

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] Asterisk extra logging to file

[BJ Weschke]

 You can set the debug and verbosity level either via command line
param (-vvv [verbose] -ddd [debug) or via the CLI set verbose
level set debug level

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] ztdummy? is it necessary?

[BJ Weschke]

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] default value of ast_opt_priority_jumping

[BJ Weschke]

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

[BJ Weschke]

On 12/1/05, Charles Huang [EMAIL PROTECTED] wrote:
 Hi, Alex:

  After taking your suggestion change from em 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 ATT? 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

[BJ Weschke]

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:

 snip from app_page.c
 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;
 }
 /snip

 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

[BJ Weschke]

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] Current HEAD: res_config_odbc.c compilation failure

[BJ Weschke]

 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] How to start?

[BJ Weschke]

 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] musiconhold -vs- musicclass problems setting the differnt class of music

[BJ Weschke]

 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

[BJ Weschke]

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] SIP REINVITE

[BJ Weschke]

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