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

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] Viva Chan_Sip, may it rest in peace

2016-10-04 Thread Bruce Ferrell 
On 10/04/2016 05:46 PM, James Finstrom wrote:
> 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 
>

Forcing adoption IS one simplistic approach to getting wide adoption. 

Were Asterisk a toy, not widely in use, that kind of simple approach might make 
sense.  Asterisk is however NOT a toy.  Asterisk IS in wide use for peoples 
livelihood.  "A little
bleach" might also read "possible loss of business for others"... And that 
cavalier thought process towards those failures might well benefit from a much 
closer look.

Another method is showing a clear and persuasive benefit. Might it be possible 
that such a benefit isn't actually there, beyond a certain "academic" mindset?

Impatience NEVER benefits anyone.



-- 
_
-- 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 goes Spatial Conferencing: the STEAK project

2016-07-19 Thread Bruce Ferrell 
On 07/19/2016 01:56 PM, Sean Bright wrote:
> On 7/19/2016 4:00 PM, Bruce Ferrell wrote:
>> On 07/19/2016 10:59 AM, Sean Bright wrote:
>>> On 7/19/2016 10:35 AM, Matt Fredrickson wrote:
>>>> Response below.
>>>>
>>>> On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse
>>>> <dennis.g...@alumni.tu-berlin.de> wrote:
>>>>> Technical Details (at the moment the modifications are based upon 13.6.0):
>>>>> * Enabled OPUS (with incoming stereo and outgoing stereo [interleaved])
>>>>> * Extended softmix for stereo support (downmixing)
>>>>> * Extended the default confbridge (basically added a convolution engine)
>>> If Opus is a required part of the implementation - and from reading the 
>>> description of the work being done it appears to be - wouldn't that make 
>>> this ineligible for inclusion?
>>>
>>> Kind Regards,
>>> Sean
>>>
>> Just for clarification, why?  speex is included.  similar if not the same 
>> license?
>
> The last update I've seen on Digium's position in regards to the inclusion of 
> Opus support in the core is here:
>
> http://lists.digium.com/pipermail/asterisk-dev/2013-May/060419.html
>
> I don't believe they have publicly changed their stance on the topic since 
> then, but I'd be happy to be proven wrong.
>
> Kind regards,
> Sean
>
>
>
great answer Sean.  Thanks


-- 
_
-- 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 goes Spatial Conferencing: the STEAK project

2016-07-19 Thread Bruce Ferrell 
On 07/19/2016 10:59 AM, Sean Bright wrote:
> On 7/19/2016 10:35 AM, Matt Fredrickson wrote:
>> Response below.
>>
>> On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse
>>  wrote:
>>> Technical Details (at the moment the modifications are based upon 13.6.0):
>>> * Enabled OPUS (with incoming stereo and outgoing stereo [interleaved])
>>> * Extended softmix for stereo support (downmixing)
>>> * Extended the default confbridge (basically added a convolution engine)
>
> If Opus is a required part of the implementation - and from reading the 
> description of the work being done it appears to be - wouldn't that make this 
> ineligible for inclusion?
>
> Kind Regards,
> Sean
>
Just for clarification, why?  speex is included.  similar if not the same 
license?


-- 
_
-- 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] Journald support for Asterisk

2015-05-10 Thread Bruce Ferrell 
On 05/10/2015 02:22 PM, Ludovic Gasc wrote:
 2015-05-10 20:46 GMT+02:00 Bruce Ferrell bferr...@baywinds.org 
 mailto:bferr...@baywinds.org:

 On 05/09/2015 01:53 PM, Ludovic Gasc wrote:
  2015-05-09 16:15 GMT+02:00 Bruce Ferrell bferr...@baywinds.org 
 mailto:bferr...@baywinds.org mailto:bferr...@baywinds.org 
 mailto:bferr...@baywinds.org:
 
  On 05/09/2015 01:17 AM, Ludovic Gasc wrote:
   Hi,
  
   Systemd and Journald is now by default on Debian Jessie and 
 Ubuntu 15.04, as on RHEL/CentOS.
   Journald supports syslog format, nevertheless, at least for us, 
 the structured log system provided with journald helps us to debug the 
 production.
  
   The idea behind that is to attach metadata with a log line to 
 facilitate the search with journalctl, you can write queries to find the 
 errors.
  
   For example, with Apache: 
 http://httpd.apache.org/docs/trunk/mod/mod_journald.html
  
   For our Python daemons, for each log line, we store account_id, 
 request_id, endpoint and method used to be easy to retrieve quickly 
 interesting logs.
  
   Moreover, not yet used for us, but you can generate statistics 
 about your source code real usage based
   on: 
 http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=
  
   For Asterisk, for example with dialplan logging, you should 
 attach the context, the extension and the channel.
  
   You can simulate this journald feature with a specific format 
 message for your logs, nevertheless, journalctl is more user-friendly to 
 retrieve pertinent logs compare
 to the
   classical grep usage.
   ave no idea if i
   I'm permitted to raise the question about an eventual journald 
 support in Asterisk because I don't find anything about that in issues 
 tracker nor mailing list.
  
   Moreover, I understand that even if you add the journald support, 
 it's certainly necessary to change logging everywhere in Asterisk, however, I 
 should help to do that.
  
   Regards
   --
   Ludovic Gasc (GMLudo)
   http://www.gmludo.eu/
  
  
  systemd and journald SUCK to high heaven.
 
 
  I've no problems to believe you, nevertheless, could you be more 
 precise ?
  What are the facts that you arrive to this conclusion ?
 
 
