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 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 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" mailto:d...@keshercommunications.com>>
*Sent*: Sunday, October 8, 2017 3:12 PM
*To*: "Asterisk Developers Mailing List" 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.

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

asterisk-dev mailing list
To UNSUBSCRIBE or

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

2017-10-09 Thread George Joseph 
On Mon, Oct 9, 2017 at 7:02 AM, Alexander Traud 
wrote:

> 
>
> 1) The button around "Download Latest - 15.0.0-rc1" is missing: Its A tag
> misses a class attribute with the value "btn btn-primary".
>

I'm looking at this part.


>
> 2) Test Release: Is it possible to remove the part about test releases
> when the final release is newer? Or link to that final release instead?
> Some users might scroll all the way down and install the "latest" test
> release although there is a newer "test" release already - the final
> release. They might overlook that the Final area is newer then the Test
> area. At least this happened to me several times already.
>
> These two questions belong together and are about the normal releases:
> 3A) What is the state of Asterisk 11, why is it still listed there?
> According the Wiki, Asterisk 11 receives only security fixes.
>
> 3B) What is the state of Asterisk 14, why was it removed there?
> According the Wiki, Asterisk 14 receives only security fixes.
>
>
>
> --
> _
> -- 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, Inc. | 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

[asterisk-dev] Asterisk Regular Segfault ASTERISK-27230 / ASTERISK-27256

2017-10-09 Thread Ross Beer 
Hi All,

It was great to attend AstriCon last week and to discuss the future of Asterisk.

While Asterisk 13 PJSIP is becoming more and more stable day by day, I am 
currently facing issues with the current GIT release which causes segfaults 
every day.

I have created these issues under ASTERISK-27230 and ASTERISK-27256, Rusty 
Newton kindly noted that these two issues appear to be caused by the same 
underlying issue.

I was wondering if anyone would be willing to resolve the issue?

I am willing to pay a bounty, please email me directly to discuss further.

Kind regards,

Ross


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

[asterisk-dev] RTCP feedback for codec modules

2017-10-09 Thread marek cervenka 

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 ?

thanks

Marek


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

2017-10-09 Thread Eric Klein 
>
> Date: Sun, 8 Oct 2017 19:47:32 -0400
> From: James Finstrom 
> To: Asterisk Developers Mailing List 
> Subject: Re: [asterisk-dev] One sip stack to rule them all
>
> 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.
>


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

Eric Klein
VP Operations
Greenfield
Main US +1 805 410 1010
Main UK +44 203 746 6000
Main Il+972  73 255 7799
Mobile+972 54 666 0933

*Email *e...@greenfield.tech
Skype: EricLKlein
Web: www.greenfield.tech
 www.cloudonix.io
-- 
_
-- 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] Webpage Downloads

2017-10-09 Thread Alexander Traud 


1) The button around "Download Latest - 15.0.0-rc1" is missing: Its A tag 
misses a class attribute with the value "btn btn-primary".

2) Test Release: Is it possible to remove the part about test releases when the 
final release is newer? Or link to that final release instead? Some users might 
scroll all the way down and install the "latest" test release although there is 
a newer "test" release already - the final release. They might overlook that 
the Final area is newer then the Test area. At least this happened to me 
several times already.

These two questions belong together and are about the normal releases:
3A) What is the state of Asterisk 11, why is it still listed there?
According the Wiki, Asterisk 11 receives only security fixes.

3B) What is the state of Asterisk 14, why was it removed there?
According the Wiki, Asterisk 14 receives only security fixes.



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