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

2017-10-10 Thread Matt Fredrickson 
On Tue, Oct 10, 2017 at 6:21 PM, James Finstrom  wrote:

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

Thanks for clarifying, James.  This type of data is useful and helpful in
trying to continue to improve chan_pjsip.  As far as contingent actions
(such as marking chan_sip as deprecated) my opinion is that they are still
premature - as mentioned in my other reply.

Best wishes,
Matthew Fredrickson


>
> On Tue, Oct 10, 2017 at 2:40 PM, Matt Fredrickson 
> wrote:
>
>>
>>
>> On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord  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  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 
 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?
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com

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

2017-10-10 Thread 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 
wrote:

>
>
> On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord  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  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 
>>> 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?

 --
 _
 -- 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
>>
>> --
>> Seán C McCord
>> CyCore Systems, Inc
>> +1 888 240 0308

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

2017-10-10 Thread Matt Fredrickson 
On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord  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  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 
>> 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?
>>>
>>> --
>>> _
>>> -- 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
>
> --
> Seán C McCord
> CyCore Systems, Inc
> +1 888 240 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
>



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

Re: [asterisk-dev] RTCP feedback for codec modules

2017-10-10 Thread Matt Fredrickson 
On Mon, Oct 9, 2017 at 9:01 AM, marek cervenka  wrote:

> hi,
>
> i'm writing article about new features in Asterisk 15
>
> can you explain if
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26584
>
> is only part of the building block for function "change codec or codec
> params if network is worse/better"?
>
> and the missing part is rtp_engine + sip update method ?
>

Hey Marek,

This is support added to Asterisk to allow RTCP feedback messages to
influence codec behavior - so statistics contained within those messages
might include packet loss, jitter information, and other network level
details.  The codecs then could presumably act on that behavior (increasing
FEC level, reducing bitrate, etc).  This is separate from any SIP protocol
level messaging.

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

[asterisk-dev] Adding a new module to Asterisk

2017-10-10 Thread Nir Simionovich 
Hi All,

  I'm in the process of adding a new module to Asterisk, in this case, a
new CDR backend.
The new backend relies on a library that I need to introduce to the linker,
however, I've tried
to figure out how the autotools work in there - and had failed miserably.

  I would appreciate if someone can shed a little light on the process - if
possible.

Regards,
  Nir S
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] Asterisk 14 Security Fix Only Mode

2017-10-10 Thread Matt Fredrickson 
Hey all,

For those who may not be aware Asterisk 14 transitioned from bug fix mode
to security-fix-only mode a few weeks ago (Sept 26th). For those of you
that are still on this release, it's a good time to consider building an
upgrade plan for moving to 15.x.x.  I sincerely apologize for the late
notification.  Somehow, this was overlooked in the push to get 15.0.0
released.

You can read more about this process and the relevant dates on the wiki at
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

Best wishes, and sorry again about the confusion on this.

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

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

2017-10-10 Thread Sean Bright 

On 10/8/2017 10:55 AM, James Finstrom wrote:
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?


FWIW, I created a tracking bug for chan_pjsip feature parity with chan_sip:

    https://issues.asterisk.org/jira/browse/ASTERISK-27309

If anyone feels like taking a crack at this related bugs, go for it.

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