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

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

2017-10-09 Thread Bruce Ferrell 

On 10/08/2017 04:47 PM, James Finstrom wrote:

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.



EASY!!! No one uses it, no tickets... no bugs!  It wins!

Wait... WHAT?!

I most definitely do NOT want what you're smoking!




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.


...And of course none of the features or bugs fixes

This is the same stuff Novell smoked.



On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord <ule...@gmail.com 
<mailto:ule...@gmail.com>> 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 <brya...@zktech.com 
<mailto:brya...@zktech.com>> 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" <d...@keshercommunications.com 
<mailto:d...@keshercommunications.com>>
*Sent*: Sunday, October 8, 2017 3:12 PM
*To*: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com 
<mailto:asterisk-dev@lists.digium.com>>
*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.

--

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

2017-10-09 Thread Bruce Ferrell 

On 10/09/2017 07:11 AM, Daniel Journo wrote:

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



You bring up an issue that was discussed at Devcon. We, as a community, need to 
step up and provide this kind of documentation, best practices, and examples so 
people can use Asterisk (and in this case PJSIP) properly and with confidence.
If we want people to use it, we need to show them how to do it in a supported 
and stable way.


Your point about every provider only documenting chan_sip is an interesting one. Most advanced users would be able to learn how to configure PJSIP using the wiki. Beginners asking 


Actually the wiki SUCKS as do most wiki's... They presume too much and leave too much 
unsaid as "obvious".
My rule of thumb when I write documents is that if I think it's obvious, it 
probably isn't and needs to be
explicitly called out.  The Asterisk book is/was good at that.

I've been attempting to use the wiki for pjsip to get a recent Digium blog 
entry working (the one of
video conferencing).  It's a nice step by step... and it doesn't work for me.  
And precisely ZERO on
how to figure out why.

I WAS able to get hard phones to register, but I have to say, it's convoluted 
and I can't see a good reason
for making it that way.  Maybe it's "obvious".  chan_sip has a clean 
configuration for endpoints.


questions on the #asterisk irc channel are often told to go to the Asterisk book to learn how to configure Asterisk. As the latest Asterisk book was written for v11, I think that 
would be one of the major causes of the continued usage of chan_sip rather than the providers.


I'm surprised to hear that Digium uses PJSIP commercially because I've always struggled with various bugs and issues. I can't reload PJSIP without causing any downtime for example. 
PJSIP is getting there, but it has a way to go before it can be trusted.

I don't consider my use case of 100 endpoints per Asterisk box to be 
particularly unusual, but I do have my fair share of bugs with PJSIP. So do 
others I speak to on IRC.


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


Ya know, I've seen this trumpeted quite a bit... A dead end is something going 
nowhere and doesn't work.

Like it or NOT... It seems that for a significant number of applications 
chan_sip DOES work and does so better
than pjsip does.

As I was taught many, many, years ago, good engineering is about cost effective 
solutions, not "whiz bang"
technology.  If the cost in effort/downtime/etc is more for the "cool/forward 
looking" technology is higher
and presents barriers to adoption, that test fails.



I'm not sure what the purpose of this thread is then. It seems like this is not actually a question of whether it should be depreciated. Just a statement that it is. If it is, 
PJSIP needs some serious work otherwise it opens the window for commercial solutions to take some market share.


If chan_sip is a dead end and it is made officially depreciated, it would have 
the following effect:-

- It would 'hopefully' increase uptake and therefore bug reports. As long as there are people able to work through them, that’s fine. Otherwise, it opens the window for commercial 
solutions to take some market share.

- There would currently be no reliable sip stack for some use cases whereas 
chan_sip worked fine as some support is still available.




--
_
-- 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-09 Thread Daniel Journo 
>> Every provider that actually provides documentation only gives a chan_sip 
>> block
>> We don't understand how to configure it.
>> My customers need ccss.

> You bring up an issue that was discussed at Devcon. We, as a community, need 
> to step up and provide this kind of documentation, best practices, and 
> examples so people can use Asterisk (and in this case PJSIP) properly and 
> with confidence.
> If we want people to use it, we need to show them how to do it in a supported 
> and stable way.

Your point about every provider only documenting chan_sip is an interesting 
one. Most advanced users would be able to learn how to configure PJSIP using 
the wiki. Beginners asking questions on the #asterisk irc channel are often 
told to go to the Asterisk book to learn how to configure Asterisk. As the 
latest Asterisk book was written for v11, I think that would be one of the 
major causes of the continued usage of chan_sip rather than the providers.

