[asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

Hi,


I agree that the conversation about HEP default settings doesn't warrant a lengthy discussion, however, the fact that the 'task processor' causes asterisk to stop processing packets is a serious issue. This is happening multiple times a day on several boxes.


I'm trying to identify what is causing over 1500 tasks to back-up in the 'subm:rtp_topic-000000de' scheduler. This is proving difficult as you only see counts and not actual waiting tasks.


>From the backtraces, I noticed STUN requests being scheduled, these have been disabled. The next backtrace shows tasks for HEP which I believe do get added to the rtp_topic as they are processing srtp data.


While typing the task processor has once again stopped packets being processed, even with the HEP modules disabled, I will upload the information now.


I would prefer not to bother the dev team, but Asterisk 13 has a lot of bugs which I'm sure we would all prefer to be resolved before the next release goes out.


Kind regards,


Ross


________________________________
From: asterisk-dev-bounces at lists.digium.com <asterisk-dev-bounces at lists.digium.com> on behalf of Matthew Jordan <mjordan at digium.com>
Sent: 28 June 2016 15:53
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP

On Tue, Jun 28, 2016 at 9:48 AM, Matt Fredrickson <creslin at digium.com> wrote:
> On Tue, Jun 28, 2016 at 8:54 AM, Ross Beer <ross.beer at outlook.com> wrote:
>> Hi,
>>
>>
>> I am still facing a task processor issue on subm:rtp_topic-000000de, looking
>> at the backtrace it looks to be related to HEP.
>
> Sounds like you're having some good luck sleuthing :-)
>
>> HEP is enabled by default and sends packets to 192.168.1.1:9061, shouldn't
>> this be disabled by default and not enabled in Asterisk 13? It makes no
>> sense to send packets if you can't be sure that a HEP server exists at the
>> default server location.
>
> I'd tend to agree with that logic.  I haven't done much work with HEP,
> but if HEP is enabled by default, we should probably change that
> behavior.  HEP should only be enabled if you "opt in" by setting it
> up.
>
> Just my .02.
>
> Anybody else have any thoughts?
>

I don't really care if they are enabled by default or not. For the
most part, most modules in Asterisk are 'opt-out', not 'opt-in', but
it doesn't really matter to me. Alternatively, instead of disabling
the modules from building, the HEP modules can be disabled by setting
the 'enabled' option to 'no' - which could also be changed in the
sample config file.

I will say that if you're installing the sample config files and not
updating them - particularly for things that you aren't interfacing to
- then you're setting up your systems poorly. The sample config files
have long been used for documentation purposes - running 'make
samples' and walking away is going to give you a bad time, and not
just because of the HEP modules.

Since these are just config file modifications we're talking about, a
patch should be provided and submitted to Gerrit. This is a patch that
anyone - including the issue reporter - could write. To echo what Josh
said, this doesn't really merit a lengthy discussion on the mailing
list, nor does it require 'poking' developers.

Matt

--
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://digium.com/>

Business Phone Systems | Unified Communications | Digium<http://digium.com/>
digium.com
Digium offers full Unified Communications solutions with on-premises and hosted business phone systems, IP phones, and Asterisk hardware.




--
_____________________________________________________________________
-- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160628/b978ac31/attachment-0001.html>