Re: [asterisk-dev] Infrastructure move to GitHub

[James Finstrom]

I assume this is asterisk/asterisk on github The about still
reflects it as a mirror

---

About

Mirror of the official Asterisk (https://www.asterisk.org) Project
repository. No pull requests here please. Use Gerrit:

gerrit.asterisk.org

---

On Mon, Apr 3, 2023 at 1:25 PM Sean Bright  wrote:
>
> On 4/3/2023 11:11 AM, George Joseph wrote:
> > Last year we announced we were planning to move away from the Atlassian 
> > products (Jira, Confluence, etc), Gerrit and Jenkins to GitHub.  That time 
> > is upon us.
>
> This is great news. Thanks to you and everyone else who's been working on 
> this!
>
> Kind regards,
> Sean
>
>
> --
> _
> -- 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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] OpenAPI 3.1 API description for ARI

[James Finstrom]

I did convert and manually clean up the spec once.  This obviously
isn't  maintained

https://gist.github.com/jfinstrom/6f4e130804d5b2965fe9aab29d3b8ff8

On Fri, Jun 24, 2022 at 10:18 AM Joshua C. Colp  wrote:
>
> On Fri, Jun 24, 2022 at 2:11 PM Nicolas HEDGER  wrote:
>>
>> Hi,
>>
>> I noticed that ARI’s API description uses Swagger 1.1, which is at least a 
>> few years old.
>>
>> I was wondering if there’d be interest in an OpenAPI 3.1 version, in which 
>> case I’d be willing to contribute.
>>
>> It would probably allow using more current tools to generate API clients.
>
>
> I'm sure someone would like it. The issue though is not just writing the 
> definitions. The existing JSON files are actually used to produce generated 
> base code for things so that also has to change. There would also need to be 
> backwards compatibility present, to be allowed in older versions.
>
> --
> 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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] IRC Channels Moved To Libera Chat!

[James Finstrom]

Remember libera not libra

On Wed, May 26, 2021, 4:50 AM Joshua C. Colp  wrote:

> Greetings all,
>
> For those who may not have seen the blog post[1] or the comments on IRC
> itself, we've moved the Asterisk IRC channels to the new Libera Chat
> network[2]. You can find the #asterisk-dev channel over there just like
> normal, with myself (as file) there amongst others!
>
> [1] https://www.asterisk.org/irc-channels-moved-to-libera-chat/
> [2] https://libera.chat
>
> --
> 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] Proposal for New Major Version Process Change

[James Finstrom]

Well if it got Dan Jenkins excited :)

I dig it.

On Wed, Jul 8, 2020 at 6:25 AM Dan Jenkins  wrote:
>
> YES YES YES.
>
> I never really got why it was done like it was...
>
> I agree, 4-6 weeks is good. If someone's going to take the time to upgrade to 
> an 18 RC then they'll be looking to test it and give feedback etc etc so you 
> don't need a huge amount of time... just enough to actually action bug fixes 
> and then release new RCs with those bug fixes
>
> Dan
>
>
>
> On Wed, Jul 8, 2020 at 2:14 PM Joshua C. Colp  wrote:
>>
>> On Wed, Jul 8, 2020 at 9:56 AM Jared Smith  wrote:
>>>
>>> On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp  wrote:
>>>>
>>>> 1. It leaves a confusing area for developers where we have to ask "should 
>>>> this go into 18.0?"
>>>> 2. It confuses users because if they upgrade to 18.0.0 then it is likely 
>>>> the other current releases have bug fixes they don't have, which has 
>>>> caused issues for users in the past.
>>>
>>>
>>> I agree with these two points of confusion.
>>>
>>>> What do people think? Do we believe that a month out is ample enough?
>>>
>>>
>>> I think somewhere between four and six weeks is more than adequate, given 
>>> the maturity of the project.
>>
>>
>> That's my thinking too. I also think despite not creating actual tarballs we 
>> could still reach out on the asterisk-users list and the Discourse early to 
>> inform people that the branch has been created and while a release candidate 
>> has not yet been created that it can still be retrieved from Git or Github 
>> and used/tested.
>>
>> --
>> 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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] res_calendar_exchange: anyone using it?

[James Finstrom]

When I wrote the calendar functionality in to FreePBX I was originally
going to use res_calendar.  It ultimately wasn't flexible enough for
my ambitions and as far as I could tell not many folks use
res_calendar.  Even asking during planning I received a lot of dunno
answers