I have no idea if the issues I've had with them (OpenSUSE) are 
 distro related or inherent.
 
 
  It's issues on your production with several servers ? Or on your laptop 
 ?
  Could give us links with unresolved bugs you have ?
  For now, to my experience, with 6 VMs on Debian Jessie on production 
 with small clients and Asterisk 13, I've no issues with systemd nor journald.
 
 
  I have seen that the implementation of apache with a static 
 systemd/journald module will no longer correctly serve content.
 
 
  Could you give me a link about that ?
 I would suggest you try it for yourself.  Procedure to reproduce:

 Perform fresh install of OpenSUSE 13.2
 assure apache/php/MySQL support are installed
 install wordpress from wordpress.org http://wordpress.org
 Observe CSS is NOT correctly served.

 I did this several times to assure my findings.

 I rebuilt the opensuse rpms from the source rpms to omit systemd/journald 
 from the apache build.  Correct operation was now observed


 Interesting, it seems like a regression bug.
 The question now is the patchs from opensuse has broken this module, or the 
 bug is in Apache itself.
 The bug seems to be too obvious to be present in Apache source code, but who 
 knows ?
  

 The response to the bug report was Use Nginex


 To be really honest with you, I've thought that when you explain your 
 problem, I've dropped Apache on our production a long time ago for efficiency 
 issues.
  


  Please do NOT do this
 

  Why ? If it works for me, what's the problem for you ?

   Systemd integration has been insidious.  Should you wish to discuss 
 further, please off this list.

 
 
It also breaks fail2ban site security.
 
 
  I don't understand the issue here, I see at least two solutions:
  1. You can continue to use rsyslog even if you have journald, BTW, it's 
 the default setup of Debian Jessie, where journald forwards everything to 
 rsyslog to avoid to perturb
  sysadmins with log files.
  2. Apparently, fail2ban supports journald: 
 https://github.com/fail2ban/fail2ban/pull/82

 1.) I don't know of any asterisk systems that use any form of system 
 logging.  It can, and the fact that you keep bringing syslog logging into 
 this indicates a lack of
 understanding of asterisk usage on your part.
 2.) Not released code and still under

Re: [asterisk-dev] Journald support for Asterisk

2015-05-10 Thread Bruce Ferrell 
On 05/09/2015 01:53 PM, Ludovic Gasc wrote:
 2015-05-09 16:15 GMT+02:00 Bruce Ferrell bferr...@baywinds.org 
 mailto:bferr...@baywinds.org:

 On 05/09/2015 01:17 AM, Ludovic Gasc wrote:
  Hi,
 
  Systemd and Journald is now by default on Debian Jessie and Ubuntu 
 15.04, as on RHEL/CentOS.
  Journald supports syslog format, nevertheless, at least for us, the 
 structured log system provided with journald helps us to debug the production.
 
  The idea behind that is to attach metadata with a log line to 
 facilitate the search with journalctl, you can write queries to find the 
 errors.
 
  For example, with Apache: 
 http://httpd.apache.org/docs/trunk/mod/mod_journald.html
 
  For our Python daemons, for each log line, we store account_id, 
 request_id, endpoint and method used to be easy to retrieve quickly 
 interesting logs.
 
  Moreover, not yet used for us, but you can generate statistics about 
 your source code real usage based
  on: 
 http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=
 
  For Asterisk, for example with dialplan logging, you should attach the 
 context, the extension and the channel.
 
  You can simulate this journald feature with a specific format message 
 for your logs, nevertheless, journalctl is more user-friendly to retrieve 
 pertinent logs compare to the
  classical grep usage.
  ave no idea if i
  I'm permitted to raise the question about an eventual journald support 
 in Asterisk because I don't find anything about that in issues tracker nor 
 mailing list.
 
  Moreover, I understand that even if you add the journald support, it's 
 certainly necessary to change logging everywhere in Asterisk, however, I 
 should help to do that.
 
  Regards
  --
  Ludovic Gasc (GMLudo)
  http://www.gmludo.eu/
 
 
 systemd and journald SUCK to high heaven.


 I've no problems to believe you, nevertheless, could you be more precise ?
 What are the facts that you arrive to this conclusion ?
  

   I have no idea if the issues I've had with them (OpenSUSE) are distro 
 related or inherent.


 It's issues on your production with several servers ? Or on your laptop ?
 Could give us links with unresolved bugs you have ?
 For now, to my experience, with 6 VMs on Debian Jessie on production with 
 small clients and Asterisk 13, I've no issues with systemd nor journald.
  

 I have seen that the implementation of apache with a static 
 systemd/journald module will no longer correctly serve content.


 Could you give me a link about that ?