I'm surprised to hear that Digium uses PJSIP commercially because I've always 
struggled with various bugs and issues. I can't reload PJSIP without causing 
any downtime for example. PJSIP is getting there, but it has a way to go before 
it can be trusted.
I don't consider my use case of 100 endpoints per Asterisk box to be 
particularly unusual, but I do have my fair share of bugs with PJSIP. So do 
others I speak to on IRC.

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

I'm not sure what the purpose of this thread is then. It seems like this is not 
actually a question of whether it should be depreciated. Just a statement that 
it is. If it is, PJSIP needs some serious work otherwise it opens the window 
for commercial solutions to take some market share.

If chan_sip is a dead end and it is made officially depreciated, it would have 
the following effect:-

- It would 'hopefully' increase uptake and therefore bug reports. As long as 
there are people able to work through them, that’s fine. Otherwise, it opens 
the window for commercial solutions to take some market share.
- There would currently be no reliable sip stack for some use cases whereas 
chan_sip worked fine as some support is still available.

-- 
_
-- 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-08 Thread Corey Farrell 
Correction on number of bugs, most PJSIP bugs are filed against resource 
modules.  If you select all of the "Resources/res_pj*" categories in 
addition to Channels/chan_pjsip it shows 121 open bugs.  People are 
reporting issues against the pjsip modules, most are not against the 
channel driver itself.



On 10/08/2017 07:47 PM, James Finstrom wrote:
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 <ule...@gmail.com 
<mailto:ule...@gmail.com>> 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
<brya...@zktech.com <mailto:brya...@zktech.com>> 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" <d...@keshercommunications.com
<mailto:d...@keshercommunications.com>>
*Sent*: Sunday, October 8, 2017 3:12 PM
*To*: "Asterisk Developers Mailing List"
<asterisk-dev@lists.digium.com
        <mailto:asterisk-dev@lists.digium.com>>
*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

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

2017-10-08 Thread 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 <ule...@gmail.com> 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 <brya...@zktech.com>
> 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" <d...@keshercommunications.com>
>> *Sent*: Sunday, October 8, 2017 3:12 PM
>> *To*: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
>> *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

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

2017-10-08 Thread Seán C . McCord 
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 <brya...@zktech.com> 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" <d...@keshercommunications.com>
> *Sent*: Sunday, October 8, 2017 3:12 PM
> *To*: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
> *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
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

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

2017-10-08 Thread Bryant Zimmerman 
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" <d...@keshercommunications.com>
Sent: Sunday, October 8, 2017 3:12 PM
To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
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

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

2017-10-08 Thread Daniel Journo 
> 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

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

2017-10-08 Thread Seán C . McCord 
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.


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

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

2017-10-08 Thread Troy Bowman 
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

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

2017-10-08 Thread Gunnar Hellström 
The Real-Time Text feature of Asterisk does not work with PJSIP. Or at 
least it is not documented how its redundant transport support is 
configured.
See: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4260034 
for how it once worked.


(There are bugs in the release 11 and 13 implementations of redundant 
transmission of real-time text with chan_sip as well, but it worked in 
earlier releases. )




Den 2017-10-08 kl. 16:55, skrev 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] One sip stack to rule them all....

2017-10-08 Thread Daniel Journo 
Having run pjsip for about a year now in production, I can say that the current 
implementation isn’t very reliable for scaling.
Due to the issues I describe below, I have to run multiple asterisk boxes with 
around 100 endpoints per box max.
Even at that leve, Asterisk on all boxes randomly stop responding to sip 
packets for up to 30 seconds.
It only happens 2 to 3 times a week which makes debugging or running core dumps 
hard to catch.
It does however still send out OPTIONS so it’s not totally dead during that 
time. The CLI still works as normal too.
I had a discussion with George about this, but we never found a solution due to 
the difficulty in capturing a core dump of the issue.

Another problem is Qualify. When doing PJSIP RELOAD, Asterisk stops dealing 
with inbound packets for about 60 seconds (while it qualifies everything 
again?).

Asterisk start up time is also greatly increased by qualify in PJSIP.

My short term plan is to switch back to Chansip until the issues are resolved. 
A discussion relating to depreciating chansip is a little worrying for me at 
this time.

Here are some issues related to this that I’ve been monitoring. I have tried to 
dive into the code, but it’s too steeper learning curve for me to work out how 
things are being done.

https://issues.asterisk.org/jira/browse/ASTERISK-27247
https://issues.asterisk.org/jira/browse/ASTERISK-26806
https://issues.asterisk.org/jira/browse/ASTERISK-26599
https://issues.asterisk.org/jira/browse/ASTERISK-26194


From: asterisk-dev-boun...@lists.digium.com 
[mailto:asterisk-dev-boun...@lists.digium.com] On Behalf Of James Finstrom
Sent: 08 October 2017 15:56
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] One sip stack to rule them all

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