On Thu, Oct 24, 2019 at 2:34 PM Sean Bright  wrote:
>
> Hi,
>
> The res_calendar_exchange module currently relies on a library
> (libiksemel) that is abandoned and is being dropped from recent distros.
> I've converted it over to use libxml2 (which is already a required
> dependency of Asterisk), but I don't have an environment in which to test.
>
> Would anyone be willing and/or able to help me test? If so, the review
> and patch is here:
>
>  https://gerrit.asterisk.org/c/asterisk/+/13124
>
> If I don't hear back in a couple days, I will try on the asterisk-users
> list.
>
> Kind regards,
> Sean
>
> --
> _
> -- 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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk and CentOS 8

[James Finstrom]

Oh right I also "dnf config-manager --set-enabled PowerTools"
So that probably helped me some.

to be honest I am not sure if these pre-reqs are documented anywhere. I
have been using a list that originates from way back to do I dare say the
trixbox days.  Things get added to the list but rarely removed.


On Thu, Oct 17, 2019 at 12:41 PM Corey Farrell  wrote:

> iksemel-devel: To my knowledge library is not maintained and has been
> removed from Fedora because it no longer builds from source.  Honestly I
> thought we had deprecated res_xmpp and chan_motif for this very reason.
>
> libedit-devel: This is mandatory since Asterisk 16.  The devel package is
> found the in PowerTools repository which is not enabled by default.
>
> Other stuff install_prereq installs from the PowerTools repo:
>
> bluez-libs-devel
> doxygen
> gsm-devel
> libogg-devel
> libsndfile-devel
> libsrtp-devel
> libvorbis-devel
> lua-devel
> neon-devel
> speex-devel
> speexdsp-devel
>
> Why RedHat decided to hide these devel packages in a repository that is
> disabled by default it is beyond me.
>
>
> On 10/17/19 2:24 PM, George Joseph wrote:
>
>
>
> On Thu, Oct 17, 2019 at 12:03 PM James Finstrom 
> wrote:
>
>> I started writing
>> https://github.com/jfinstrom/just-a-wiki/wiki/FreePBX-on-Centos-8 when
>> Centos 8 launched. It actually 90% works.
>> FreePBX itself has some weird stuff happening and I haven't had time to
>> revisit it. That said the asterisk portion built just fine.
>>
>
> Here are the missing packages.  I guess as long as you don't need any of
> their functionality you could be OK but libsrtp is a big one.
>
> libedit-devel
> speex-devel
> speexdsp-devel
> libogg-devel
> libvorbis-devel
> xmlstarlet
> neon-devel
> gmime-devel
> lua-devel
> uriparser-devel
> bluez-libs-devel
> freetds-devel
> iksemel-devel
> corosynclib-devel
> spandsp-devel
> libresample-devel
> libsrtp-devel
> gsm-devel
> doxygen
> hoard
> codec2-devel
> libsndfile-devel
>
>
>
>>
>> On Thu, Oct 17, 2019 at 9:19 AM George Joseph  wrote:
>>
>>> At the current time, we do not recommend attempting to build Asterisk on
>>> CentOS 8.  Many packages Asterisk uses are not yet available and would
>>> require building from their sources.  The Asterisk packages are also not
>>> available in the EPEL 8 or CentOS 8 repositories yet for the same reason.
>>>
>>> We'll update you when we think it's safe.
>>>
>>> --
>>> *George Joseph*
>>> Digium - A Sangoma Company | Software Developer | Software Engineering
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>>> direct/fax: +1 256 428 6012
>>> Check us out at: https://digium.com · https://sangoma.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
>>
>>
>>
>> --
>> *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 --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk and CentOS 8

[James Finstrom]

I went off a list I had + the "contrib/scripts/install_prereq install"
script. It didn't complain but I guess it would just set flags
accordingly.  Hadn't gotten to the point of testing and configuring because
of the FreePBX weirdness.

Carry on :)



On Thu, Oct 17, 2019 at 11:25 AM George Joseph  wrote:

>
>
> On Thu, Oct 17, 2019 at 12:03 PM James Finstrom 
> wrote:
>
>> I started writing
>> https://github.com/jfinstrom/just-a-wiki/wiki/FreePBX-on-Centos-8 when
>> Centos 8 launched. It actually 90% works.
>> FreePBX itself has some weird stuff happening and I haven't had time to
>> revisit it. That said the asterisk portion built just fine.
>>
>
> Here are the missing packages.  I guess as long as you don't need any of
> their functionality you could be OK but libsrtp is a big one.
>
> libedit-devel
> speex-devel
> speexdsp-devel
> libogg-devel
> libvorbis-devel
> xmlstarlet
> neon-devel
> gmime-devel
> lua-devel
> uriparser-devel
> bluez-libs-devel
> freetds-devel
> iksemel-devel
> corosynclib-devel
> spandsp-devel
> libresample-devel
> libsrtp-devel
> gsm-devel
> doxygen
> hoard
> codec2-devel
> libsndfile-devel
>
>
>
>>
>> On Thu, Oct 17, 2019 at 9:19 AM George Joseph  wrote:
>>
>>> At the current time, we do not recommend attempting to build Asterisk on
>>> CentOS 8.  Many packages Asterisk uses are not yet available and would
>>> require building from their sources.  The Asterisk packages are also not
>>> available in the EPEL 8 or CentOS 8 repositories yet for the same reason.
>>>
>>> We'll update you when we think it's safe.
>>>
>>> --
>>> *George Joseph*
>>> Digium - A Sangoma Company | Software Developer | Software Engineering
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>>> direct/fax: +1 256 428 6012
>>> Check us out at: https://digium.com · https://sangoma.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
>>
>>
>>
>> --
>> *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 --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk and CentOS 8