I would suggest you try it for yourself.  Procedure to reproduce:

Perform fresh install of OpenSUSE 13.2
assure apache/php/MySQL support are installed
install wordpress from wordpress.org
Observe CSS is NOT correctly served.

I did this several times to assure my findings.

I rebuilt the opensuse rpms from the source rpms to omit systemd/journald from 
the apache build.  Correct operation was now observed

The response to the bug report was Use Nginex

 Please do NOT do this


 Why ? If it works for me, what's the problem for you ?

  Systemd integration has been insidious.  Should you wish to discuss further, 
please off this list.

  

   It also breaks fail2ban site security.  


 I don't understand the issue here, I see at least two solutions:
 1. You can continue to use rsyslog even if you have journald, BTW, it's the 
 default setup of Debian Jessie, where journald forwards everything to rsyslog 
 to avoid to perturb
 sysadmins with log files.
 2. Apparently, fail2ban supports journald: 
 https://github.com/fail2ban/fail2ban/pull/82

1.) I don't know of any asterisk systems that use any form of system logging.  
It can, and the fact that you keep bringing syslog logging into this indicates 
a lack of
understanding of asterisk usage on your part.
2.) Not released code and still under test.  This is disingenuous, at best.
3.) Just because everyone else is jumping off of bridges isn't a good enough 
reason to do it.  It's NOT broken and this is NOT an improvement.

  

 Asterisk works well now.  It integrates easily.


 For this point, I'm agree with you, it's very important to continue to be 
 integrated easily, I use that a lot.
  




 --
 _
 -- 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] Journald support for Asterisk

2015-05-09 Thread Bruce Ferrell 
On 05/09/2015 01:17 AM, Ludovic Gasc wrote:
 Hi,

 Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as 
 on RHEL/CentOS.
 Journald supports syslog format, nevertheless, at least for us, the 
 structured log system provided with journald helps us to debug the production.

 The idea behind that is to attach metadata with a log line to facilitate the 
 search with journalctl, you can write queries to find the errors.

 For example, with Apache: 
 http://httpd.apache.org/docs/trunk/mod/mod_journald.html

 For our Python daemons, for each log line, we store account_id, request_id, 
 endpoint and method used to be easy to retrieve quickly interesting logs.

 Moreover, not yet used for us, but you can generate statistics about your 
 source code real usage based
 on: 
 http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=

 For Asterisk, for example with dialplan logging, you should attach the 
 context, the extension and the channel.

 You can simulate this journald feature with a specific format message for 
 your logs, nevertheless, journalctl is more user-friendly to retrieve 
 pertinent logs compare to the
 classical grep usage.
 ave no idea if i
 I'm permitted to raise the question about an eventual journald support in 
 Asterisk because I don't find anything about that in issues tracker nor 
 mailing list.

 Moreover, I understand that even if you add the journald support, it's 
 certainly necessary to change logging everywhere in Asterisk, however, I 
 should help to do that.

 Regards
 --
 Ludovic Gasc (GMLudo)
 http://www.gmludo.eu/


systemd and journald SUCK to high heaven.  I have no idea if the issues I've 
had with them (OpenSUSE) are distro related or inherent.

I have seen that the implementation of apache with a static systemd/journald 
module will no longer correctly serve content.

Please do NOT do this.  It also breaks fail2ban site security.  Asterisk works 
well now.  It integrates easily.



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