[James Finstrom]

I started writing
https://github.com/jfinstrom/just-a-wiki/wiki/FreePBX-on-Centos-8 when
Centos 8 launched. It actually 90% works.
FreePBX itself has some weird stuff happening and I haven't had time to
revisit it. That said the asterisk portion built just fine.

On Thu, Oct 17, 2019 at 9:19 AM George Joseph  wrote:

> At the current time, we do not recommend attempting to build Asterisk on
> CentOS 8.  Many packages Asterisk uses are not yet available and would
> require building from their sources.  The Asterisk packages are also not
> available in the EPEL 8 or CentOS 8 repositories yet for the same reason.
>
> We'll update you when we think it's safe.
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Voice Messaging Platform

[James Finstrom]

In review with peers it seems my metaphor may have overstepped and I
apologise.

My point was it seems this appears as some form of business venture rather
than resolving a direct deficit within asterisk.

Asterisk is an engine and many products are derived from it.  The mentioned
service does not seem to offer anything asterisk cannot do. So getting
someone to build a similar solution with asterisk as the engine will be
more successful if you provide detailed desires and a more specific benefit
to the person you are trying to attract.

Specific compensation and a roadmap should be provided to get proper
qualified attention.



On Tue, Oct 23, 2018, 6:57 AM hasan malik  wrote:

> james finstrom,
> i find your response insulting.
> i suggest you pick up a copy of how to win friends and influence people or
> some similar title.
>
>
>
> On Mon, Oct 22, 2018 at 11:34 PM James Finstrom 
> wrote:
>
>> It seems you are not looking for "Asterisk Development" but someone
>> who will build out a platform using asterisk.  You may have better
>> luck on the asterisk-business or asterisk-users list.  Again you will
>> want to spec out what exactly you want and what you are willing to pay
>> for it. Currently this reads as, someone remake facebook for me and I
>> will pay you some random amount of money.
>> On Mon, Oct 22, 2018 at 12:54 AM hasan malik 
>> wrote:
>> >
>> > hello james,
>> > comsys.net has many big telecom providers buying their platform.
>> > they are not cheap, but they know what they're doing.
>> > what is your experience in voice messaging?
>> > i'm looking for someone who has done this for someone else.
>> > if you are starting from scratch...big learning curveit is probably
>> not a good fit.
>> >
>> > On Mon, Oct 22, 2018 at 8:27 AM James Finstrom 
>> wrote:
>> >>
>> >> What feature(s) do you feel are missing?
>> >> What is the bounty you are willing to pay?
>> >>
>> >> I am thinking an email this vague will yeild no real return.
>> >>
>> >> On Wed, Oct 17, 2018, 6:17 PM hasan malik 
>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Bounty will be paid.
>> >>>
>> >>> Looking for voice messaging platform like comsys.net
>> >>>
>> >>> Please contact me directly: hasanxmalik at gmail dot com.
>> >>>
>> >>> Thank you.
>> >>> --
>> >>> _
>> >>> -- 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
>>
>>
>>
>> --
>> 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. P

Re: [asterisk-dev] Voice Messaging Platform

[James Finstrom]

It seems you are not looking for "Asterisk Development" but someone
who will build out a platform using asterisk.  You may have better
luck on the asterisk-business or asterisk-users list.  Again you will
want to spec out what exactly you want and what you are willing to pay
for it. Currently this reads as, someone remake facebook for me and I
will pay you some random amount of money.
On Mon, Oct 22, 2018 at 12:54 AM hasan malik  wrote:
>
> hello james,
> comsys.net has many big telecom providers buying their platform.
> they are not cheap, but they know what they're doing.
> what is your experience in voice messaging?
> i'm looking for someone who has done this for someone else.
> if you are starting from scratch...big learning curveit is probably not a 
> good fit.
>
> On Mon, Oct 22, 2018 at 8:27 AM James Finstrom  wrote:
>>
>> What feature(s) do you feel are missing?
>> What is the bounty you are willing to pay?
>>
>> I am thinking an email this vague will yeild no real return.
>>
>> On Wed, Oct 17, 2018, 6:17 PM hasan malik  wrote:
>>>
>>> Hello,
>>>
>>> Bounty will be paid.
>>>
>>> Looking for voice messaging platform like comsys.net
>>>
>>> Please contact me directly: hasanxmalik at gmail dot com.
>>>
>>> Thank you.
>>> --
>>> _
>>> -- 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



-- 
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] Voice Messaging Platform

[James Finstrom]

What feature(s) do you feel are missing?
What is the bounty you are willing to pay?

I am thinking an email this vague will yeild no real return.

On Wed, Oct 17, 2018, 6:17 PM hasan malik  wrote:

> Hello,
>
> Bounty will be paid.
>
> Looking for voice messaging platform like comsys.net
>
> Please contact me directly: hasanxmalik at gmail dot com.
>
> Thank you.
> --
> _
> -- 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

[asterisk-dev] GPG Key signing

[James Finstrom]

I personally am offering to sign GPG keys for the #WebOfTrust at Astricon.
Note this is not an official venture and is not related to my employer or
related projects. Submit a request at:  https://t.co/0ti9v9rpMr I will
setup several meeting times to do physical verification including devcon
breaks #PGP
-- 
_
-- 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

[James Finstrom]

Modou please do not hijack other peoples messages.

As mentioned in your original email

Quote:

This list is for the purpose of developmental discussion of the
Asterisk source code.  For discussion of taxation in VoIP services,
you might find a better response on the asterisk-biz list or the
asterisk-users list.
On Wed, Sep 12, 2018 at 12:45 PM modou lo  wrote:
>
> hi Dear Member can i have your helping i want to have a code which help me to 
> taxe users services voip/toip each calling in asterisk.
>
> Le mer 12 sept. 2018 19:33, i...@magnussolution.com  
> a écrit :
>>
>> 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-conferenc

Re: [asterisk-dev] write my self app. Debug

[James Finstrom]

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] Adding a call preemption feature

[James Finstrom]

I wasn't saying it was an invalid feature at all,  I just see the
ramifications of these features because someone set something wrong. Their
system starts doing obscure things and you spend way too much time tracking
it down.  In general the user experience which is also heavily linked to
their customer experience is  paramount.  So dropping calls in most cases
without warning is not ideal.

I also think for these types of things the ideal of ARI is absolutely
perfect.

On Mon, Nov 13, 2017 at 3:17 PM, Phil Mickelson <p...@cbasoftware.com>
wrote:

> Jean,
>
> You should know that I wrote something very similar to what you are asking
> for.  Slightly different reasons and I use ARI which makes it very easy.
> However, the result is the same.  The inbound call gets terminated.
>
> For those of you who don't know why you'd do this here's the situation:
> If you're running a live operator answering service and have a customer who
> hasn't and won't pay their bill but still forwards the calls.  Unless you
> terminate the call when it comes in then you have operators answering calls
> where they have to tell the caller they're not going to get taken care of.
> It's much easier to just terminate the call before it's answered.  ARI
> makes this very easy.  And, BTW, it get the customer's attention very
> quickly.  And, the bill is generally paid!
>
> Everyone has some feature that's important to them.  Just because you
> don't understand or see the reason doesn't mean it's not valid.
>
> On Mon, Nov 13, 2017 at 4:47 PM, Jean Aunis <jean.au...@prescom.fr> wrote:
>
>> Le 13/11/2017 à 17:58, Steve Edwards a écrit :
>>
>> On Mon, 13 Nov 2017, James Finstrom wrote:
>>
>> Generally the idea of arbitrarily killing calls seems awful, even if the
>> behavior is expected. Yeah so john we need to . RING John is
>> confused, your brain has to reset because whatever was happening no longer
>> matters.
>>
>>
>> At least play a message like "The boss needs to call his
>> mom/bookie/hooker. Thank you for understanding, your call just wasn't
>> important enough. Better luck next time -- and have a great day."
>>
>>
>>
>> Thank you for your remarks. The fact is, it is not a question of user
>> experience. We are working on critical communication networks, in which
>> network resources are limited. Hanging up a low priority call to leave room
>> to another is not an option, it is an absolute necessity, and it must be
>> done in near real-time. We cannot afford to play any announcement.
>>
>> By the way, I think call preemption is a native feature of ISDN networks
>> (at least it's my understanding of the MLPP stuff, but I'm not a ISDN
>> expert). But it is probably not used very often.
>>
>> --
>> _
>> -- 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
>



-- 
*James Finstrom*
Guy who does stuff that is sometimes cool


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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Adding a call preemption feature

[James Finstrom]

Generally the idea of arbitrarily killing calls seems awful, even if the
behavior is expected.

Yeah so john we need to . RING John is confused, your brain has
to reset because whatever was happening no longer matters.

You can have priority queues and allow the agents to manage the transition
rather than have the carpet yanked from their feet.

For the most part, arbitrary automation of call control between 2 humans
should avoided IMHO.

On Mon, Nov 13, 2017 at 2:31 AM, Jean Aunis  wrote:

> Hello,
>
> As I highlighted recently on the asterisk-users list (
> http://lists.digium.com/pipermail/asterisk-users/2017-November/292079.html),
> there is no native way in Asterisk to implement call preemption. By call
> preemption, I mean the following :
>
> - given calls have a priority, which may be notified by the network (see
> the SIP header Priority for instance), or which may be set by another way
>
> - given the number of calls to or from a given peer is limited
>
> - when this limit is reached, and an additional call comes in with a
> higher priority than previous ones, one of these calls should be hanged up
> to leave room to the new call.
>
> At the moment, it is possible to limit the number of calls to a peer using
> the GROUP/GROUP_COUNT functions. It is also possible to list all channels
> in Asterisk and choose one to hangup in an AGI script, but there is no way
> to list channels in a particular group. And there is no concept of priority
> attached to a channel.
>
> Therefore, I plan to add a new dialplan application which would preempt a
> channel in a particular group, below a given priority. It would be used
> this way : ChannelPreempt(mygroup,5) where "mygroup" is the group in which
> to look for a channel to hangup, and "5" is the priority below which the
> channel must by chosen. The application would return the preemption status
> and the preempted channel in channel variables.
>
> I would like to have your opinions about the best way to implement this.
> Here are my thoughts so far:
>
> 1- add a "priority" field to the channel structure
>
> 2- allow the CHANNEL function to read and write this field
>
> 3- inside the new ChannelPreempt application:
>
> - loop through the group list, and find the channel in the given group
> with the lowest priority
>
> - if this priority is lower than the provided one, hangup the selected
> channel with ast_softhangup
>
> - otherwise, do nothing
>
> - set the following dialplan variables on completion:
>
> * PREEMPTION_STATUS: "SUCCESS" if we found a channel to hang up,
> "FAILURE" otherwise
>
> * PREEMPTED_CHANNEL: the name of the channel that was hanged up in
> case of success, empty otherwise
>
> By the way, would this feature have a chance to be merged upstream ?
>
> Regards
>
> Jean Aunis
>
>
> --
> _
> -- 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




-- 
James
-- 
_
-- 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] One sip stack to rule them all....

[James Finstrom]

>From my original email:

"""
So one of the things that is needed to finally put Chan sip to bed is
feature parody.  Someone brought up CCSS.
What features do you feel you would lose going from chan_sip to pjsip.
Are there any bugs in pjsip that keep you from migrating?
"""

To clear up the tl;dr was what needs to happen to get you to convert.

The goal of this was to find the path that gets us to the goal of wide
spread adoption of pjsip.  Pjsip seems to get a lot of criticism but most
of it is not constructive.   There needs to be constructive feed back that
is better thought out than "it sucks" or "it is buggy".

What is it YOU are missing to transition?

Documentation? Is there something not covered?

https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip
https://wiki.asterisk.org/wiki/display/AST/Migrating+from+chan_sip+to+res_pjsip

Bugs?
Sean did https://issues.asterisk.org/jira/browse/ASTERISK-27309
Is there any specific open bugs of concern?
Do you have a reproducible unreported bug?
Do you have a feature in chan_sip that doesn't exist in pjsip that is not
in sean's ticket?

Help the developers help you. Documentation was mentioned at devcon and in
this post.
Again if there is something NOT on the wiki, or something that needs to be
stripped down to simpler terms bring it up so someone can write it.



On Tue, Oct 10, 2017 at 2:40 PM, Matt Fredrickson <cres...@digium.com>
wrote:

>
>
> On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord <ule...@gmail.com> wrote:
>
>> As James mentioned at the top, chan_sip is already de facto deprecated.
>>  The discussion (at devcon) was centered around making it _officially_
>> deprecated.
>>
>> For clarity, deprecation is NOT the same thing as removal.  (It is also
>> not depreciation, the reduction in value of something.)  Deprecation is the
>> declaration that something is not approved.  Using chan_sip has not been
>> recommended for a long time.
>>
>> It _is_ important to officially deprecate chan_sip because it is really
>> isn't being maintained as it would otherwise need to be.  There is no
>> reasonable way _to_ maintain it.   Users should _know_ of that status, and
>> that status is highly unlikely to change.
>>
>
>> What is _also_ needed, however, is more use of PJSIP and reports of
>> specific problems, and specific deficits of PJSIP so that the fear can be
>> eased before, at some point many years from now, chan_sip just doesn't work
>> any more.
>>
>
> I think it's probably premature to conclude that marking chan_sip
> deprecation is the right answer at this time.  I would argue that there are
> many more modules in Asterisk's code base that have less maintenance than
> chan_sip but are still permitted to be there.
>
> I do think that the exercise of finding problematic scenarios and missing
> features is useful right now, as it allows us to continue to improve
> chan_pjsip and see if there are problematic scenarios or missing critical
> features.  But my point of view is what I have already said - it is
> premature to mark it as deprecated.
>
> Matthew Fredrickson
>
>
>>
>
>>
>> On Sun, Oct 8, 2017 at 12:56 PM Troy Bowman <t...@lump.net> wrote:
>>
>>> I sincerely hope they don't deprecate it.  The pjsip code might seem
>>> fine in development and test environments, but I am still afraid of using
>>> it in production.  I see too many issues with it regularly on this list.  I
>>> can't gamble stability versus my job security.
>>>
>>> From my perspective, chan_sip doesn't get bugfixes because it doesn't
>>> seem to need them.  It just works.  I have had zero issues with it for
>>> several years.
>>>
>>>
>>> On Sun, Oct 8, 2017 at 8:55 AM, James Finstrom <jfinst...@gmail.com>
>>> wrote:
>>>
>>>> One does not simply depricate a sip stack.
>>>>
>>>> Ok so at devcon there was a discussion of depricating chan_sip. This
>>>> may sound a lot worse than it actually is. Chan_sip has been essentially
>>>> untouched in 4ish years. It does not receive bug fixes. It is just sort of
>>>> a barge floating in the ocean.
>>>>
>>>> So one of the things that is needed to finally put Chan sip to bed is
>>>> feature parody.  Someone brought up CCSS.
>>>>
>>>> What features do you feel you would lose going from chan_sip to pjsip.
>>>>
>>>> Are there any bugs in pjsip that keep you from migrating?
>>>>
>>>> --
>>>> _
>>

Re: [asterisk-dev] One sip stack to rule them all....

[James Finstrom]

A large percentage of "PJSIP" Sucks comes down to comfort.  I talked to
several users at astricon and the summary is:

Every provider that actually provides documentation only gives a chan_sip
block
We don't understand how to configure it.
My customers need ccss.

So one issue with feature parody and mostly people who simply don't want to
configure it.

The process of eventual removal when the ball gets rolling to do so is
several releases away.
PJSIP is already in use on Digium's commercial platform which shows their
level of confidence in the stack.

This ultimately comes down to the chicken vs the egg.
Once major adoption occurs PJSIP will become a rock. PJSIP will become a
rock when major adoption occurs.

Looking at the tracker chan_sip has 233 open bugs, Chan_pjsip 38.
So if our metric is "bugs" then there is a clear winner

Remember the golden rule of software. No ticket, no bug.

Side note remember if it is removed in say Asterisk 19 (made up scenario)
You don't have to use 19. All the previous releases will still have it.


On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord  wrote:

> I obviously failed to sufficiently emphasize the point.  Whether you like
> it or not, whether you think pjsip is ready or not, whether it is better or
> not, chan_sip is effectively at a dead end.Unless some miraculously
> talented and motivated person emerges to maintain chan_sip (which is
> somewhat less likely than my dead grandmother taking up x86 assembly),
> there is no future for it.  The discussion is not about that.  There is no
> discussion about that.  This is not about chan_sip vs chan_pjsip.  It is
> pointless to wax about the perceived solidity of chan_sip.  It is not
> solid.  It is not maintainable.  It is already years behind.  People have
> managed to patch it into a simulacrum of stability under certain use cases
> (though I will admit that those use cases are wide and, in a
> self-fulfilling manner, perhaps do represent the majority of present use
> cases of active users of chan_sip), but this will not and has not continued.
>
> Factual deprecation itself is not even under discussion.  chan_sip _is_
> deprecated, whether that is officially acknowledged or not.
>
> Rather, this discussion is about making sure lurkers who are still using
> chan_sip but have not reported specific problems or feature gaps have their
> say, are aware that chan_sip is NOT the recommended stack, and understand
> that chan_sip will (again, whether anyone likes it or not) progressively
> worsen as time progresses.
>
>
> On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman 
> wrote:
>
>> I would agree with this. We have tried to deploy pjsip several times over
>> the last year with limited success.
>> We have had nothing but issues with database real-time deployments.
>> Tables not working from one 13.x release to another.
>> Table builders sorcery failing out.
>>
>> Issues when there are multiple transports on varying networks were udp is
>> not routed correctly through the asterisk servers. No matter the settings.
>>
>> Connectivity issues with varying success by carrier.
>>
>> Unexplained audio quality issues that don't occur on the same spec
>> running chan_sip
>>
>> We want to move to pjsip but the functionality and stability have only
>> proven out for limited applications.
>>
>>
>> Bryant
>>
>> --
>> *From*: "Daniel Journo" 
>> *Sent*: Sunday, October 8, 2017 3:12 PM
>> *To*: "Asterisk Developers Mailing List" 
>> *Subject*: Re: [asterisk-dev] One sip stack to rule them all
>>
>>
>> > What is _also_ needed, however, is more use of PJSIP and reports of
>> specific problems, and specific deficits of PJSIP so that the fear can be
>> eased before, at some point many years from now, chan_sip just doesn't work
>> any more.
>>
>> There are a number of specific issues on issue tracker which still need
>> addressing before more people will take it on properly. Some issues
>> probably require a semi-major rethink and probably won’t be dealt with for
>> months.
>> Making chan_sip depreciated would leave Asterisk with no production grade
>> sip stack that is officially being maintained.
>> --
>> _
>> -- 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
>
> --
> Seán C McCord
> CyCore Systems, Inc
> +1 888 240 0308 <(888)%20240-0308>
> PGP/GPG: http://cycoresys.com/scm.asc
>
> --
> _
> -- 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
>



-- 
James
-- 

[asterisk-dev] One sip stack to rule them all....

[James Finstrom]

One does not simply depricate a sip stack.

Ok so at devcon there was a discussion of depricating chan_sip. This may
sound a lot worse than it actually is. Chan_sip has been essentially
untouched in 4ish years. It does not receive bug fixes. It is just sort of
a barge floating in the ocean.

So one of the things that is needed to finally put Chan sip to bed is
feature parody.  Someone brought up CCSS.

What features do you feel you would lose going from chan_sip to pjsip.

Are there any bugs in pjsip that keep you from migrating?
-- 
_
-- 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] Viva Chan_Sip, may it rest in peace

[James Finstrom]

I don't have a preference in this fight. I am like Switzerland.  Full
disclosure for those unaware I am one of the FreePBX developers. We support
both stacks individually and together.  The project made a decision (good,
bad or otherwise) to push PJSIP as the default stack. This only affects new
installs and we, by no means force any migration. I think many seasoned
users go in and flip to chan_sip on new installs. New users run with it and
are adopting PJSIP because they haven't used anything else. The learning
curve for a new user would be the same in either stack.

My origin story is Zaptel I lived through the great Zaptel/Dahdi
migration (and all I got was this stupid t-shirt). There was some rough
patches there but we survived.  As mentioned it is not going to be a here
today gone tomorrow kind of thing.  I think everyone gets the business
implementation.  Many in the community and open source world have worked
overtime to legitimize "free software" and no one wants to make any wild
west moves to reverse that.  There are things in Asterisk deprecated back
in 1.6 still present. Deprecation is a request to move on. There has been a
few replies where people took the plunge and migrated. Note they didn't do
it in a binary manner. They migrated over time and built a platform that
fits their business. The effort ranges from trivial to "nope".  The trivial
people have likely moved. The sell has to be to those towards the other end
of the spectrum.  You have to convince the "nope people" that it is worth
the move.

I think there was a mention of over 50% adoption as a desired metric to
depreciate.  I can see this as a viable goal. With 50% adoption, that
should cover a majority of edge cases and bring most bugs to the surface.

Maybe a good task for any working group would be to go to voip-info and
supply PJSIP information wherever there is chan_sip information.  When
anyone old or new googles, like it or not the top results are usually
voipinfo. Also it may be useful on those pages to link to the official wiki
wherever appropriate. This should help googlers get back to current
information.

On Wed, Oct 5, 2016 at 4:29 AM, Eric Klein <eric.kl...@greenfieldtech.net>
wrote:

> James,
>
> You missed a few points:
> 1. There needs to be a move in the training materials, and DCAP exam away
> from (the soon to be depriciated) version 11 and move into versions that
> support PJSip - familiarity will breed use.
>
> 2. One suggestion to do this was to declare that Chan_Sip would be
> depreciated in version 15 or 16. This would not mean removing it from the
> code, but that going forward (for 1 or 2 more releases) it would only get
> security fixes and no more development. This would have the benefit
> of  everyone would have 3-5 years to learn and transition to PJSip without
> breaking anything that is currently working,  while releasing development
> staff to improving the interface and problems with PJSip and other parts of
> Asterisk.
>
> Eric Klein
> VP of Customer Experience
> GreenfieldTech
> Mobile +972-54-666-0933
> Email eric.kl...@greenfieldtech.net
> Skype: EricLKlein
> Web: http://www.greenfieldtech.net/
>
>
>
>> Message: 5
>> Date: Tue, 4 Oct 2016 17:46:52 -0700
>> From: James Finstrom <jfinst...@gmail.com>
>> To: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com>
>> Subject: [asterisk-dev] Viva Chan_Sip, may it rest in peace
>> Message-ID:
>> 

[asterisk-dev] Viva Chan_Sip, may it rest in peace

[James Finstrom]

So the discussion of deprecating chan_sip came up at the devcon this year
and it caused a bit of a stir. The end result was the need for broader
discussion with a wider audience.  So let's discuss.

Currently, Asterisk is running dual sip stacks. The argument is that to
deprecate PJSIP there must be broader adoption. There is currently nothing
motivating adoption but much slowing it.

What are some of the hurdles to adoption?
1. Apathy.  If it ain't broke don't fix it. Many would argue chan_sip is
broke but it is the "devil you know". A decade of documentation and a broad
user base allows people to be pretty forgiving of flaws. Almost any issue
has some sort of work around or generally accepted idea of I guess we can
live with it.

2. One Ring to rule them all!!  PJSIP requires up to 6 sections of
configuration. Once you dig in, this method makes sense. But at a glance,
you have just multiplied the workload to  6 times that of chan_sip's single
blob config. Though it is not really 600% more effort it may be enough to
scare some away

3. Mo Adoption, Mo problems!
The only way to clean up all the edge cases and weird bugs is to hit them
in the first place.  Dogfooding only gets you so far.  You can make
anything working clean in a single environment and single use case. But
what happens when people start flinging wrenches. Things break. 100
wrenches may break 10 things. 1000 wrenches may break 100 things.  In the
ladder case, you have 100 people saying pjsip sucks, and pjsip is crap. As
with all things the 900 assume all is good and move on with their lives
telling no one of their glory. So you have 10% of the voices running
unopposed. You fix the 100 issues and that is great but those 100 people
have gone back to the comfort of chan_sip and are stuck at point 1.

Escaping the cycle.

So how do we dredge through this mess and get high adoption?

You have to make #1 not an option.  This means potentially breaking the
universe. This is why I think there is a tendency to be gunshy. No one
wants to be the guy who broke the universe.  But breaking the universe gets
us to #3 without falling back into #1.   Once The universe breaks and we
are in #3 many of the edges will be found and fixed. Suddenly PJSIP becomes
usable in most, if not all situations. The issues in #2 will automatically
resolve as there is more information and it becomes the "accepted way" of
doing things.  The old dogs will have to refactor how they do configuration
but I am confident once they do a few they will figure out the bark is
bigger than the bite.

tl;dr to get adoption you have to force it.  There will be blood, but
nothing that can't be cleaned up with a little bleach and some elbow grease

-- 
James
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [asterisk-users] Migrating asterisk 11 to 13: some callers get no ringback tone any more

[James Finstrom]

Update to the latest core/ringgroups version (may be in edge still)  This
will correct the ringback issues.  This ultimately comes down to how your
provider handles these messages. Some (not all) providers freak out if they
get "progress" and "ringing".  Recently we added progress in ringgroups. If
you have ringing on your inbound route you are now sending both and this
makes some providers cry.  So the latest iteration does NOT send progress
if you set ringing to be true. Ultimately this is a provider problem as a
direct result of configuration in FreePBX and not an Asterisk issue.

On Tue, May 3, 2016 at 9:47 AM, Joshua Colp  wrote:

> Michael Maier wrote:
>
> 
>
> Ok - but this doesn't seem to answer my main question:
>>
>> Why must
>>
>> progressinband=never
>>
>> be applied especially if asterisk uses it by default? The big difference
>> between w/ and w/o it is:
>>
>
> The default in 13 is "no" which still allows early media through. That
> option has a complicated past.
>
>
>> w/o the option progrssinband=never just the sip-package
>> 183 Session Progress
>> is sent.
>>
>
> Yes, because it's doing inband progress using a media stream.
>
>
>> w/ the option set, the additional sip-packages
>> 100 Trying
>> 180 Ringing
>> 180 Ringing
>> are sent.
>>
>> If progrssinband=never is the default, the Ringing package should be
>> sent always, shouldn't it?
>>
>
> It's not the default.
>
>
>> If I remove the option progrssinband=never via FreePBX, I can't find any
>> other value provided to progrssinband in /etc/asterisk/*.
>>
>>
>> Why does it work always correctly w/ the second trunk, which is
>> connected directly to the extension?
>>
>
> FreePBX may not use inband progress for that scenario, causing it to send
> out of band ringing instead.
>
>
>> Is it possible to switch off the standard behavior of asterisk /
>> progrssinband for ring groups only by setting some other options?
>>
>
> Asterisk does not have the concept of ring groups, this is a FreePBX
> construc. Asterisk itself does allow the option to be set on an individual
> basis for the entries in sip.conf.
>
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
James
-- 
_
-- 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