Re: [asterisk-dev] GitHub: One Month Update

[Ross Beer]

Hi George,

First time using GitHub here and it looks like I need to re-sign the 
contributor license agreement. This is approved in Jira, how do we go about 
signing this in GitHub?

I'm sure others will have the same issue so thought it was pertinent to reply 
to this thread.

Regards,

Ross

From: asterisk-dev  on behalf of George 
Joseph 
Sent: 06 June 2023 12:22
To: Asterisk Developers Mailing List 
Subject: [asterisk-dev] GitHub: One Month Update

It's been a month now since we transitioned over to GitHub so I thought I'd 
give you guys an update but I'd also like to hear your thoughts on the 
transition and new process.

First...A Policy Change...
When we started, we said "one commit per pull request" to keep things as close 
to Gerrit as possible.  After some discussions and additional thinking however, 
it looks like we can allow multiple commits per pull request under the 
following condition:  The commits MUST be for a single functional change and 
must be able to stand on their own, in sequence from first to last commit.  For 
example, a commit that adds some core capability to JSON processing, then a 
second commit that updates an app or function to use it.  In this case, the 
first commit can stand on its own and the second depends on it so having both 
commits in the same PR would make sense.  Another good example might be a large 
scale change required by a new gcc version where the files changed in the apps 
directory might be in one commit and the files changed in funcs in another.

What's not acceptable are commits added to a PR that fix issues in other 
commits in the same PR.  This would result in a commit that we know to be 
broken making it into the git history.  An unknowing person might checkout that 
commit and not realize that the following commit is also required.  It would 
also make git-bisects troublesome.  Also not acceptable are merge or other 
housekeeping commits.  I've seen a few merge commits just in the past week.

Second...A Reminder...
Please keep an eye on your commit messages.  Don't put anything extraneous 
after the Fixes/Resolves, UserNote or UpgradeNote trailers.  Keep all legacy 
ASTERISK- mentions, Gerrit links, Reported-by and other stuff  above all the 
new trailers.  It would also help me a great deal if you could update the pull 
request description to match the commit message if you happen to fix any of 
these issues after the PR is created.  We don't parse the PR description at all 
but if I see issues in it I'll have to keep drilling down to the commits to see 
if you've fixed them there.

Third...Merges...
We had some issues yesterday where two PRs were merged that both updated 
Alembic scripts.  Each PR on its own passed all the tests and merge conflict 
detection but when actually merged broke the previous/next links between 
Alembic scripts.  This happened because we do most of the merge checks when PRs 
are submitted and none just before they're actually merged.  GitHub isn't 
really set up to do pre-merge checks like Gerrit did and assumes that if a PR 
could be merged without git conflict, it must be good.  We're looking at ways 
to solve this issue which may include a new "Merge Queue" feature GitHub has in 
beta testing.  It might take a few weeks to iron the kinks out though.  In the 
mean time, we might automatically add an "ALEMBIC CHANGE!" flag to any PR that 
touches the Alembic scripts just to make us aware that there might be a 
conflict.

Finally...Your Thoughts?
How's everything working from your perspective?  Anything we should change?

--
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and 
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

Re: [asterisk-dev] Idle Timers and Keep-Alives

[Ross Beer]

Could the operating system manage this also, for example with the following:

sysctl.conf

net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_syn_retries = 5

# Keep TCP connections alive
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 20

>From a chan_pjsip point of view, it would receive notification that the 
>underlying connection has closed.

From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Alexander Traud 

Sent: 05 January 2018 15:44
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Idle Timers and Keep-Alives

> Do we even WANT an idle timer?

I posted my concerns already in : I have a 
device which crashes when it receives such a keepalive. I could live with a 
timer when Asterisk is not the registrar but registered somewhere else. But I 
do not _need_ that either.



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

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

[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

[asterisk-dev] ASTERISK-27147 - prune_on_boot - ps_contacts - Sanity Check

[Ross Beer]

Hi Richard,


Can I run something past you regarding the 'prue_on_boot' logic, please?


If multiple asterisk servers are using the ps_contacts database table, does the 
removal logic check the 'reg_server' before removing the contact on boot?


I am concerned that valid contacts on other asterisk instances may be removed 
incorrectly.


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

[asterisk-dev] Stasis-core-control Task Processor

[Ross Beer]

Hi,


Is there currently a variable to adjust the low and high water on the 
Stasis-core-control task processor?


Also, am I correct in thinking that adjusting the 'max_size' thread pool in the 
'stasis.conf' will help eliminate the following log message:

The 'stasis-core-control' task processor queue reached 500 scheduled tasks 
again.


Thanks,


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

[asterisk-dev] BOUNTY - ASTERISK-26978 - rtp: Crash in ast_rtp_codecs_payload_code()

[Ross Beer]

HI All,


I would like to offer a bounty to fix 
ASTERISK-26978


Richard has kindly suggested a fix:


When the channels join the native rtp bridge the bridge technology needs to 
save a pointer with a ref to the rtp instance structure for both channels in 
the bridge. Then when a channel leaves the bridge the rtp instance's bridged 
with pointer can be guaranteed to be cleared. As it is now when a channel 
leaves the bridge there is no guarantee that the rtp instance's bridged with 
pointer gets cleared. Somehow both channel's rtp instance pointers are not 
being found so one of the rtp instance's bridged with pointer is not being 
cleared. As a result, the rtp code tries to natively bridge a frame to a 
destroyed rtp instance and deadlocks on a destroyed lock.


I am offering $1,000 for fixing the crash and deadlock.

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] ASTERISK-26978 - rtp: Crash in ast_rtp_codecs_payload_code()

[Ross Beer]

>>

>> Therefore I have added the following code to check for this:
>>
>>
>> if (format1->codec == NULL || format2->codec == NULL) {
>> return AST_FORMAT_CMP_NOT_EQUAL;
>> }
>>
>> The question is, should 'codec' be NULL if 'format1' and 'format2' are
.> not NULL? Is adding the above check, the correct fix?

>A format can't be created and remain valid without a codec being present
>on it. A format itself is a codec + extra data about it. Identifying how
>it became NULL and why the format is no longer valid would uncover the
>real fix.

Does the format object need locking so that anything acting on it doesn't have 
the object pulled from under it?

My theory is that a channel is attempting to unallocated the 'format' object 
while it is trying to be compared. It, therefore, makes it through the NULL 
checks on 'format1' and 'format2' but is in the process of being freed.

There are quite a few backtraces on this and the linked issue. Would anyone be 
willing to take a look, my C skills are not that good?



-- 
_
-- 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-26978 - rtp: Crash in ast_rtp_codecs_payload_code()

[Ross Beer]

Hi,

I'm trying to fix a bug within the  ast_rtp_codecs_payload_code(), there are 
multiple crashes in the procedure.

The latest being:

#0 0x0051f883 in ast_format_cmp (format1=0x2bf73b8, format2=0x151) at 
format.c:247

This line contains:


if (format1->codec != format2->codec) {

return AST_FORMAT_CMP_NOT_EQUAL;

}

In the code before this line there are checks that 'format1' and 'format2' are 
not NULL however there are no checks to see if 'format1->codec' or 
'format2->codec' are not NULL.

Therefore I have added the following code to check for this:


if (format1->codec == NULL || format2->codec == NULL) {
return AST_FORMAT_CMP_NOT_EQUAL;
}

The question is, should 'codec' be NULL if 'format1' and 'format2' are not 
NULL? Is adding the above check, the correct fix?

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] Asterisk 13 and PJSIP 2.6 TLS Disconnections

[Ross Beer]

Hi Matthew,

I have the option 'keep_alive_interval' disabled at present as the function 
causes a deadlock. There is an issue open for this.

As I understand it, this function is Asterisk's own way of sending keep alive 
and not using the underlying OS to manage them. I was looking at a work around 
for the deadlock and thought that chan_sip uses the SO_KEEPALIVE option 
therefore this might be an easy solution.

Kind regards,

Ross



_
From: Matt Fredrickson mailto:cres...@digium.com>>
Sent: Thursday, March 2, 2017 20:38
Subject: Re: [asterisk-dev] Asterisk 13 and PJSIP 2.6 TLS Disconnections
To: Asterisk Developers Mailing List 
mailto:asterisk-dev@lists.digium.com>>


On Thu, Mar 2, 2017 at 7:02 AM, Ross Beer 
mailto:ross.b...@outlook.com>> wrote:
> Hi All,
>
>
> I'm trying to diagnose an issue with Asterisk 13 and PJSIP where TLS
> connections are being randomly closed by Asterisk. I'm currently testing the
> latest GIT version which uses Bundled PJSIP 2.6.
>
>
> Phones are set to register every 120 seconds, so connections shouldn't be
> timing out.
>
>
> I have a feeling this is related to the PJSIP keepalive options
> (https://trac.pjsip.org/repos/ticket/95):
>
>
> PJSIP_TCP/TLS_KEEP_ALIVE_INTERVAL
>
>
> I have tried setting these in the pjsip config, however, it doesn't appear
> to be working:
>
>
> 'netstat --timers -tn' shows that keepalives are not currently is use:
>
>
> tcp 0 0 :5060 :39395
> ESTABLISHED off (0.00/0/0)
> tcp 0 0 :22 :61282
> ESTABLISHED keepalive (195.31/0/0)
> tcp 0 0 :5061 :46216
> ESTABLISHED off (0.00/0/0)
> tcp 0 0 :5061 :47727
> ESTABLISHED off (0.00/0/0)
> tcp 0 0 :5061 :56087
> ESTABLISHED off (0.00/0/0)
> tcp 0 704 :22 :59566
> ESTABLISHED on (0.04/0/0)
> tcp 0 0 :5060 :39394
> ESTABLISHED off (0.00/0/0)
> tcp 0 0 :5060 :46139
> ESTABLISHED off (0.00/0/0)
>
>
>
> Would SO_KEEPALIVE need to be defined when setting up sockets in Asterisk?

Good question. I believe that application level keep alives are
generally relied upon in Asterisk's TCP/TLS code. Essentially, a
'\r\n\r\n' is sent over the TCP socket every so often to verify/ensure
connectivity.

Do you have the variable keep_alive_interval set in the [global]
section of your pjsip.conf? The value you set it to in seconds is the
interval at which it sends a keep alive message over the socket.

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


-- 
_
-- 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 13 and PJSIP 2.6 TLS Disconnections

[Ross Beer]

Hi All,


I'm trying to diagnose an issue with Asterisk 13 and PJSIP where TLS 
connections are being randomly closed by Asterisk. I'm currently testing the 
latest GIT version which uses Bundled PJSIP 2.6.


Phones are set to register every 120 seconds, so connections shouldn't be 
timing out.


I have a feeling this is related to the PJSIP keepalive options 
(https://trac.pjsip.org/repos/ticket/95):


PJSIP_TCP/TLS_KEEP_ALIVE_INTERVAL


I have tried setting these in the pjsip config, however, it doesn't appear to 
be working:


'netstat --timers -tn' shows that keepalives are not currently is use:


tcp0  0 :5060  :39395  
ESTABLISHED off (0.00/0/0)
tcp0  0 :22:61282  
ESTABLISHED keepalive (195.31/0/0)
tcp0  0 :5061  :46216  
ESTABLISHED off (0.00/0/0)
tcp0  0 :5061  :47727  
ESTABLISHED off (0.00/0/0)
tcp0  0 :5061  :56087  
ESTABLISHED off (0.00/0/0)
tcp0704 :22:59566  
ESTABLISHED on (0.04/0/0)
tcp0  0 :5060  :39394  
ESTABLISHED off (0.00/0/0)
tcp0  0 :5060  :46139  
ESTABLISHED off (0.00/0/0)



Would SO_KEEPALIVE need to be defined when setting up sockets in Asterisk?


Best 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] Deadlock GIT 13

[Ross Beer]

Hi Joshua,


I've created the issue here: 
ASTERISK-26797<https://issues.asterisk.org/jira/browse/ASTERISK-26797>

There is a sanitized backtrace uploaded, however, I have the full version if 
required.

Kind regards,

Ross

From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 16 February 2017 12:33
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Deadlock GIT 13

On Thu, Feb 16, 2017, at 08:20 AM, Ross Beer wrote:
> Unfortunately, the commit did not resolve the issue.
>
>
> This looks related to a lock inversion between channel hang up and the
> bridging code. There is an issue open for this
> ASTERISK-26445<https://issues.asterisk.org/jira/browse/ASTERISK-26445>
>
> While writing I have also had the following segfault:



>
> Should an issue be raised for this?

Asterisk shouldn't crash so any time there is one an issue should be
filed. The worst case is it is a duplicate and we link/close.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.digium.com
Digium makes business phone systems more affordable for your company. We offer 
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
-- 
_
-- 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] Deadlock GIT 13

[Ross Beer]

Unfortunately, the commit did not resolve the issue.


This looks related to a lock inversion between channel hang up and the bridging 
code. There is an issue open for this 
ASTERISK-26445<https://issues.asterisk.org/jira/browse/ASTERISK-26445>

While writing I have also had the following segfault:

[Current thread is 1 (Thread 0x7efeed3d4700 (LWP 27169))]
#0  0x7effa2cefa28 in raise () at /lib64/libc.so.6
#1  0x7effa2cf162a in abort () at /lib64/libc.so.6
#2  0x7effa2d32dea in  () at /lib64/libc.so.6
#3  0x7effa2d3b22a in _int_free () at /lib64/libc.so.6
#4  0x7effa2d3e78c in free () at /lib64/libc.so.6
#5  0x7effa5c73aa4 in default_block_free (factory=0x7eff13bee000 
, mem=0x7eff64c600d0, size=4096) at 
../src/pj/pool_policy_malloc.c:78
#6  0x7effa5c7b9ce in pj_pool_destroy_int (pool=0x7eff64c600d0) at 
../src/pj/pool.c:296
initial_size = 4096
#7  0x7effa5c7c1aa in cpool_release_pool (pf=0x7eff13bee000 , 
pool=0x7eff64c600d0) at ../src/pj/pool_caching.c:238
cp = 0x7eff13bee000 
pool_capacity = 12096
i = 32511
#8  0x7effa5c7b1ef in pj_pool_release (pool=0x7eff64c600d0) at 
../include/pj/pool_i.h:92
#9  0x7effa5be5f11 in pjsip_rx_data_free_cloned (rdata=0x7eff54259678) at 
../src/pjsip/sip_transport.c:730
#10 0x7eff139c8968 in distribute (data=0x7eff54259678) at 
res_pjsip/pjsip_distributor.c:779
param = {start_prio = 0, start_mod = 0x7eff13becc40 , 
idx_after_start = 1, silent = 0}
handled = 1
rdata = 0x7eff54259678
is_request = 
endpoint = 
#11 0x005ee88f in ast_taskprocessor_execute (tps=0x3f14250) at 
taskprocessor.c:965
local = {local_data = 0x7efeed3d4700, data = 0x5f6012 
}
t = 0x7eff55977e50
size = 66142800
__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#12 0x005f8444 in execute_tasks (data=0x3f14250) at threadpool.c:1322
tps = 0x3f14250
#13 0x005ee88f in ast_taskprocessor_execute (tps=0x27180a0) at 
taskprocessor.c:965
local = {local_data = 0x7efeed3d3c80, data = 0x2691c60}
t = 0x7eff5484bc60
size = 40443032
__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#14 0x005f66f9 in threadpool_execute (pool=0x2691cb0) at 
threadpool.c:351
__PRETTY_FUNCTION__ = "threadpool_execute"
#15 0x005f7db0 in worker_active (worker=0x7eff940097c0) at 
threadpool.c:1105
alive = 0
#16 0x005f7b68 in worker_start (arg=0x7eff940097c0) at threadpool.c:1024
worker = 0x7eff940097c0
saved_state = (DEAD | unknown: 32508)
__PRETTY_FUNCTION__ = "worker_start"
#17 0x0060402e in dummy_start (data=0x7eff94009260) at utils.c:1235
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-3586398186740987612, 139633997204095, 139633367009024, 507904, 507904, 
-3586398186715821788, 3731046902439921956}, __mask_was_saved = 0}}, __pad = 
{0x7efeed3d3df0, 0x0, 0x1, 0x7effa3c936e8 <__pthread_keys+1032>}}
__cancel_routine = 0x452814 
__cancel_arg = 0x7efeed3d4700
__not_first_call = 0
ret = 0x7effa30728d8
a = {start_routine = 0x5f7ae1 , data = 0x7eff940097c0, 
name = 0x7eff9410c6e0 "worker_start started at [ 1079] threadpool.c 
worker_thread_start()"}
#18 0x7effa3a8161a in start_thread () at /lib64/libpthread.so.0
#19 0x7effa2dbd5fd in clone () at /lib64/libc.so.6

Should an issue be raised for this?

Regards,

Ross

____
From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 08 February 2017 18:17
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Deadlock GIT 13


Hi Mark,


It does indeed, the patch has just been committed so I will check out the 
latest from git.


Thank you for your swift reply.


Kind regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Mark Michelson 

Sent: 08 February 2017 17:55
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Deadlock GIT 13

On 02/08/2017 11:26 AM, Ross Beer wrote:

Hi,


I'm getting a deadlock every so often with asterisk 13 GIT. There are a lot of 
low level locks:


#0  0x7f64ca6f052d in nanosleep () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f64cdcc9700 (LWP 20745))]
#0  0x7f64ca6f052d in nanosleep () at /lib64/libc.so.6
#1  0x7f64ca6f03c4 in sleep () at /lib64/libc.so.6
#2  0x004fc844 in db_sync_thread (data=0x0) at db.c:980
__PRETTY_FUNCTION__ = "db_sync_thread"
#3  0x0060401e in dummy_start (data=0x1e04440) at utils.c:1235
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-361566044794415684, 140733401961727, 140070926194432, 507904, 0, 
-361566044802804292, 302566635355346364}, __mask_was_saved = 0}}, __pad = 
{0x7f64cdcc8df0, 0x0, 0x0, 0x0}}
__cancel_routi

Re: [asterisk-dev] Deadlock GIT 13

[Ross Beer]

Hi Mark,


It does indeed, the patch has just been committed so I will check out the 
latest from git.


Thank you for your swift reply.


Kind regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Mark Michelson 

Sent: 08 February 2017 17:55
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Deadlock GIT 13

On 02/08/2017 11:26 AM, Ross Beer wrote:

Hi,


I'm getting a deadlock every so often with asterisk 13 GIT. There are a lot of 
low level locks:


#0  0x7f64ca6f052d in nanosleep () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f64cdcc9700 (LWP 20745))]
#0  0x7f64ca6f052d in nanosleep () at /lib64/libc.so.6
#1  0x7f64ca6f03c4 in sleep () at /lib64/libc.so.6
#2  0x004fc844 in db_sync_thread (data=0x0) at db.c:980
__PRETTY_FUNCTION__ = "db_sync_thread"
#3  0x0060401e in dummy_start (data=0x1e04440) at utils.c:1235
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-361566044794415684, 140733401961727, 140070926194432, 507904, 0, 
-361566044802804292, 302566635355346364}, __mask_was_saved = 0}}, __pad = 
{0x7f64cdcc8df0, 0x0, 0x0, 0x0}}
__cancel_routine = 0x452814 
__cancel_arg = 0x7f64cdcc9700
__not_first_call = 0
ret = 0x7f64cdcc8df0
a = {start_routine = 0x4fc765 , data = 0x0, name = 
0x1e055b0 "db_sync_thread   started at [ 1022] db.c astdb_init()"}
#4  0x7f64cb3ee61a in start_thread (arg=0x7f64cdcc9700) at 
pthread_create.c:334
__res = 
pd = 0x7f64cdcc9700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140070926194432, 
302565808931837372, 140733401961727, 140070926194432, 507904, 0, 
-361566044792318532, -361562863565433412}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#5  0x7f64ca72a5fd in clone () at /lib64/libc.so.6


Should an issue be created on Jira?


Regards,


Ross

Hi Ross,

This may be the same issue that George discovered earlier today while doing 
some testing. If you apply the code change on this review 
https://gerrit.asterisk.org/#/c/4902/ , do you still see the issue?
Gerrit Code Review<https://gerrit.asterisk.org/#/c/4902/>
gerrit.asterisk.org
gerrit.asterisk.org runs on a server provided by Digium, Inc. and uses 
bandwidth donated to the open source Asterisk community by API Digital 
Communications in ...




Mark Michelson
-- 
_
-- 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] Deadlock GIT 13

[Ross Beer]

Hi,


I'm getting a deadlock every so often with asterisk 13 GIT. There are a lot of 
low level locks:


#0  0x7f64ca6f052d in nanosleep () from /lib64/libc.so.6

[Current thread is 1 (Thread 0x7f64cdcc9700 (LWP 20745))]

#0  0x7f64ca6f052d in nanosleep () at /lib64/libc.so.6

#1  0x7f64ca6f03c4 in sleep () at /lib64/libc.so.6

#2  0x004fc844 in db_sync_thread (data=0x0) at db.c:980

__PRETTY_FUNCTION__ = "db_sync_thread"

#3  0x0060401e in dummy_start (data=0x1e04440) at utils.c:1235

__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-361566044794415684, 140733401961727, 140070926194432, 507904, 0, 
-361566044802804292, 302566635355346364}, __mask_was_saved = 0}}, __pad = 
{0x7f64cdcc8df0, 0x0, 0x0, 0x0}}

__cancel_routine = 0x452814 

__cancel_arg = 0x7f64cdcc9700

__not_first_call = 0

ret = 0x7f64cdcc8df0

a = {start_routine = 0x4fc765 , data = 0x0, name = 
0x1e055b0 "db_sync_thread   started at [ 1022] db.c astdb_init()"}

#4  0x7f64cb3ee61a in start_thread (arg=0x7f64cdcc9700) at 
pthread_create.c:334

__res = 

pd = 0x7f64cdcc9700

now = 

unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140070926194432, 
302565808931837372, 140733401961727, 140070926194432, 507904, 0, 
-361566044792318532, -361562863565433412}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

not_first_call = 

pagesize_m1 = 

sp = 

freesize = 

#5  0x7f64ca72a5fd in clone () at /lib64/libc.so.6


Should an issue be created on Jira?


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] ASTERISK-26699 - res_pjsip: Assertion when sending OPTIONS request to endpoint

[Ross Beer]

Excellent!


Thank you very much!


I will test and let you know if there are any further issues.


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 31 January 2017 17:56
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] ASTERISK-26699 - res_pjsip: Assertion when sending 
OPTIONS request to endpoint

On Tue, Jan 31, 2017, at 10:38 AM, Joshua Colp wrote:



>
> I believe the problem is in Asterisk, not PJSIP. We have our own logic
> around the handling of sending outbound requests and in this case it is
> not working as it should. It may be a result of a slight behavior change
> in PJSIP, but I still think the fix is on our side.

I was correct. I did a patch during lunch, it's now up for review.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & 
www.asterisk.org
[https://www.digium.com/sites/digium/themes/digium/logo.png]

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


Open Source Communications Software | Asterisk Official 
Site
www.asterisk.org
Asterisk is the world's most popular open source communications project that 
lets you create telephony apps for IP PBXs, VoIP Gateways and Conference 
Servers.




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

[asterisk-dev] ASTERISK-26699 - res_pjsip: Assertion when sending OPTIONS request to endpoint

[Ross Beer]

Hi Guys,


I've been trying to track down a problem with Asterisk which is causing a 
segfault. I have recently downloaded the latest 13 branch and a lot of the 
crashing issues have been resolved due to Richard Mudgett patches (Thank you, 
Richard!).


However, I am still suffering from the following issue:


ASTERISK-26699 - 
res_pjsip: Assertion when sending OPTIONS request to endpoint


I have just uploaded a backtrace that shows the issue is occurring when trying 
to cancel a timer for an OPTIONS request:


#0  0x7fdde8bd6485 in cancel (ht=0x2b010c0, entry=0x21, flags=7) at 
../src/pj/timer.c:331

331   if (entry->_timer_id < 0 || (pj_size_t)entry->_timer_id > 
ht->max_size) {

[Current thread is 1 (Thread 0x7fdce8214700 (LWP 99357))]

#0  0x7fdde8bd6485 in cancel (ht=0x2b010c0, entry=0x21, flags=7) at 
../src/pj/timer.c:331

timer_node_slot = 45093056

#1  0x7fdde8bd6a00 in cancel_timer (ht=0x2b010c0, entry=0x21, flags=6, 
id_val=0) at ../src/pj/timer.c:581

count = 32733

Would this issue be related to the PJSIP project or is this caused by Asterisk 
directly?


I would like to start this bug moving so I am happy to raise this to the PJSIP 
team if needed.


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

[asterisk-dev] Asterisk 13 GIT Deadlock

[Ross Beer]

Hi All,


I've raised a ticket for a recent deadlock in Asterisk and can't track down the 
cause:


  1.  ASTERISK-26686 
(https://issues.asterisk.org/jira/browse/ASTERISK-26686)


The issue is happening daily on multiple servers at random times.


Can anyone provide assistance on the cause so I can update the ticket with the 
correct information?


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

[asterisk-dev] Asterisk or Jansson issue?

[Ross Beer]

Hi,

Is the below segfault caused by Asterisk or Jansson? Currently using version 
2.9 as packaged with Fedora 23.

#0  0x00538392 in ast_json_free (p=0x7f330002) at json.c:190
mem = 0x7f32ffba
free_list = 0x7f336970
__PRETTY_FUNCTION__ = "ast_json_free"
#1  0x7f34fc3d5701 in json_delete () at /lib64/libjansson.so.4
#2  0x7f34fc3d0631 in hashtable_do_clear () at /lib64/libjansson.so.4
#3  0x7f34fc3d06d9 in hashtable_close () at /lib64/libjansson.so.4
#4  0x7f34fc3d5721 in json_delete () at /lib64/libjansson.so.4
#5  0x00538153 in json_decref (json=0x7f33d8497fa8) at 
/usr/include/jansson.h:112
#6  0x005384bc in ast_json_unref (json=0x7f33d8497fa8) at json.c:224
__mem___LINE__ = 0x7f33d8497f60
free_list = 0x7f3382395ba0
mem = 0x110074
#7  0x00539b0f in json_payload_destructor (obj=0x7f33d82f9f80) at 
json.c:922
payload = 0x7f33d82f9f80
#8  0x0045e560 in internal_ao2_ref (user_data=0x7f33d82f9f80, delta=-1, 
file=0x6b8c5b "astobj2.c", line=505, func=0x6b8ee8 <__FUNCTION__.8971> 
"__ao2_ref") at astobj2.c:438
obj = 0x7f33d82f9f68
obj_mutex = 0x7f3382395bb8
obj_rwlock = 0x7f33d8497fa8
current_value = 0
ret = 1
__PRETTY_FUNCTION__ = "internal_ao2_ref"
#9  0x0045e811 in __ao2_ref (user_data=0x7f33d82f9f80, delta=-1) at 
astobj2.c:505
__FUNCTION__ = "__ao2_ref"
#10 0x0045e882 in __ao2_cleanup (obj=0x7f33d82f9f80) at astobj2.c:518
#11 0x005e0b26 in stasis_message_dtor (obj=0x7f33d82cb090) at 
stasis_message.c:107
message = 0x7f33d82cb090
#12 0x0045e560 in internal_ao2_ref (user_data=0x7f33d82cb090, delta=-1, 
file=0x6b8c5b "astobj2.c", line=505, func=0x6b8ee8 <__FUNCTION__.8971> 
"__ao2_ref") at astobj2.c:438
obj = 0x7f33d82cb078
obj_mutex = 0x3758d50
obj_rwlock = 0x7f33d82cb090
current_value = 0
ret = 1
__PRETTY_FUNCTION__ = "internal_ao2_ref"
#13 0x0045e811 in __ao2_ref (user_data=0x7f33d82cb090, delta=-1) at 
astobj2.c:505
__FUNCTION__ = "__ao2_ref"
#14 0x0045e882 in __ao2_cleanup (obj=0x7f33d82cb090) at astobj2.c:518
#15 0x005cf81f in dispatch_exec_async (local=0x7f3382395ca0) at 
stasis.c:716
sub = 0x3758d50
message = 0x7f33d82cb090
#16 0x005ee36a in ast_taskprocessor_execute (tps=0x2c23f20) at 
taskprocessor.c:965
local = {local_data = 0x3758d50, data = 0x7f33d82cb090}
t = 0x7f33d82d0cd0
size = 0
__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#17 0x005ec695 in default_tps_processing_function (data=0x3982ab0) at 
taskprocessor.c:185
listener = 0x3982ab0
tps = 0x2c23f20
pvt = 0x3758de0
sem_value = 0
res = 0
__PRETTY_FUNCTION__ = "default_tps_processing_function"
#18 0x00603b1c in dummy_start (data=0x3813c80) at utils.c:1235
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-7924327506780593733, 140728438389919, 139859204859648, 507904, 0, 
-7924327506755427909, 7809284277735154107}, __mask_was_saved = 0}}, __pad = 
{0x7f3382395df0, 0x0, 0x0, 0x0}}
__cancel_routine = 0x45257a 
__cancel_arg = 0x7f3382396700
__not_first_call = 0
ret = 0x0
a = {start_routine = 0x5ec5ff , data = 
0x3982ab0, name = 0x2c36090 "default_tps_processing_function started at [  202] 
taskprocessor.c default_listener_start()"}
#19 0x7f34fbb7361a in start_thread () at /lib64/libpthread.so.0
#20 0x7f34faeaf5fd in clone () at /lib64/libc.so.6


If this looks like an Asterisk issue I will raise a ticket.

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

[asterisk-dev] sorcery_memory_cache_delete: Unable to delete object

[Ross Beer]

Hi,


Should asterisk output the following message if the object isn't in the cache?


[2016-11-18 11:50:25] ERROR[73437]: res_sorcery_memory_cache.c:1558 
sorcery_memory_cache_delete: Unable to delete object '<>' from 
sorcery cache


In my opinion, this isn't needed and just causes the logs to fill up.


If this is actually an error how can this be fixed?


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

[asterisk-dev] ASTERISK-26589 and ASTERISK-26445

[Ross Beer]

Hi All,


I have a couple of tickets open related to accessing RTP/SDP which cause 
Asterisk to deadlock and stop processing calls. This has the knock-on effect of 
task processors exceeding their limits and displaying errors. There are a few 
of these bugs now being raised (ASTERISK-26601) and I wondered if they all 
related to the two tickets ASTERISK-26589 and ASTERISK-26445?


If they are can I ask if these are being worked on? If not I will most likely 
seek a developer to resolve the issue.


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

[Ross Beer]

Hi Joshua,


Looking at traces, there are packets being sent with length 4. These show as 
PSH, ACK in a Wireshark. However, in TLS I don't see any such packets which I 
believe is the cause of the TLS connection is being closed.


Can you confirm if Asterisk does send these packets on TLS transports?


Kind regards,

Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 09 November 2016 17:48
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Chan_pjsip keep_alive_interval

On Wed, Nov 9, 2016, at 01:25 PM, Ross Beer wrote:
> Hi,
>
>
> I'm investigating an issue where TLS connections close with a 'RST' after
> a random period of time.
>
>
> I can see that PJSIP sets 'PJSIP_TRANSPORT_IDLE_TIME=600', with the
> option in pjsip.conf 'keep_alive_internal' set, does this set both
> 'PJSIP_TCP_KEEP_ALIVE_INTERVAL' and 'PJSIP_TLS_KEEP_ALIVE_INTERVAL'?

The keep_alive_interval option doesn't set those in PJSIP. It controls
the interval at which code in Asterisk (not PJSIP) will send a
keepalive. There is no expectation that a response is received, as it
does not generate a SIP request itself. It allows runtime control
instead of compile time control.

>
>
> Does a keep-alive packet actually reset 'PJSIP_TRANSPORT_IDLE_TIME' if a
> response is received? If no response received, how many attempts are made
> before asterisk disconnects the session?

It does not reset the timer locally. Its purpose is to ensure the remote
side does not disconnect us for being idle. If we received a message
then our local idle timer would be reset.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
Asterisk custom communications - PBX, VoIP gateways, IVRs 
...<http://www.asterisk.org/>
www.asterisk.org
Asterisk: an open source framework that lets you build communications 
applications for IP PBX, VoIP gateways, conference servers and custom phone apps


[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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 --
api digital - problem solved.<http://www.api-digital.com/>
www.api-digital.com
API Digital Website




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

[asterisk-dev] Chan_pjsip keep_alive_interval

[Ross Beer]

Hi,


I'm investigating an issue where TLS connections close with a 'RST' after a 
random period of time.


I can see that PJSIP sets 'PJSIP_TRANSPORT_IDLE_TIME=600', with the option in 
pjsip.conf 'keep_alive_internal' set, does this set both 
'PJSIP_TCP_KEEP_ALIVE_INTERVAL' and 'PJSIP_TLS_KEEP_ALIVE_INTERVAL'?


Does a keep-alive packet actually reset 'PJSIP_TRANSPORT_IDLE_TIME' if a 
response is received? If no response received, how many attempts are made 
before asterisk disconnects the session?


There are options to do 'keep alive' from the Linux kernel, however, I feel 
that PJSIP keeping sessions alive is the best option.


I would be grateful on any views you may have.


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] Asterisk Recv-Q Backlog

[Ross Beer]

As these are uneven ports would this be an RTCP backlog?


How does Asterisk process RTCP?



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 03 November 2016 16:27
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Asterisk Recv-Q Backlog


Hi,

Quick question, what could cause a high Recv-Q on Asterisk 13 RTP?

Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
udp0  0 0.0.0.0:25952   0.0.0.0:*   
33260/asterisk
udp  768  0 0.0.0.0:25953   0.0.0.0:*   
33260/asterisk
udp 1536  0 0.0.0.0:27911   0.0.0.0:*   
33260/asterisk
udp  768  0 0.0.0.0:49013   0.0.0.0:*   
33260/asterisk


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

[asterisk-dev] Asterisk Recv-Q Backlog

[Ross Beer]

Hi,

Quick question, what could cause a high Recv-Q on Asterisk 13 RTP?

Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
udp0  0 0.0.0.0:25952   0.0.0.0:*   
33260/asterisk
udp  768  0 0.0.0.0:25953   0.0.0.0:*   
33260/asterisk
udp 1536  0 0.0.0.0:27911   0.0.0.0:*   
33260/asterisk
udp  768  0 0.0.0.0:49013   0.0.0.0:*   
33260/asterisk


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

[Ross Beer]

Hi


I have spent over a year migrating from chan_sip (1.8) to chan_pjsip (13) and 
it has been stressful.


However, there is light at the end of the tunnel. When first migrating Asterisk 
would crash around 20 times a day or more. However, by investing time and money 
into resolving the segfaults, database issues and task managers I feel that the 
new stack is stable with the odd bug still remaining. The most common crash I 
get from the stack at the moment is due to TLS connections, which the PJSIP 
team are currently working on and I am assured there will be a patch in the 
coming days.


>From experience, I can say that chan_pjsip is more scalable and efficiently 
>uses server resources compared to chan_sip. It is the way forward!


I would welcome a working group to manage the migration from chan_sip to 
chan_pjsip as there are still features in chan_sip that have not been 
implemented in chan_pjsip.  I would also welcome additional features such as 
'Device Feature Key Synchronization' (as-feature-event).


At present, there are a few undocumented features, such as the sorcery 
configuration:


endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error


The above stops a full database query that loads every single endpoint at 
startup, which can cause overload on systems with a number of endpoints. 
Therefore documentation covering the whole sip stack and features would help 
people migrate easier.


Finally, I would like to thank everyone who has been working on ironing out the 
chan_pjsip bugs.


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Olle E. Johansson 

Sent: 05 October 2016 10:42
To: Asterisk Developers Mailing List
Cc: Olle E Johansson
Subject: Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace

Hi!

>From my perspective I know that maintaining a SIP stack requires *A LOT* of 
>effort, so I understand that a project can't maintain two of them.

I suggest that a working group is created for the transition and that the first 
task is to compare the functionality.
Last time I checked the functionality *I need* (but maybe not everyone else) 
was non-existing in PJSIP so I could not use it.
It may have changed since then.

I think the goal has to be to gradually phase out the ugly code in chan_sip and 
celebrate the day it's gone, but
make sure we don't leave functionality (and users) behind and have good 
guidelines for the transition.

I still think we should totally rewrite how chan_pjsip is configured. That 
concept is very far away from other SIP implementations.
But that's my personal opinion from a small cold corner of the world, using 
Asterisk in non-PBX ways as large scale media
and feature servers.

Executive summary: Create a working group that maintains the feature gap, makes 
sure it's going away and also makes sure
that we have enough material that explains the gold that hides in chan_pjsip!

/O
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
api digital - problem solved.
www.api-digital.com
API Digital Website




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] Task Processor Issue ASTERISK-26145

[Ross Beer]

I think this is related to the following review board link:


https://gerrit.asterisk.org/#/c/3320/


When using ODBC storage with VM there is a backlog in processing MWI notify 
messages. This patch has helped the issue, but not totally resolved it. There 
is debate on the review board if this is needed by from my experience it is!


When using ODBC storage for VM are only registered devices checked for new 
messages or all peers? Does Asterisk try to send alerts to every peer that has 
voicemail even if its not registered?



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 01 August 2016 11:57
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Task Processor Issue ASTERISK-26145


Hi,


Just has the same issue on a different test box:


pjsip/distributor-00cc 68046  0  5  
  450500

pjsip/distributor-00cd 68846  0  5  
  450500

pjsip/distributor-00ce 79573533 12  
  450500

pjsip/distributor-00cf 65862  0  9  
  450500


This happens daily on multiple test servers.


Can anyone help?

Ross

From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 01 August 2016 11:37
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Task Processor Issue ASTERISK-26145


Hi All,


I am still experiencing a task processor issue which stops Asterisk 13 
processing packets. The task processor shows the following:


pjsip/distributor-00b1 64041  0  6  
  450500

pjsip/distributor-00b2 56970  0  8  
  450500

pjsip/distributor-00b3 59429  0  6  
  450500

pjsip/distributor-00b4 68142  0  8  
  450500

pjsip/distributor-00b5 50941  0  6  
  450500

pjsip/distributor-00b6 56458  0  4  
  450500

pjsip/distributor-00b7 62735  0  5  
  450500

pjsip/distributor-00b8 62856  0  6  
  450500

pjsip/distributor-00b9 68292  0  5  
  450500

pjsip/distributor-00ba 71961  0  4  
  450500

pjsip/distributor-00bb 54810  0  9  
  450500

pjsip/distributor-00bc 60165  0  5  
  450500

pjsip/distributor-00bd 72316  0 10  
  450500

pjsip/distributor-00be 58807  0  8  
  450500

pjsip/distributor-00bf 59188  0  6  
  450500

pjsip/distributor-00c0 66673  0  7  
  450500

pjsip/distributor-00c1 54221  0  5  
  450500

pjsip/distributor-00c2 61391  0  5  
  450500

pjsip/distributor-00c3 78313527  6  
  450500

pjsip/distributor-00c4 70249  0  4  
  450500

pjsip/distributor-00c5 82573  0 15  
  450500

pjsip/distributor-00c6 63342  0 11  
  450500

pjsip/distributor-00c7 56292  0 10  
  450500

pjsip/distributor-00c8 52082  0  5  
  450500

pjsip/distributor-00c9 68204  0  9  
  450500

pjsip/distributor-00ca 62369  0  4  
  450500

pjsip/distributor-00cb 56135  0  7  
  450500

pjsip/distributor-00cc 62608  0  8  
  450500

pjsip/distributor-00cd 58685  0  5  
  450500

pjsip/distributor-00ce 54513  0  8  
  450500

pjsip/distributor-00cf 56525  0  6  
  450500


Processing appears to be fairly evenly distributed across the threads, however, 
one thread appears to get flooded. I

Re: [asterisk-dev] Task Processor Issue ASTERISK-26145

[Ross Beer]

Hi,


Just has the same issue on a different test box:


pjsip/distributor-00cc 68046  0  5  
  450500

pjsip/distributor-00cd 68846  0  5  
  450500

pjsip/distributor-00ce 79573533 12  
  450500

pjsip/distributor-00cf 65862  0  9  
  450500


This happens daily on multiple test servers.


Can anyone help?

Ross

From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 01 August 2016 11:37
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Task Processor Issue ASTERISK-26145


Hi All,


I am still experiencing a task processor issue which stops Asterisk 13 
processing packets. The task processor shows the following:


pjsip/distributor-00b1 64041  0  6  
  450500

pjsip/distributor-00b2 56970  0  8  
  450500

pjsip/distributor-00b3 59429  0  6  
  450500

pjsip/distributor-00b4 68142  0  8  
  450500

pjsip/distributor-00b5 50941  0  6  
  450500

pjsip/distributor-00b6 56458  0  4  
  450500

pjsip/distributor-00b7 62735  0  5  
  450500

pjsip/distributor-00b8 62856  0  6  
  450500

pjsip/distributor-00b9 68292  0  5  
  450500

pjsip/distributor-00ba 71961  0  4  
  450500

pjsip/distributor-00bb 54810  0  9  
  450500

pjsip/distributor-00bc 60165  0  5  
  450500

pjsip/distributor-00bd 72316  0 10  
  450500

pjsip/distributor-00be 58807  0  8  
  450500

pjsip/distributor-00bf 59188  0  6  
  450500

pjsip/distributor-00c0 66673  0  7  
  450500

pjsip/distributor-00c1 54221  0  5  
  450500

pjsip/distributor-00c2 61391  0  5  
  450500

pjsip/distributor-00c3 78313527  6  
  450500

pjsip/distributor-00c4 70249  0  4  
  450500

pjsip/distributor-00c5 82573  0 15  
  450500

pjsip/distributor-00c6 63342  0 11  
  450500

pjsip/distributor-00c7 56292  0 10  
  450500

pjsip/distributor-00c8 52082  0  5  
  450500

pjsip/distributor-00c9 68204  0  9  
  450500

pjsip/distributor-00ca 62369  0  4  
  450500

pjsip/distributor-00cb 56135  0  7  
  450500

pjsip/distributor-00cc 62608  0  8  
  450500

pjsip/distributor-00cd 58685  0  5  
  450500

pjsip/distributor-00ce 54513  0  8  
  450500

pjsip/distributor-00cf 56525  0  6  
  450500


Processing appears to be fairly evenly distributed across the threads, however, 
one thread appears to get flooded. I though this could be related to voicemail 
and MWI https://issues.asterisk.org/jira/browse/ASTERISK-26229 but I am 
currently testing the patch and it's not showing a queue on the new 
taskprocessor for app_voicemail.


What features use the 'pjsip/distributor' and how can I identify what is 
causing the backlog?


One thing I did notice in the latest back trace, was a call pickup was being 
done a the time of the issue. Is there a lock that isn't released here?


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

[asterisk-dev] Task Processor Issue ASTERISK-26145

[Ross Beer]

Hi All,


I am still experiencing a task processor issue which stops Asterisk 13 
processing packets. The task processor shows the following:


pjsip/distributor-00b1 64041  0  6  
  450500

pjsip/distributor-00b2 56970  0  8  
  450500

pjsip/distributor-00b3 59429  0  6  
  450500

pjsip/distributor-00b4 68142  0  8  
  450500

pjsip/distributor-00b5 50941  0  6  
  450500

pjsip/distributor-00b6 56458  0  4  
  450500

pjsip/distributor-00b7 62735  0  5  
  450500

pjsip/distributor-00b8 62856  0  6  
  450500

pjsip/distributor-00b9 68292  0  5  
  450500

pjsip/distributor-00ba 71961  0  4  
  450500

pjsip/distributor-00bb 54810  0  9  
  450500

pjsip/distributor-00bc 60165  0  5  
  450500

pjsip/distributor-00bd 72316  0 10  
  450500

pjsip/distributor-00be 58807  0  8  
  450500

pjsip/distributor-00bf 59188  0  6  
  450500

pjsip/distributor-00c0 66673  0  7  
  450500

pjsip/distributor-00c1 54221  0  5  
  450500

pjsip/distributor-00c2 61391  0  5  
  450500

pjsip/distributor-00c3 78313527  6  
  450500

pjsip/distributor-00c4 70249  0  4  
  450500

pjsip/distributor-00c5 82573  0 15  
  450500

pjsip/distributor-00c6 63342  0 11  
  450500

pjsip/distributor-00c7 56292  0 10  
  450500

pjsip/distributor-00c8 52082  0  5  
  450500

pjsip/distributor-00c9 68204  0  9  
  450500

pjsip/distributor-00ca 62369  0  4  
  450500

pjsip/distributor-00cb 56135  0  7  
  450500

pjsip/distributor-00cc 62608  0  8  
  450500

pjsip/distributor-00cd 58685  0  5  
  450500

pjsip/distributor-00ce 54513  0  8  
  450500

pjsip/distributor-00cf 56525  0  6  
  450500


Processing appears to be fairly evenly distributed across the threads, however, 
one thread appears to get flooded. I though this could be related to voicemail 
and MWI https://issues.asterisk.org/jira/browse/ASTERISK-26229 but I am 
currently testing the patch and it's not showing a queue on the new 
taskprocessor for app_voicemail.


What features use the 'pjsip/distributor' and how can I identify what is 
causing the backlog?


One thing I did notice in the latest back trace, was a call pickup was being 
done a the time of the issue. Is there a lock that isn't released here?


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] No Core Dumps

[Ross Beer]

Hi Joshua,


There was one instance of this being reported on a ticket I read last week. It 
just strange that on Fedora 23 that this has suddenly stopped happening.


The previous example shows that the dump was attempted but no files created. 
They were being created for previous versions.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 22 July 2016 13:45
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] No Core Dumps

Ross Beer wrote:
> Hi All,
>
>
> Asterisk has stopped creating core dumps, the logs show the following:
>
>
> Jul 22 09:39:20 audit[826]: ANOM_ABEND auid=4294967295 uid=0 gid=0
> ses=4294967295 pid=826 comm="asterisk"
> exe=2F7573722F7362696E2F617374657269736B202864656C6574656429 sig=11
>
> Jul 22 09:39:20 kernel: asterisk[826]: segfault at 4 ip
> 7f0ea22f69af sp 7f0df03e2ae0 error 4 in libasteriskpj.so.2
> (deleted)[7f0ea21e4000+177000]
>
> Jul 22 09:40:20 systemd-coredump[11695]: Process 11216 (asterisk) of
> user 0 dumped core.
>
>
> Stack trace of thread 826:
>
> #0 0x7f0ea22f69af n/a (/usr/lib64/libasteriskpj.so.2 (deleted))
>
>
> Has anything changed which would stop the core files being created on a
> crash?

There have been no changes which would impact the creation of core
dumps, and I haven't seen anyone else report problems with core dump
creation either.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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] No Core Dumps

[Ross Beer]

Hi All,


Asterisk has stopped creating core dumps, the logs show the following:


Jul 22 09:39:20 audit[826]: ANOM_ABEND auid=4294967295 uid=0 gid=0 
ses=4294967295 pid=826 comm="asterisk" 
exe=2F7573722F7362696E2F617374657269736B202864656C6574656429 sig=11

Jul 22 09:39:20 kernel: asterisk[826]: segfault at 4 ip 7f0ea22f69af sp 
7f0df03e2ae0 error 4 in libasteriskpj.so.2 (deleted)[7f0ea21e4000+177000]

Jul 22 09:40:20 systemd-coredump[11695]: Process 11216 (asterisk) of user 0 
dumped core.


Stack trace of thread 826:

#0  0x7f0ea22f69af n/a (/usr/lib64/libasteriskpj.so.2 (deleted))


Has anything changed which would stop the core files being created on a crash?


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

[asterisk-dev] Asterisk ABORTS

[Ross Beer]

Hi All,


I have a number of tickets open which are causing Asterisk 13 to crash multiple 
times per day.


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

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

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


There is also a deadlock causing an issue:


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


I really would like to get these bugs resolved, would anyone like to make an 
offer to fix these as Asterisk 13 is currently unusable?


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] [BOUNTY] Bug Fixes

[Ross Beer]

Hi Sean,


$500 in total as they shouldn't need too much work.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Sean Bright 

Sent: 11 July 2016 12:25
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] [BOUNTY] Bug Fixes

On 7/7/2016 8:22 AM, Ross Beer wrote:

Currently, there are a few open issues with the Asterisk project which require 
urgent fixes:

https://issues.asterisk.org/jira/browse/ASTERISK-26145
https://issues.asterisk.org/jira/browse/ASTERISK-26174
https://issues.asterisk.org/jira/browse/ASTERISK-26166
https://issues.asterisk.org/jira/browse/ASTERISK-26164
https://issues.asterisk.org/jira/browse/ASTERISK-26112
https://issues.asterisk.org/jira/browse/ASTERISK-26113


I am therefore offering $500 USD for these to be resolved.

Is that $500 each or $500 total?

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

[asterisk-dev] ASTERISK-26145 - Asterisk 13.10.0-rc2 and SVN Deadlock

[Ross Beer]

Hi,


Would it be possible for someone to take a look at the following issue ASAP?


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


Asterisk deadlocks on multiple test boxes and will not process any further 
information.


I would be very grateful on any input.


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

[asterisk-dev] [BOUNTY] Bug Fixes

[Ross Beer]

Hi,


Currently, there are a few open issues with the Asterisk project which require 
urgent fixes:

https://issues.asterisk.org/jira/browse/ASTERISK-26145
https://issues.asterisk.org/jira/browse/ASTERISK-26174
https://issues.asterisk.org/jira/browse/ASTERISK-26166
https://issues.asterisk.org/jira/browse/ASTERISK-26164
https://issues.asterisk.org/jira/browse/ASTERISK-26112
https://issues.asterisk.org/jira/browse/ASTERISK-26113


I am therefore offering $500 USD for these to be resolved.


Please contact me directly

-- 
_
-- 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-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

I've attached further backtraces, however, asterisk needs to be recompiled with 
DEBUG_THREADS to show the locks. I will do this now ready for the next time 
this happens.



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 30 June 2016 12:16
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly 
caused by HEP

Ross Beer wrote:
> It appears to get stuck, however, chan_pjsip stops accepting registrations.

Can you put a newer deadlock backtrace up on your issue?

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

It appears to get stuck, however, chan_pjsip stops accepting registrations.



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 30 June 2016 12:10
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly 
caused by HEP

Ross Beer wrote:
> Hi Joshua,
>
>
> Is there a way to see what is in the queue?
>
>
> If we can identify the tasks we may be able to fix the reason for the
> backlog.

No, items are not identifiable. They only contain the function to invoke
and the data to pass to it. Based on the actual taskprocessor itself you
can limit what exactly can be in it.

Does the queue go down, or does it just peak and go down eventually?

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

Hi Joshua,


Is there a way to see what is in the queue?


If we can identify the tasks we may be able to fix the reason for the backlog.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 30 June 2016 12:04
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly 
caused by HEP

Ross Beer wrote:



>
> Shouldn't any task be distributed evenly across the above threads?

Task processors are queues of work, not threads. Threading in PJSIP
relies on a guarantee of serialization so some things will always go to
the same queue. Depending on what is in that queue it can get backed up
as you've seen.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

Hi Richard,


I've just had another task processor max out, this time with the following 
thread:


pjsip/distributor-00c7  1286513 10  
  450500


All other threads around this are processing very few tasks:


pjsip/distributor-00b1  1745  0  4  
  450500

pjsip/distributor-00b2  1394  0  3  
  450500

pjsip/distributor-00b3  1408  0  3  
  450500

pjsip/distributor-00b4  1765  0  6  
  450500

pjsip/distributor-00b5  1600  0  3  
  450500

pjsip/distributor-00b6  1683  0  6  
  450500

pjsip/distributor-00b7  1421  0  4  
  450500

pjsip/distributor-00b8  1664  0  4  
  450500

pjsip/distributor-00b9  1514  0  4  
  450500

pjsip/distributor-00ba  2067  0  4  
  450500

pjsip/distributor-00bb  1477  0  4  
  450500

pjsip/distributor-00bc  1740  0  3  
  450500

pjsip/distributor-00bd  1468  0  4  
  450500

pjsip/distributor-00be  1313  0  3  
  450500

pjsip/distributor-00bf  1862  0  6  
  450500

pjsip/distributor-00c0  1592  0  4  
  450500

pjsip/distributor-00c1  1637  0  4  
  450500

pjsip/distributor-00c2  1613  0  4  
  450500

pjsip/distributor-00c3  2130  0  6  
  450500

pjsip/distributor-00c4  1825  0  8  
  450500

pjsip/distributor-00c5  1871  0  4  
  450500

pjsip/distributor-00c6  1508  0  4  
  450500

pjsip/distributor-00c7  1286513 10  
  450500

pjsip/distributor-00c8  1892  0  5  
  450500

pjsip/distributor-00c9  1661  0  3  
  450500

pjsip/distributor-00ca  1771  0  5  
  450500

pjsip/distributor-00cb  1433  0  4  
  450500

pjsip/distributor-00cc  1644  0  6  
  450500

pjsip/distributor-00cd  1567  0  4  
  450500

pjsip/distributor-00ce  1738  0  3  
  450500

pjsip/distributor-00cf  1736  0  3  
  450500


Shouldn't any task be distributed evenly across the above threads?


Kind regards,


Ross


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Richard Mudgett 

Sent: 28 June 2016 17:00
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly 
caused by HEP



On Tue, Jun 28, 2016 at 10:20 AM, Ross Beer 
mailto:ross.b...@outlook.com>> wrote:

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-00de' scheduler. This is proving difficult as you only see 
counts and not actual waiting tasks.

The res_hep_rtcp.so module is what creates the subm:rtp_topic stasis message 
bus subscription.  Since you have indicated that you are not using that feature 
you should not load the module.

The taskprocessors that begin with 'subm:' (m for mailbox) or 'subp:' (p for 
thread pool) are stasis message bus subscriptions.  The 'subm:' taskprocessors 
have a single dedicated thread to process the taskprocessor tasks.  The 'subp:' 
taskprocessors do not have a dedicated thread.  Those taskprocessors get 
executed by an available thread from 

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

[Ross Beer]

Hi Richard,


Thank you for the additional information it is very useful. I can no longer see 
the subm:rtp_topic after the last crash with the HEP modules disabled. This 
will hopefully resolve that issue, however, I've just seen the following 
SIGSEGV issue:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f1ee50edda0 in pj_pool_release () from /lib64/libpj.so.2
[Current thread is 1 (Thread 0x7f1ed3de4700 (LWP 31442))]
#0  0x7f1ee50edda0 in pj_pool_release () at /lib64/libpj.so.2
#1  0x7f1ee6c32b48 in pjsip_tx_data_dec_ref () at /lib64/libpjsip.so.2
#2  0x7f1ee6c32d60 in pjsip_transport_send () at /lib64/libpjsip.so.2
#3  0x7f1ee6c3e6be in tsx_send_msg () at /lib64/libpjsip.so.2
#4  0x7f1ee6c3e227 in tsx_timer_callback () at /lib64/libpjsip.so.2
#5  0x7f1ee50f63b7 in pj_timer_heap_poll () at /lib64/libpj.so.2
#6  0x7f1ee6c2dc3b in pjsip_endpt_handle_events2 () at /lib64/libpjsip.so.2
#7  0x7f1ed58c7508 in monitor_thread_exec (endpt=) at 
res_pjsip.c:3863
delay = {sec = 0, msec = 10}
#8  0x7f1ee50e7a56 in thread_main () at /lib64/libpj.so.2
#9  0x7f1f66ad261a in start_thread () at /lib64/libpthread.so.0
#10 0x7f1f65e0e59d in clone () at /lib64/libc.so.6

Should another issue be raised for this?

Kind regards,

Ross




From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Richard Mudgett 

Sent: 28 June 2016 17:00
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly 
caused by HEP



On Tue, Jun 28, 2016 at 10:20 AM, Ross Beer 
mailto:ross.b...@outlook.com>> wrote:

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-00de' scheduler. This is proving difficult as you only see 
counts and not actual waiting tasks.

The res_hep_rtcp.so module is what creates the subm:rtp_topic stasis message 
bus subscription.  Since you have indicated that you are not using that feature 
you should not load the module.

The taskprocessors that begin with 'subm:' (m for mailbox) or 'subp:' (p for 
thread pool) are stasis message bus subscriptions.  The 'subm:' taskprocessors 
have a single dedicated thread to process the taskprocessor tasks.  The 'subp:' 
taskprocessors do not have a dedicated thread.  Those taskprocessors get 
executed by an available thread from the stasis thread pool.  The stasis thread 
pool is configured by the stasis.conf file.

Richard

-- 
_
-- 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-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-00de' 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-boun...@lists.digium.com 
 on behalf of Matthew Jordan 

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  wrote:
> On Tue, Jun 28, 2016 at 8:54 AM, Ross Beer  wrote:
>> Hi,
>>
>>
>> I am still facing a task processor issue on subm:rtp_topic-00de, 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
-- 
_
-- 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-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

Hi,


I am still facing a task processor issue on subm:rtp_topic-00de, looking at 
the backtrace it looks to be related to HEP.


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 would be grateful if someone could take a look at this bug again to confirm 
the above.


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] Serious Asterisk 13.10.0 issue

[Ross Beer]

Regarding: https://issues.asterisk.org/jira/browse/ASTERISK-26145


I have just put up some more debug info for the above issue and it appears that 
ICE / STUN may be causing the issue.



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 24 June 2016 12:05
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue


Hi Joshua,


I believe the issue to be related to the option 'rtp_timeout', on an Asterisk 
setup that does not use this option there is no such issue.


I assume that tasks are created to check that RTP is being sent and these are 
getting backed up and hitting the 'high water' mark.


I am happy to test any patches as soon as they become available.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 24 June 2016 11:59
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue

Ross Beer wrote:
> Hi,
>
>
> The latest release of asterisk is suffering a bug where it reaches too
> many tasks and stops processing all SIP packets when using PJSIP.
>
>
> I have raised a fault here:
>
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26145
>
>
> This is a show stopper for the next version of asterisk, can we try to
> resolve this issue as a matter of urgency.

We'll look at the issue and determine the proper steps forward,
including whether it should block things or not.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] Serious Asterisk 13.10.0 issue

[Ross Beer]

Ok,


I believe the segfault to be related to a previous issue:


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

This issue has been resolved, however looking at the 'configure' script it 
looks like it isn't finding the PJPROJECT method. Should there be a variable 
used when compiling PJPROJECT or is this automatically discovered?

Regards,

Ross

From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 24 June 2016 13:41
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue


The following issue has been created for the seg fault:


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



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 24 June 2016 13:20
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue

Ross Beer wrote:
> Hi,
>
>
> Also just had the following crash:
>
>
> [Thread debugging using libthread_db enabled]
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0 0x7f4e7c16fb29 in pj_atomic_dec_and_get () from /lib64/libpj.so.2
>
> [Current thread is 1 (Thread 0x7f4e6d9fc700 (LWP 10799))]
>
> #0 0x7f4e7c16fb29 in pj_atomic_dec_and_get () at /lib64/libpj.so.2
>
> #1 0x7f4e7dcbab30 in pjsip_tx_data_dec_ref () at
> /lib64/libpjsip.so.2
>
> #2 0x7f4e7dcc5f07 in tsx_shutdown () at /lib64/libpjsip.so.2
>
> #3 0x7f4e7dcc6141 in tsx_set_state () at /lib64/libpjsip.so.2
>
> #4 0x7f4e7dcc61ca in tsx_on_state_terminated () at
> /lib64/libpjsip.so.2
>
> #5 0x7f4e7dcc6227 in tsx_timer_callback () at /lib64/libpjsip.so.2
>
> #6 0x7f4e7c17e3b7 in pj_timer_heap_poll () at /lib64/libpj.so.2
>
> #7 0x7f4e7dcb5c3b in pjsip_endpt_handle_events2 () at
> /lib64/libpjsip.so.2
>
> #8 0x7f4e6fbac508 in monitor_thread_exec (endpt=)
> at res_pjsip.c:3863
>
> delay = {sec = 0, msec = 10}
>
> #9 0x7f4e7c16fa56 in thread_main () at /lib64/libpj.so.2
>
> #10 0x7f4ec5ce261a in start_thread () at /lib64/libpthread.so.0
>
> #11 0x7f4ec501e59d in clone () at /lib64/libc.so.6
>
>
> Should this be raised as a bug?

Yes.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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] Serious Asterisk 13.10.0 issue

[Ross Beer]

The following issue has been created for the seg fault:


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



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 24 June 2016 13:20
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue

Ross Beer wrote:
> Hi,
>
>
> Also just had the following crash:
>
>
> [Thread debugging using libthread_db enabled]
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0 0x7f4e7c16fb29 in pj_atomic_dec_and_get () from /lib64/libpj.so.2
>
> [Current thread is 1 (Thread 0x7f4e6d9fc700 (LWP 10799))]
>
> #0 0x7f4e7c16fb29 in pj_atomic_dec_and_get () at /lib64/libpj.so.2
>
> #1 0x7f4e7dcbab30 in pjsip_tx_data_dec_ref () at
> /lib64/libpjsip.so.2
>
> #2 0x7f4e7dcc5f07 in tsx_shutdown () at /lib64/libpjsip.so.2
>
> #3 0x7f4e7dcc6141 in tsx_set_state () at /lib64/libpjsip.so.2
>
> #4 0x7f4e7dcc61ca in tsx_on_state_terminated () at
> /lib64/libpjsip.so.2
>
> #5 0x7f4e7dcc6227 in tsx_timer_callback () at /lib64/libpjsip.so.2
>
> #6 0x7f4e7c17e3b7 in pj_timer_heap_poll () at /lib64/libpj.so.2
>
> #7 0x7f4e7dcb5c3b in pjsip_endpt_handle_events2 () at
> /lib64/libpjsip.so.2
>
> #8 0x7f4e6fbac508 in monitor_thread_exec (endpt=)
> at res_pjsip.c:3863
>
> delay = {sec = 0, msec = 10}
>
> #9 0x7f4e7c16fa56 in thread_main () at /lib64/libpj.so.2
>
> #10 0x7f4ec5ce261a in start_thread () at /lib64/libpthread.so.0
>
> #11 0x7f4ec501e59d in clone () at /lib64/libc.so.6
>
>
> Should this be raised as a bug?

Yes.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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] Serious Asterisk 13.10.0 issue

[Ross Beer]

Hi,


Also just had the following crash:


[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x7f4e7c16fb29 in pj_atomic_dec_and_get () from /lib64/libpj.so.2

[Current thread is 1 (Thread 0x7f4e6d9fc700 (LWP 10799))]

#0  0x7f4e7c16fb29 in pj_atomic_dec_and_get () at /lib64/libpj.so.2

#1  0x7f4e7dcbab30 in pjsip_tx_data_dec_ref () at /lib64/libpjsip.so.2

#2  0x7f4e7dcc5f07 in tsx_shutdown () at /lib64/libpjsip.so.2

#3  0x7f4e7dcc6141 in tsx_set_state () at /lib64/libpjsip.so.2

#4  0x7f4e7dcc61ca in tsx_on_state_terminated () at /lib64/libpjsip.so.2

#5  0x7f4e7dcc6227 in tsx_timer_callback () at /lib64/libpjsip.so.2

#6  0x7f4e7c17e3b7 in pj_timer_heap_poll () at /lib64/libpj.so.2

#7  0x7f4e7dcb5c3b in pjsip_endpt_handle_events2 () at /lib64/libpjsip.so.2

#8  0x7f4e6fbac508 in monitor_thread_exec (endpt=) at 
res_pjsip.c:3863

delay = {sec = 0, msec = 10}

#9  0x7f4e7c16fa56 in thread_main () at /lib64/libpj.so.2

#10 0x7f4ec5ce261a in start_thread () at /lib64/libpthread.so.0

#11 0x7f4ec501e59d in clone () at /lib64/libc.so.6


Should this be raised as a bug?


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 24 June 2016 12:05
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue


Hi Joshua,


I believe the issue to be related to the option 'rtp_timeout', on an Asterisk 
setup that does not use this option there is no such issue.


I assume that tasks are created to check that RTP is being sent and these are 
getting backed up and hitting the 'high water' mark.


I am happy to test any patches as soon as they become available.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 24 June 2016 11:59
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue

Ross Beer wrote:
> Hi,
>
>
> The latest release of asterisk is suffering a bug where it reaches too
> many tasks and stops processing all SIP packets when using PJSIP.
>
>
> I have raised a fault here:
>
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26145
>
>
> This is a show stopper for the next version of asterisk, can we try to
> resolve this issue as a matter of urgency.

We'll look at the issue and determine the proper steps forward,
including whether it should block things or not.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] Serious Asterisk 13.10.0 issue

[Ross Beer]

Hi Joshua,


I believe the issue to be related to the option 'rtp_timeout', on an Asterisk 
setup that does not use this option there is no such issue.


I assume that tasks are created to check that RTP is being sent and these are 
getting backed up and hitting the 'high water' mark.


I am happy to test any patches as soon as they become available.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 24 June 2016 11:59
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Serious Asterisk 13.10.0 issue

Ross Beer wrote:
> Hi,
>
>
> The latest release of asterisk is suffering a bug where it reaches too
> many tasks and stops processing all SIP packets when using PJSIP.
>
>
> I have raised a fault here:
>
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26145
>
>
> This is a show stopper for the next version of asterisk, can we try to
> resolve this issue as a matter of urgency.

We'll look at the issue and determine the proper steps forward,
including whether it should block things or not.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] Serious Asterisk 13.10.0 issue

[Ross Beer]

Hi,


The latest release of asterisk is suffering a bug where it reaches too many 
tasks and stops processing all SIP packets when using PJSIP.


I have raised a fault here:


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


This is a show stopper for the next version of asterisk, can we try to resolve 
this issue as a matter of urgency.


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] Asterisk GIT-13-4d52b4cM - Task Processors

[Ross Beer]

Hi,


Looking at the taskprocessors, which are currently running at 1317 tasks. There 
are entries for 'subp', what are these entries?


The reason I ask is, since start there have been about 12,000 process tasks and 
a max depth of 67.


There are some endpoints with a greater depth of around 200, these are for 
standard phones.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 20 June 2016 08:50
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Asterisk GIT-13-4d52b4cM - Task Processors


Hi All,


Since updating to Asterisk GIT-13-4d52b4cM on a dev box, we are getting a lot 
of messages saying the taskprocessor is full, this then stops all registrations 
to the asterisk server.


What is the best way to diagnose this issue as the system doesn't crash, it 
just stops processing requests?


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

[asterisk-dev] Asterisk GIT-13-4d52b4cM - Task Processors

[Ross Beer]

Hi All,


Since updating to Asterisk GIT-13-4d52b4cM on a dev box, we are getting a lot 
of messages saying the taskprocessor is full, this then stops all registrations 
to the asterisk server.


What is the best way to diagnose this issue as the system doesn't crash, it 
just stops processing requests?


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

[asterisk-dev] ASTERISK-26113 res_pjsip: Lots of DNS lookups of local hostname

[Ross Beer]

Hi,


I'm still looking into why there are so many own name lookups occurring in 
Asterisk 13.


After sanity checking the physical server configuration by comparing this to an 
Asterisk 1.8 build, I can confirm that only the Asterisk 13 server is 
performing thousands of lookup numbers per minute.


Looking at the res_pjsup.c file it looks like each time a dialogue is created 
it looks up the local IP addresses (line 2391) in this piece of code:


/* Get the local bound address for the transport that will be used when 
communicating with the provided URI */
if 
(pjsip_tpmgr_find_local_addr(pjsip_endpt_get_tpmgr(ast_sip_get_pjsip_endpoint()),
 pool, type, selector,
 &local_addr, &local_port) != PJ_SUCCESS) {

/* If no local address can be retrieved using the transport manager use the 
host one */
pj_strdup(pool, &local_addr, pj_gethostname());
local_port = pjsip_transport_get_default_port_for_type(PJSIP_TRANSPORT_UDP);
}


If the transport is set to bound=0.0.0.0 there is no IP address set and 
therefore a DNS lookup is carriedout to discover the addresses.


Is there a better way to manage this situation, if the 'res_pjsip_multihomed' 
code does a lookup on startup, can this not store the address and re-use them 
here?


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] Segfault Asterisk pj_atomic_dec_and_get in res_pjsip_pubsub

[Ross Beer]

Hi Josh,


We connect to an XMPP server to publish status, but we don't publish to any 
other PJSIP servers?


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 09 June 2016 16:54
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Segfault Asterisk pj_atomic_dec_and_get in 
res_pjsip_pubsub

Ross Beer wrote:
> Hi Josh,
>
>
> Is there a way I can mitigate the presence issue, can I disable XMPP as
> the ticket shows that the issue is caused by a 'Crash when sending
> request due to server timeout'?
>
>
> Is XMPP the server causing the issue here?

XMPP is not in use, this is a SIP subscription.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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] Segfault Asterisk pj_atomic_dec_and_get in res_pjsip_pubsub

[Ross Beer]

Hi Josh,


Is there a way I can mitigate the presence issue, can I disable XMPP as the 
ticket shows that the issue is caused by a 'Crash when sending request due to 
server timeout'?


Is XMPP the server causing the issue here?


Kind regards,

Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 09 June 2016 16:18
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Segfault Asterisk pj_atomic_dec_and_get in 
res_pjsip_pubsub

Ross Beer wrote:
> Hi Joshua / Team,
>
> Sorry to push you but I think we are suffering issues which there are
> patches for on Gerrit:
>
> res_pjsip_pubsub.c: Use distributor serializer for incoming
> subscriptions.
> res_pjsip_pubsub.c: Recreate subscriptions using distributor serializer.
> pjsip_distributor.c: Consistently pick a serializer for messages.
> res_pjsip_registrar.c: Eliminate rx REGISTER request race condition.
> sorcery: Add setting object type congestion levels.
> stasis: Add setting subscription congestion levels.
> pjsip_distributor.c: Ignore messages until fully booted.
>
>
> Most of these look to be reviewed and therefore I was wondering the lead
> time on having this merged into the 13 branch?

The crash you saw has been seen even with these changes, so I do not
expect them to solve it. I would expect them to be merged in a few days.
They have other branches to go into.

Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://www.asterisk.org>
[https://www.digium.com/sites/digium/themes/digium/logo.png]<http://www.digium.com/>

Business Phone Systems | Unified Communications | Digium<http://www.digium.com/>
www.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
-- 
_
-- 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] Segfault Asterisk pj_atomic_dec_and_get in res_pjsip_pubsub

[Ross Beer]

Hi Joshua / Team,


Sorry to push you but I think we are suffering issues which there are patches 
for on Gerrit:

res_pjsip_pubsub.c: Use distributor serializer for incoming subscriptions.
res_pjsip_pubsub.c: Recreate subscriptions using distributor serializer.
pjsip_distributor.c: Consistently pick a serializer for messages.
res_pjsip_registrar.c: Eliminate rx REGISTER request race condition.
sorcery: Add setting object type congestion levels.
stasis: Add setting subscription congestion levels.
pjsip_distributor.c: Ignore messages until fully booted.

Most of these look to be reviewed and therefore I was wondering the lead time 
on having this merged into the 13 branch?

As soon as they are merged I will test these to see if they resolve the issues 
we are experiencing.

Kind regards,

Ross


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 09 June 2016 10:46
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Segfault Asterisk pj_atomic_dec_and_get in 
res_pjsip_pubsub

Ross Beer wrote:
> Hi All,
>
>
> The database issues appear to be resolved in the latest 13 branch which
> is fantastic! Thank you all for your efforts.
>
>



>  From Gerrit I notice that Richard Mudgett has a change to related to
> presence, and wondered if this commit would resolve the above issue?

It won't for this please. Please file an issue[1].

[1] https://issues.asterisk.org/jira
System Dashboard - Digium/Asterisk JIRA<https://issues.asterisk.org/jira>
issues.asterisk.org
By adding a gadget to the directory, you are making the gadget available for 
people to use on their dashboards. Only add gadgets that you trust!




--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] Segfault Asterisk pj_atomic_dec_and_get in res_pjsip_pubsub

[Ross Beer]

Hi Josh,

Thank you for your reply, I have raised an issue here:

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

Hopefully, we can resolve the issue quickly.

Kind regards,

Ross


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 09 June 2016 10:46
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Segfault Asterisk pj_atomic_dec_and_get in 
res_pjsip_pubsub

Ross Beer wrote:
> Hi All,
>
>
> The database issues appear to be resolved in the latest 13 branch which
> is fantastic! Thank you all for your efforts.
>
>



>  From Gerrit I notice that Richard Mudgett has a change to related to
> presence, and wondered if this commit would resolve the above issue?

It won't for this please. Please file an issue[1].

[1] https://issues.asterisk.org/jira
System Dashboard - Digium/Asterisk JIRA<https://issues.asterisk.org/jira>
issues.asterisk.org
By adding a gadget to the directory, you are making the gadget available for 
people to use on their dashboards. Only add gadgets that you trust!




--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] Segfault Asterisk pj_atomic_dec_and_get in res_pjsip_pubsub

[Ross Beer]

Hi All,


The database issues appear to be resolved in the latest 13 branch which is 
fantastic! Thank you all for your efforts.


I'm now facing another issue which could be related to PJSIP or Asterisk. It 
looks like an issue with Presence. Here is a snippet of the backtrace:


Program terminated with signal SIGSEGV, Segmentation fault.

#0  pj_atomic_dec_and_get (atomic_var=0x20002) at 
../src/pj/os_core_unix.c:962

962pj_mutex_lock( atomic_var->mutex );

[Current thread is 1 (Thread 0x7f3120987700 (LWP 31576))]

#0  0x7f31b4c26b29 in pj_atomic_dec_and_get (atomic_var=0x20002) at 
../src/pj/os_core_unix.c:962

new_value = 

#1  0x7f31b4c2b89d in pj_grp_lock_dec_ref (glock=0x7f3169033008) at 
../src/pj/lock.c:554

cnt = 

#2  0x7f31b4c2b89d in pj_grp_lock_dec_ref (glock=0x7f3169033008) at 
../src/pj/lock.c:631

#3  0x7f31b69a5629 in evsub_destroy (sub=sub@entry=0x7f31600ffb68) at 
../src/pjsip-simple/evsub.c:574

dlgsub_head = 

dlgsub = 

#4  0x7f31b69a57b8 in set_state (sub=sub@entry=0x7f31600ffb68, 
state=PJSIP_EVSUB_STATE_TERMINATED, state_str=, 
event=0x7f3120986ab0, event@entry=0x0, reason=reason@entry=0x0) at 
../src/pjsip-simple/evsub.c:622

prev_state = PJSIP_EVSUB_STATE_ACTIVE

dummy_event = {prev = 0x7f311c9567e8, next = 0x0, type = 
PJSIP_EVENT_USER, body = {timer = {entry = 0x0}, tsx_state = {src = {rdata = 
0x0, tdata = 0x0, timer = 0x0, status = 0, data = 0x0}, tsx = 0x0, prev_state = 
0, type = PJSIP_EVENT_UNKNOWN}, tx_msg = {tdata = 0x0}, tx_error = {tdata = 
0x0, tsx = 0x0}, rx_msg = {rdata = 0x0}, user = {user1 = 0x0, user2 = 0x0, 
user3 = 0x0, user4 = 0x0}}}

#5  0x7f31b69a74d7 in pjsip_evsub_send_request (sub=0x7f31600ffb68, 
tdata=tdata@entry=0x7f311c9567e8) at ../src/pjsip-simple/evsub.c:1378

status = 0

#6  0x7f314e52c086 in internal_pjsip_evsub_send_request 
(sub_tree=sub_tree@entry=0x7f3160077608, tdata=tdata@entry=0x7f311c9567e8) at 
res_pjsip_pubsub.c:1581

selector = {type = PJSIP_TPSELECTOR_NONE, u = {transport = 0x0, 
listener = 0x0, ptr = 0x0}}

#7  0x7f314e532afc in send_notify (tdata=, 
sub_tree=0x7f3160077608) at res_pjsip_pubsub.c:1727

res = 

evsub = 

tdata = 0x7f311c9567e8

#8  0x7f314e532afc in send_notify (sub_tree=sub_tree@entry=0x7f3160077608, 
force_full_state=force_full_state@entry=1) at res_pjsip_pubsub.c:2179

evsub = 

tdata = 0x7f311c9567e8

#9  0x7f314e532c02 in serialized_pubsub_on_server_timeout 
(userdata=0x7f3160077608) at res_pjsip_pubsub.c:3264

sub_tree = 0x7f3160077608

dlg = 0x7f317811feb8

#10 0x005ea3c3 in ast_taskprocessor_execute (tps=0x7f31601d9ab8) at 
taskprocessor.c:850

local = {local_data = 0x7f3120987700, data = 0x5f11a2 
}

t = 0x7f3175582430

size = 1

__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"

#11 0x005f35d4 in execute_tasks (data=0x7f31601d9ab8) at 
threadpool.c:1322

tps = 0x7f31601d9ab8

#12 0x005ea3c3 in ast_taskprocessor_execute (tps=0x1e23998) at 
taskprocessor.c:850

local = {local_data = 0x7f3120986c80, data = 0x1e22330}

t = 0x7f31b00067f0

size = 31597416

__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"

#13 0x005f1889 in threadpool_execute (pool=0x1e22388) at 
threadpool.c:351

__PRETTY_FUNCTION__ = "threadpool_execute"

#14 0x005f2f40 in worker_active (worker=0x7f31c0009cd8) at 
threadpool.c:1105

alive = 1

#15 0x005f2cf8 in worker_start (arg=0x7f31c0009cd8) at threadpool.c:1024

worker = 0x7f31c0009cd8

saved_state = (ZOMBIE | unknown: 32560)

__PRETTY_FUNCTION__ = "worker_start"

#16 0x005ff1d1 in dummy_start (data=0x7f31c00011c0) at utils.c:1235

__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
2796589904138404041, 139851786295935, 139848976987904, 507904, 507904, 
2796589904146792649, -2833544559795568439}, __mask_was_saved = 0}}, __pad = 
{0x7f3120986df0, 0x0, 0x7f3120987b68, 0x7f31d2898438 <__pthread_keys+344>}}

__cancel_routine = 0x451ba8 

__cancel_arg = 0x7f3120987700

__not_first_call = 0

ret = 0x7f31d1c778d8

a = {start_routine = 0x5f2c71 , data = 0x7f31c0009cd8, 
name = 0x7f31c0008480 "worker_start started at [ 1079] threadpool.c 
worker_thread_start()"}

#17 0x7f31d268661a in start_thread () at /lib64/libpthread.so.0

#18 0x7f31d19c259d in clone () at /lib64/libc.so.6


>From Gerrit I notice  that Richard Mudgett has a change to related to 
>presence, and wondered if this commit would resolve the above issue?


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

Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

[Ross Beer]

Asterisk Version: 13.9.1

OS/Distro: Fedora Server 23

unixODBC: 2.3.4 (Fedora Package Manager)

Threading: 0

Pooling: yes

ODBC Connector: 5.3.6 (MySQL Fedora Repository) [ANSI or Unicode]
Status: No Crash, but unixODBC locks


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Marek Červenka 

Sent: 01 June 2016 11:24
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

will be helpfull comparison table like this?
http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC
Asterisk Realtime ODBC - 
voip-info.org<http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC>
www.voip-info.org
asterisk version OS/Distro unixODBC threading pooling odbc-connector SQL server 
status 13.9.1 Linux/Centos 6 2.3.2 (backport fc20) 0 yes 5.1.5 distro MySQL 
5.1.73 distro random segfaults 13.9.1 Linux/Centos 6 2.3.4 (backport fc23)0 yes 
5.3.6




Dne 1.6.2016 v 7:04 Matt Fredrickson napsal(a):

Hey Ross,

At this time, we’re not thinking about reverting the ODBC change,
although we are actually working on an issue internally related to
that particular change.  If it looks like that there is an underlying
systemic issue that we are unable to resolve in a timely manner, it’s
quite possible that the change could be backed out.

So in essence, my thoughts are twofold:
1. Keep moving forward with ODBC changes - but make sure that we’ve
got testing in place to prove functionality.
2. If it all goes down and we’re playing whack a mole with ODBC bugs,
revert the changes until we can do some better testing.

Certified Asterisk goes through its own testing and vetting process
and changes in the branch are driven almost exclusively by certified
customers.  Right now, the 13.8 certified branch is going through the
initial testing process.  There is at least one open issue that we’ve
found so far related to the ODBC change that may or may not be related
to your crash, which is being worked on by a member of the Asterisk
development team at Digium.

Additionally, and completely separate from the certified testing and
release process, a deadlock in the ODBC code is highly concerning, and
if it looks like there are systemic issues related to the performance
improvement added, we will almost certainly look into those as well.

I might add that although Digium as a commercial entity is a large
contributor to the Asterisk project, the goal is for it to also be a
community project.  With that perspective, we also encourage community
members to find ways to contribute as well, whether it be via Digium’s
products and services, or helping by employing others that can
contribute to the project.  We desire and welcome any and all positive
participation.

Thanks *so* much again for the valuable feedback.  Like I said,
hopefully we’ll be able to get a few of these hickups addressed soon.

Best wishes,
Matthew Fredrickson

On Tue, May 31, 2016 at 11:01 AM, Ross Beer 
<mailto:ross.b...@outlook.com> wrote:


Hi All,

I've been looking into the changes made to res_odbc and the removal of
connection handling. I can see that this change has been murged into the
next release of Certified Asterisk. Would it be possible to regress this
change until a sutible solution to the locking is found?

Kind regards,

Ross




On Mon, May 30, 2016 at 8:43 AM -0700, "Joshua Colp" 
<mailto:jc...@digium.com>
wrote:

Ross Beer wrote:


Hi,


I'm having an issue with the latest asterisk verison 13.9.1 and SVN
MASTER:






There are currently around 9 locks held and no phones are able to
register. The system is using the latest unixODBC and
mysql-connector-odbc drivers. This has been working well up until
recently. However a change appears to have been made to the way
endpoints are authenticated. I'm exploring the possibility that this may
be a unixODBC issue however I would be great full if anyone could offer
any assistance?


A full backtrace[1] would be needed to see what is going on. You should
also file an issue and link it here.

[1]
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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

--
_
-- 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] URGENT - PJSIP Sorcery Locking

[Ross Beer]

Hi All,

I've been looking into the changes made to res_odbc and the removal of 
connection handling. I can see that this change has been murged into the next 
release of Certified Asterisk. Would it be possible to regress this change 
until a sutible solution to the locking is found?

Kind regards,

Ross




On Mon, May 30, 2016 at 8:43 AM -0700, "Joshua Colp" 
mailto:jc...@digium.com>> wrote:

Ross Beer wrote:
> Hi,
>
>
> I'm having an issue with the latest asterisk verison 13.9.1 and SVN MASTER:



>
> There are currently around 9 locks held and no phones are able to
> register. The system is using the latest unixODBC and
> mysql-connector-odbc drivers. This has been working well up until
> recently. However a change appears to have been made to the way
> endpoints are authenticated. I'm exploring the possibility that this may
> be a unixODBC issue however I would be great full if anyone could offer
> any assistance?

A full backtrace[1] would be needed to see what is going on. You should
also file an issue and link it here.

[1]
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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
-- 
_
-- 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] URGENT - PJSIP Sorcery Locking

[Ross Beer]

Hi Joshua,

Thank you for your reply, it is appreciated. 

I have created the issue:

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

I have also attached the core show locks and backtrack as requested.

I would be very grateful if you could provide assistance as I am unable to 
register any devices to the PBX.

Regards,

Ross


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 30 May 2016 16:42
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

Ross Beer wrote:
> Hi,
>
>
> I'm having an issue with the latest asterisk verison 13.9.1 and SVN MASTER:



>
> There are currently around 9 locks held and no phones are able to
> register. The system is using the latest unixODBC and
> mysql-connector-odbc drivers. This has been working well up until
> recently. However a change appears to have been made to the way
> endpoints are authenticated. I'm exploring the possibility that this may
> be a unixODBC issue however I would be great full if anyone could offer
> any assistance?

A full backtrace[1] would be needed to see what is going on. You should
also file an issue and link it here.

[1]
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

--
Joshua Colp
Digium, Inc. | Senior 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

-- 
_
-- 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] URGENT - PJSIP Sorcery Locking

[Ross Beer]

Hi,


I'm having an issue with the latest asterisk verison 13.9.1 and SVN MASTER:


===

=== 13.9.1

=== Currently Held Locks

===

===

===   (): 
 (times locked)

===

=== Thread ID: 0x7f88fc12b700 LWP:28315 (worker_start started at [ 
1077] threadpool.c worker_thread_start())

=== ---> Lock #0 (res_pjsip.c): RDLOCK 2243 ast_sip_identify_endpoint 
&((&endpoint_identifiers))->lock 0x7f88edabae50 (1)

main/backtrace.c:59 __ast_bt_get_addresses() (0x468532+1D)

main/lock.c:866 __ast_rwlock_rdlock() (0x53e19e+BA)

res/res_pjsip.c:2244 ast_sip_identify_endpoint() (0x7f88ed891f10+2D)

res_pjsip/pjsip_distributor.c:382 endpoint_lookup()

:0 pjsip_endpt_process_rx_data() (0x7f88fe128d10+107)

res_pjsip/pjsip_distributor.c:461 distribute()

main/taskprocessor.c:852 ast_taskprocessor_execute() (0x5ed8b3+110)

main/threadpool.c:1320 execute_tasks()

main/taskprocessor.c:852 ast_taskprocessor_execute() (0x5ed8b3+110)

main/threadpool.c:351 threadpool_execute()

main/threadpool.c:1103 worker_active()

main/threadpool.c:1024 worker_start()

main/utils.c:1235 dummy_start()

pthread_create.c:0 start_thread()

:0 __clone() (0x7f897d36c530+6D)

=== ---> Lock #1 (sorcery.c): RDLOCK 1838 ast_sorcery_retrieve_by_id 
&(&object_type->wizards)->lock 0x1531a20 (1)

main/backtrace.c:59 __ast_bt_get_addresses() (0x468532+1D)

main/lock.c:866 __ast_rwlock_rdlock() (0x53e19e+BA)

main/sorcery.c:1839 ast_sorcery_retrieve_by_id() (0x5cadb8+8B)

res/res_pjsip_endpoint_identifier_user.c:74 username_identify()

res/res_pjsip.c:2246 ast_sip_identify_endpoint() (0x7f88ed891f10+52)

res_pjsip/pjsip_distributor.c:382 endpoint_lookup()

:0 pjsip_endpt_process_rx_data() (0x7f88fe128d10+107)

res_pjsip/pjsip_distributor.c:461 distribute()

main/taskprocessor.c:852 ast_taskprocessor_execute() (0x5ed8b3+110)

main/threadpool.c:1320 execute_tasks()

main/taskprocessor.c:852 ast_taskprocessor_execute() (0x5ed8b3+110)

main/threadpool.c:351 threadpool_execute()

main/threadpool.c:1103 worker_active()

main/threadpool.c:1024 worker_start()

main/utils.c:1235 dummy_start()

pthread_create.c:0 start_thread()

:0 __clone() (0x7f897d36c530+6D)


There are currently around 9 locks held and no phones are able to register. The 
system is using the latest unixODBC and mysql-connector-odbc drivers. This has 
been working well up until recently. However a change appears to have been made 
to the way endpoints are authenticated. I'm exploring the possibility that this 
may be a unixODBC issue however I would be great full if anyone could offer any 
assistance?

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] Swamped with MWI Notify parse errors

[Ross Beer]

Hi George,


The change was rolled out to additional servers, which have different types of 
SIP clients. It looks like one client in particular doesn't like this format.


Simple fix to re-order the NOTIFY packed.


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of George Joseph 

Sent: 26 May 2016 17:35
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Swamped with MWI Notify parse errors

Ross,

Is this issue just showing up?  Just thinking of what might have triggered the 
issue now given that you've been testing the Message-Account stuff for a while. 
 New phones in the mix maybe?


On Thu, May 26, 2016 at 9:59 AM, Joshua Colp 
mailto:jc...@digium.com>> wrote:
Ross Beer wrote:
Ok,


The issue is that clients are unable to parse the MWI NOTIFY message due
to the order of the body.


Please see my suggestion on the ticket ASTERISK-26065
<https://issues.asterisk.org/jira/browse/ASTERISK-26065>

I've gone ahead and triaged the issue.

Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com> & 
www.asterisk.org<http://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



--
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com<http://www.digium.com/> & 
www.asterisk.org<http://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

Re: [asterisk-dev] Swamped with MWI Notify parse errors

[Ross Beer]

Ok,


The issue is that clients are unable to parse the MWI NOTIFY message due to the 
order of the body.


Please see my suggestion on the ticket 
ASTERISK-26065<https://issues.asterisk.org/jira/browse/ASTERISK-26065>


Regards,


Ross



From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Ross Beer 

Sent: 26 May 2016 11:02
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Swamped with MWI Notify parse errors


Hi All,


I'm currently being swamped with MWI Notify parse errors when Asterisk is 
sending notify messages to phones. The CLI is showing the following:


SIP/2.0 400 ../../rutil/ParseBuffer.cxx:669, Parse failed Expected a digit, 
got: sip:1571@:5060

 in context: Contents

Messages-Waiting: no

Voice-Message: 0/0 (0/0)

Message-Account: sip:1571@:5060[CRLF]

 ^[CRLF]


Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bKPjb11bdc9b-030c-453b-8e0d-070a2e01ca6a

To: @;rinstance=784a071431a881b7>;tag=3a20d77e

From: @>;tag=fbdc56c4-d260-43ce-b0ce-9333e1151602

Call-ID: ed88eae3-2daf-4b6e-b5a1-572783bce0b7

CSeq: 8818 NOTIFY

Accept-Language: en

Content-Length: 0


To me this looks like the transport layer rejecting the message before it's 
being sent. For some reason the other lines of the message do not show the 
[CRLF] even though I can see the "\r\n" in the code.


Can you please help?


I've raised an issue 
ASTERISK-26065<https://issues.asterisk.org/jira/browse/ASTERISK-26065>


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

[asterisk-dev] Swamped with MWI Notify parse errors

[Ross Beer]

Hi All,


I'm currently being swamped with MWI Notify parse errors when Asterisk is 
sending notify messages to phones. The CLI is showing the following:


SIP/2.0 400 ../../rutil/ParseBuffer.cxx:669, Parse failed Expected a digit, 
got: sip:1571@:5060

 in context: Contents

Messages-Waiting: no

Voice-Message: 0/0 (0/0)

Message-Account: sip:1571@:5060[CRLF]

 ^[CRLF]


Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bKPjb11bdc9b-030c-453b-8e0d-070a2e01ca6a

To: @;rinstance=784a071431a881b7>;tag=3a20d77e

From: @>;tag=fbdc56c4-d260-43ce-b0ce-9333e1151602

Call-ID: ed88eae3-2daf-4b6e-b5a1-572783bce0b7

CSeq: 8818 NOTIFY

Accept-Language: en

Content-Length: 0


To me this looks like the transport layer rejecting the message before it's 
being sent. For some reason the other lines of the message do not show the 
[CRLF] even though I can see the "\r\n" in the code.


Can you please help?


I've raised an issue 
ASTERISK-26065


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

[asterisk-dev] Possible PJSIP Issue

[Ross Beer]

Hi All,

I think I've found an issue in PJSIP which may require the bundled PJSIP to be 
updated. This morning I had the following segfault which I believe to be fixed 
in PJPROJECT commit (https://trac.pjsip.org/repos/changeset/5316). Can you 
please confirm if this looks to be related?

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.

Program terminated with signal 11, Segmentation fault.

#0  0x2ad124e77d1d in pjsip_ua_unregister_dlg (ua=0x2ad12508bc60, 
dlg=0x2ad4996c3f58) at ../src/pjsip/sip_ua_layer.c:378

378d = dlg_set->dlg_list.next;

#0  0x2ad124e77d1d in pjsip_ua_unregister_dlg (ua=0x2ad12508bc60, 
dlg=0x2ad4996c3f58) at ../src/pjsip/sip_ua_layer.c:378

dlg_set = 0x0

d = 0x2ad1a80ee188

#1  0x2ad124e7567a in unregister_and_destroy_dialog (dlg=0x2ad4996c3f58, 
unlock_mutex=1) at ../src/pjsip/sip_dialog.c:791

status = 0

#2  0x2ad124e758d8 in pjsip_dlg_dec_lock (dlg=0x2ad4996c3f58) at 
../src/pjsip/sip_dialog.c:941

No locals.

#3  0x2ad124e75139 in create_uas_dialog (ua=0x2ad12508bc60, 
rdata=0x2ad1a80ec378, contact=0x2acffc9c2980, inc_lock=1, p_dlg=0x2acffc9c2998) 
at ../src/pjsip/sip_dialog.c:563

status = 70015

pos = 0x0

contact_hdr = 0x2ad4ab49f220

rr = 0x0

tsx = 0x0

tmp = {ptr = 0x2ad4b16ac6c0 ";user=phone>", slen = 
46}

len = 46

dlg = 0x2ad4996c3f58

#4  0x2ad124e75195 in pjsip_dlg_create_uas_and_inc_lock (ua=0x2ad12508bc60, 
rdata=0x2ad1a80ec378, contact=0x2acffc9c2980, p_dlg=0x2acffc9c2998) at 
../src/pjsip/sip_dialog.c:595

No locals.

#5  0x2ad12c87053d in ast_sip_create_dialog_uas (endpoint=0x2e06960, 
rdata=0x2ad1a80ec378, status=0x2acffc9c2a00) at res_pjsip.c:2895

dlg = 0x2acffc9c2a10

contact = {ptr = 0x2ad4b16ac4c0 "", slen = 24}

type = PJSIP_TRANSPORT_UDP

selector = {type = PJSIP_TPSELECTOR_TRANSPORT, u = {transport = 
0x2dc39b8, listener = 0x2dc39b8, ptr = 0x2dc39b8}}

transport = 0x2dc39b8

__PRETTY_FUNCTION__ = "ast_sip_create_dialog_uas"

#6  0x2ad124289d48 in pre_session_setup (rdata=0x2ad1a80ec378, 
endpoint=0x2e06960) at res_pjsip_session.c:1977

tdata = 0x0

dlg = 0x2ad1a80ec378

inv_session = 0x2ad12c88d75f

options = 3

dlg_status = -56874448

#7  0x2ad12428a4c0 in handle_new_invite_request (rdata=0x2ad1a80ec378) at 
res_pjsip_session.c:2139

endpoint = 0x2e06960

tdata = 0x0

inv_session = 0x0

session = 0x2ad12caa6870

invite = 0x2ad12c895fe0

#8  0x2ad12428a793 in session_on_rx_request (rdata=0x2ad1a80ec378) at 
res_pjsip_session.c:2225

handled = 1

dlg = 0x0

inv_session = 0x2ad1a80ec378

__PRETTY_FUNCTION__ = "session_on_rx_request"

#9  0x2ad124e58ee1 in pjsip_endpt_process_rx_data (endpt=0x18afd38, 
rdata=0x2ad1a80ec378, p=0x2ad12caa7f80, p_handled=0x2acffc9c2b64) at 
../src/pjsip/sip_endpoint.c:886

msg = 0x2ad1a80ed670

def_prm = {start_prio = 3247671623, start_mod = 0x6e1beb, 
idx_after_start = 4238093200, silent = 10959}

mod = 0x2ad1244909a0

handled = 0

i = 1

status = 0

#10 0x2ad12c88d6a0 in distribute (data=0x2ad1a80ec378) at 
res_pjsip/pjsip_distributor.c:637

param = {start_prio = 0, start_mod = 0x2ad12caa7de0, idx_after_start = 
1, silent = 0}

handled = 0

rdata = 0x2ad1a80ec378

is_request = 1

is_ack = 0

endpoint = 0x0

#11 0x005ec1df in ast_taskprocessor_execute (tps=0x18adfa8) at 
taskprocessor.c:850

local = {local_data = 0x2acffc9c39c0, data = 0x5ff34a}

t = 0x2ad1a80b58a0

size = 9883536

__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"

#12 0x005f52da in execute_tasks (data=0x18adfa8) at threadpool.c:1320

tps = 0x18adfa8

#13 0x005ec1df in ast_taskprocessor_execute (tps=0x18ad918) at 
taskprocessor.c:850

local = {local_data = 0x57457095, data = 0x0}

t = 0x2ad1a80a4e10

size = 0

__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"

#14 0x005f35e9 in threadpool_execute (pool=0x18ab108) at 
threadpool.c:351

__PRETTY_FUNCTION__ = "threadpool_execute"

#15 0x005f4bf8 in worker_active (worker=0x2ad134001d28) at 
threadpool.c:1103

alive = 0

#16 0x005f49a8 in worker_start (arg=0x2ad134001d28) at threadpool.c:1023

worker = 0x2ad134001d28

__PRETTY_FUNCTION__ = "worker_start"

#17 0x00600c12 in dummy_start (data=0x2ad134005820) at utils.c:1235

__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
8464671100452439244, 47077928585856, 47072784693696, 47092863030288, 3, 
8464671100410496204, 2370991808755893452}, __mask_was_saved = 0}}, __pad = 
{0x2acffc9c2e30, 0x0, 0xfc9c3a10, 0x0}}

__cancel_routine = 0x451391 

__cancel_arg = 0x2acffc9c3700

 

Re: [asterisk-dev] Segfault Asterisk 13 SVN

[Ross Beer]

Hi Joshua,

To confirm its currently built with the following:

./configure CFLAGS="-DNDEBUG" --prefix=/usr --libdir=/usr/lib64 --enable-epoll 
--with-external-srtp --enable-shared --disable-video --disable-sound 
--disable-opencore-amr

Should the DNDEBUG be removed and replaced with "-g"?

Kind regards,

Ross


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Joshua Colp 

Sent: 20 May 2016 11:37
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Segfault Asterisk 13 SVN

Ross Beer wrote:
> Hi All,
>
> I'm currently facing a regular issue with Asterisk crashing with PJSIP
> commit5281:

It could be in our usage of it causing the problem. If you recompile
PJSIP with debug symbols (it can be done by passing CFLAGS="-g" to the
configure script the backtrace will be more useful for PJSIP. Then you
can file an issue on the issue tracker[1] and we can determine how best
to proceed.

[1] https://issues.asterisk.org/jira

--
Joshua Colp
Digium, Inc. | Senior 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

-- 
_
-- 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] Segfault Asterisk 13 SVN

[Ross Beer]

Hi All,

I'm currently facing a regular issue with Asterisk crashing with PJSIP commit 
5281:


Program terminated with signal 11, Segmentation fault.

#0  0x2b53f67eba0d in pj_pool_alloc () from /usr/lib64/libpj.so.2

#0  0x2b53f67eba0d in pj_pool_alloc () from /usr/lib64/libpj.so.2

No symbol table info available.

#1  0x2b53f67eba77 in pj_pool_calloc () from /usr/lib64/libpj.so.2

No symbol table info available.

#2  0x2b53f54b742d in pj_pool_zalloc () from /usr/lib64/libpjmedia.so.2

No symbol table info available.

#3  0x2b53f54b9f92 in pjmedia_sdp_session_clone () from 
/usr/lib64/libpjmedia.so.2

No symbol table info available.

#4  0x2b53f54bb8f9 in pjmedia_sdp_neg_send_local_offer () from 
/usr/lib64/libpjmedia.so.2

No symbol table info available.

#5  0x2b53f4814b94 in timer_cb () from /usr/lib64/libpjsip-ua.so.2

No symbol table info available.

#6  0x2b53f67f7d2d in pj_timer_heap_poll () from /usr/lib64/libpj.so.2

No symbol table info available.

#7  0x2b53f4c4ab9c in pjsip_endpt_handle_events2 () from 
/usr/lib64/libpjsip.so.2

No symbol table info available.

#8  0x2b53f4c4accf in pjsip_endpt_handle_events () from 
/usr/lib64/libpjsip.so.2

No symbol table info available.

#9  0x2b53fc82514c in monitor_thread_exec (endpt=0x0) at res_pjsip.c:3775

delay = {sec = 0, msec = 10}

#10 0x2b53f67e288f in thread_main () from /usr/lib64/libpj.so.2

No symbol table info available.

#11 0x2b527bd14aa1 in start_thread (arg=0x2b5444703700) at 
pthread_create.c:301

__res = 

pd = 0x2b5444703700

now = 

unwind_buf = {cancel_jmp_buf = {{jmp_buf = {47640925452032, 
-6911363940106690129, 140724477894016, 47640925452736, 0, 3, 
-667254036973542993, -670736453341339217}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

not_first_call = 

pagesize_m1 = 

sp = 

freesize = 

#12 0x2b527cba693d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

No locals.


Is this a PJSIP bug or Asterisk?


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] Asterisk now available with bundled pjproject!

[Ross Beer]

 
Package matching libsrtp-devel-1.4.4-10.20101004cvs.el7.x86_64 already 
installed.
 
pjproject builds correct with the following:
 
./configure CFLAGS="-DNDEBUG" --prefix=/usr --libdir=/usr/lib64 --enable-epoll 
--enable-shared --disable-video --disable-sound --disable-opencore-amr
 

 
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 09:09:30 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 8:47 AM, Ross Beer  wrote:



After running install_prereq I get the following error:
 
[GENERATE] libasteriskpj.exports
   [LD] libasteriskpj.o -> libasteriskpj.so.2
   [LN] libasteriskpj.so.2 -> libasteriskpj.so
   [LD] abstract_jb.o acl.o adsi.o alaw.o aoc.o app.o ast_expr2.o ast_expr2f.o 
asterisk.o astfd.o astmm.o astobj2.o astobj2_container.o astobj2_hash.o 
astobj2_rbtree.o audiohook.o autochan.o autoservice.o backtrace.o bridge.o 
bridge_after.o bridge_basic.o bridge_channel.o bridge_roles.o bucket.o 
callerid.o ccss.o cdr.o cel.o channel.o channel_internal_api.o chanvars.o cli.o 
codec.o codec_builtin.o config.o config_options.o core_local.o core_unreal.o 
crypt.o data.o datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o 
endpoints.o enum.o event.o features.o features_config.o file.o fixedjitterbuf.o 
format.o format_cache.o format_cap.o format_compatibility.o frame.o framehook.o 
fskmodem.o global_datastores.o hashtab.o heap.o http.o image.o indications.o 
io.o jitterbuf.o json.o loader.o lock.o logger.o manager.o manager_bridges.o 
manager_channels.o manager_endpoints.o manager_mwi.o manager_system.o 
max_forwards.o md5.o media_index.o message.o mixmonitor.o named_acl.o netsock.o 
netsock2.o optional_api.o parking.o pbx.o pbx_app.o pbx_builtins.o 
pbx_functions.o pbx_hangup_handler.o pbx_switch.o pbx_timing.o pbx_variables.o 
pickup.o plc.o poll.o presencestate.o privacy.o rtp_engine.o say.o sched.o 
sdp_srtp.o security_events.o sem.o sha1.o sip_api.o slinfactory.o smoother.o 
sorcery.o sounds_index.o srv.o stasis.o stasis_bridges.o stasis_cache.o 
stasis_cache_pattern.o stasis_channels.o stasis_endpoints.o stasis_message.o 
stasis_message_router.o stasis_system.o stdtime/localtime.o strcompat.o 
strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o term.o test.o 
threadpool.o threadstorage.o timing.o translate.o udptl.o ulaw.o uri.o utils.o 
uuid.o version.o xml.o xmldoc.o   -> asterisk
./libasteriskpj.so: undefined reference to `srtp_deinit'
collect2: error: ld returned 1 exit status
make[1]: *** [asterisk] Error 1
make: *** [main] Error 2


​Ok, that's weird.  I take it you have libsrtp-devel installed (install_prereq 
should have done it)?  What version?Can you build ​pjproject from source 
normally?  When you do, do you use --with-external-srtp?



  
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 07:37:44 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 5:41 AM, Ross Beer  wrote:



Hi,
 
I just attempted to install with the bundled pjproject however the following 
error stopped the build:
 
Generating embedded module rules ...
   [CC] astdb2sqlite3.c -> astdb2sqlite3.o
   [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
   [CC] astdb2bdb.c -> astdb2bdb.o
   [LD] astdb2bdb.o db1-ast/libdb1.a -> astdb2bdb
[pjproject]  Making dependencies
[pjproject]  Compiling libs
[pjproject]  Generating symbols
[pjproject]  Compiling apps
[pjproject]  Compiling python bindings
make[2]: *** [source/pjsip-apps/src/python/build/_pjsua.so] Error 1
make[1]: *** [pjproject] Error 2
make: *** [third-party] Error 2

​I'll bet you don't have the python development libraries installed.  The 
install_prereq script was updated to include python-devel or python-dev 
depending on the distribution.​

Kind regards,
 
ROss
 
From: george.jos...@fairview5.com
Date: Mon, 7 Mar 2016 12:28:23 -0700
To: asterisk-dev@lists.digium.com; asterisk-us...@lists.digium.com
Subject: [asterisk-dev] Asterisk now available with bundled pjproject!

The current Asterisk 13 and master git branches have a new feature that will be 
included in 13.8.0:  The ability to compile and run Asterisk with a bundled 
version of pjproject.
​​
Why would you want to do this?  Several reasons:
Predictability:  When built with the ​bundled pjproject, you're always certain 
of the version you're running against, no matter where it's installed.
Scalability:  The default pjproject configuration is optimized for client 
applications. The bundled version's configuration is optimized for server use.
Usability:  Several feature patches, which have been submitted upstream to 
pjproject but not yet released, have been included in the bundled version.
Safety:  If a security or critical issue is identified in pjproject, it can be 
patched and made available with a new release of 

Re: [asterisk-dev] Asterisk now available with bundled pjproject!

[Ross Beer]

Hi,
 
I just attempted to install with the bundled pjproject however the following 
error stopped the build:
 
Generating embedded module rules ...
   [CC] astdb2sqlite3.c -> astdb2sqlite3.o
   [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
   [CC] astdb2bdb.c -> astdb2bdb.o
   [LD] astdb2bdb.o db1-ast/libdb1.a -> astdb2bdb
[pjproject]  Making dependencies
[pjproject]  Compiling libs
[pjproject]  Generating symbols
[pjproject]  Compiling apps
[pjproject]  Compiling python bindings
make[2]: *** [source/pjsip-apps/src/python/build/_pjsua.so] Error 1
make[1]: *** [pjproject] Error 2
make: *** [third-party] Error 2

Kind regards,
 
ROss
 
From: george.jos...@fairview5.com
Date: Mon, 7 Mar 2016 12:28:23 -0700
To: asterisk-dev@lists.digium.com; asterisk-us...@lists.digium.com
Subject: [asterisk-dev] Asterisk now available with bundled pjproject!

The current Asterisk 13 and master git branches have a new feature that will be 
included in 13.8.0:  The ability to compile and run Asterisk with a bundled 
version of pjproject.
​​
Why would you want to do this?  Several reasons:
Predictability:  When built with the ​bundled pjproject, you're always certain 
of the version you're running against, no matter where it's installed.
Scalability:  The default pjproject configuration is optimized for client 
applications. The bundled version's configuration is optimized for server use.
Usability:  Several feature patches, which have been submitted upstream to 
pjproject but not yet released, have been included in the bundled version.
Safety:  If a security or critical issue is identified in pjproject, it can be 
patched and made available with a new release of Asterisk instead of ​having to 
​waiting for a new release of pjproject​​.Maintainability:  You don't need to 
build and install separate packages.
Supportability:  When asking others for help, there's no question about which 
version of pjproject you're using and what options it was compiled with.
Compatibility:  This is especially important from a development perspective 
because it means we can be sure that new pjproject APIs that have been 
introduced​,​ or old ones that have been deprecated​,​ are handled and tested 
appropriately in Asterisk.
Reliability:  You can be sure that Asterisk was tested against the bundled 
version.

So now that you're sold, here's how you use it:

All you have to do is add the "--with-pjproject-bundled" option to your 
./configure command line and remove any other "--with-pjproject" option you may 
have specified.  The configure and make processes will download the correct 
version of pjproject, patch it, configure it, build it and finally link 
Asterisk to it statically.  No changes in runtime configuration are required.

Still not sold?  The default behavior hasn't changed so as long as you haven't 
specified "--with-pjproject-bundled", your build and deploy process remains as 
is.

PLEASE TRY THIS!!  I'd love some feedback BEFORE 13.8.0 is released.


-- 
_
-- 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] Asterisk now available with bundled pjproject!

[Ross Beer]

Hi,
 
This is now working as expected, however the build failed as the 'bzip2' and 
'patch' package needed to be installed. Could this be added to the 
'install_prereq' script to negate the issue?
 
Regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 14:27:10 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 10:25 AM, George Joseph  
wrote:


On Wed, Mar 16, 2016 at 9:30 AM, Ross Beer  wrote:



 
Package matching libsrtp-devel-1.4.4-10.20101004cvs.el7.x86_64 already 
installed.
 
pjproject builds correct with the following:
 
./configure CFLAGS="-DNDEBUG" --prefix=/usr --libdir=/usr/lib64 --enable-epoll 
--enable-shared --disable-video --disable-sound --disable-opencore-amr
 

​You're compiling with pjproject's internal libsrtp implementation.  Try with 
--with-external-srtp and see what happens.libsrtp-devel in Fedora is already at 
1.5.4 so maybe it's a version thing.   There was a ticket open with pjproject 
for this exact problem but it was implemented 2 years ago.  Maybe it's not 
quite right.  I'll check.

​I just tested on my CentOS7 VM with the same version of libsrtp and didn't 
have any problems.  Maybe try a distclean and reconfigure?
  
 
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 09:09:30 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 8:47 AM, Ross Beer  wrote:



After running install_prereq I get the following error:
 
[GENERATE] libasteriskpj.exports
   [LD] libasteriskpj.o -> libasteriskpj.so.2
   [LN] libasteriskpj.so.2 -> libasteriskpj.so
   [LD] abstract_jb.o acl.o adsi.o alaw.o aoc.o app.o ast_expr2.o ast_expr2f.o 
asterisk.o astfd.o astmm.o astobj2.o astobj2_container.o astobj2_hash.o 
astobj2_rbtree.o audiohook.o autochan.o autoservice.o backtrace.o bridge.o 
bridge_after.o bridge_basic.o bridge_channel.o bridge_roles.o bucket.o 
callerid.o ccss.o cdr.o cel.o channel.o channel_internal_api.o chanvars.o cli.o 
codec.o codec_builtin.o config.o config_options.o core_local.o core_unreal.o 
crypt.o data.o datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o 
endpoints.o enum.o event.o features.o features_config.o file.o fixedjitterbuf.o 
format.o format_cache.o format_cap.o format_compatibility.o frame.o framehook.o 
fskmodem.o global_datastores.o hashtab.o heap.o http.o image.o indications.o 
io.o jitterbuf.o json.o loader.o lock.o logger.o manager.o manager_bridges.o 
manager_channels.o manager_endpoints.o manager_mwi.o manager_system.o 
max_forwards.o md5.o media_index.o message.o mixmonitor.o named_acl.o netsock.o 
netsock2.o optional_api.o parking.o pbx.o pbx_app.o pbx_builtins.o 
pbx_functions.o pbx_hangup_handler.o pbx_switch.o pbx_timing.o pbx_variables.o 
pickup.o plc.o poll.o presencestate.o privacy.o rtp_engine.o say.o sched.o 
sdp_srtp.o security_events.o sem.o sha1.o sip_api.o slinfactory.o smoother.o 
sorcery.o sounds_index.o srv.o stasis.o stasis_bridges.o stasis_cache.o 
stasis_cache_pattern.o stasis_channels.o stasis_endpoints.o stasis_message.o 
stasis_message_router.o stasis_system.o stdtime/localtime.o strcompat.o 
strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o term.o test.o 
threadpool.o threadstorage.o timing.o translate.o udptl.o ulaw.o uri.o utils.o 
uuid.o version.o xml.o xmldoc.o   -> asterisk
./libasteriskpj.so: undefined reference to `srtp_deinit'
collect2: error: ld returned 1 exit status
make[1]: *** [asterisk] Error 1
make: *** [main] Error 2


​Ok, that's weird.  I take it you have libsrtp-devel installed (install_prereq 
should have done it)?  What version?Can you build ​pjproject from source 
normally?  When you do, do you use --with-external-srtp?



  
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 07:37:44 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 5:41 AM, Ross Beer  wrote:



Hi,
 
I just attempted to install with the bundled pjproject however the following 
error stopped the build:
 
Generating embedded module rules ...
   [CC] astdb2sqlite3.c -> astdb2sqlite3.o
   [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
   [CC] astdb2bdb.c -> astdb2bdb.o
   [LD] astdb2bdb.o db1-ast/libdb1.a -> astdb2bdb
[pjproject]  Making dependencies
[pjproject]  Compiling libs
[pjproject]  Generating symbols
[pjproject]  Compiling apps
[pjproject]  Compiling python bindings
make[2]: *** [source/pjsip-apps/src/python/build/_pjsua.so] Error 1
make[1]: *** [pjproject] Error 2
make: *** [third-party] Error 2

​I'll bet you don't have the python development libraries installed.  The 
install_prereq script was updated to include python-devel or python-dev 
depending on the distribution.​

Kind regards,
 
ROss
 
Fro

Re: [asterisk-dev] Asterisk now available with bundled pjproject!

[Ross Beer]

After running install_prereq I get the following error:
 
[GENERATE] libasteriskpj.exports
   [LD] libasteriskpj.o -> libasteriskpj.so.2
   [LN] libasteriskpj.so.2 -> libasteriskpj.so
   [LD] abstract_jb.o acl.o adsi.o alaw.o aoc.o app.o ast_expr2.o ast_expr2f.o 
asterisk.o astfd.o astmm.o astobj2.o astobj2_container.o astobj2_hash.o 
astobj2_rbtree.o audiohook.o autochan.o autoservice.o backtrace.o bridge.o 
bridge_after.o bridge_basic.o bridge_channel.o bridge_roles.o bucket.o 
callerid.o ccss.o cdr.o cel.o channel.o channel_internal_api.o chanvars.o cli.o 
codec.o codec_builtin.o config.o config_options.o core_local.o core_unreal.o 
crypt.o data.o datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o 
endpoints.o enum.o event.o features.o features_config.o file.o fixedjitterbuf.o 
format.o format_cache.o format_cap.o format_compatibility.o frame.o framehook.o 
fskmodem.o global_datastores.o hashtab.o heap.o http.o image.o indications.o 
io.o jitterbuf.o json.o loader.o lock.o logger.o manager.o manager_bridges.o 
manager_channels.o manager_endpoints.o manager_mwi.o manager_system.o 
max_forwards.o md5.o media_index.o message.o mixmonitor.o named_acl.o netsock.o 
netsock2.o optional_api.o parking.o pbx.o pbx_app.o pbx_builtins.o 
pbx_functions.o pbx_hangup_handler.o pbx_switch.o pbx_timing.o pbx_variables.o 
pickup.o plc.o poll.o presencestate.o privacy.o rtp_engine.o say.o sched.o 
sdp_srtp.o security_events.o sem.o sha1.o sip_api.o slinfactory.o smoother.o 
sorcery.o sounds_index.o srv.o stasis.o stasis_bridges.o stasis_cache.o 
stasis_cache_pattern.o stasis_channels.o stasis_endpoints.o stasis_message.o 
stasis_message_router.o stasis_system.o stdtime/localtime.o strcompat.o 
strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o term.o test.o 
threadpool.o threadstorage.o timing.o translate.o udptl.o ulaw.o uri.o utils.o 
uuid.o version.o xml.o xmldoc.o   -> asterisk
./libasteriskpj.so: undefined reference to `srtp_deinit'
collect2: error: ld returned 1 exit status
make[1]: *** [asterisk] Error 1
make: *** [main] Error 2

 
From: george.jos...@fairview5.com
Date: Wed, 16 Mar 2016 07:37:44 -0600
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk now available with bundled pjproject!



On Wed, Mar 16, 2016 at 5:41 AM, Ross Beer  wrote:



Hi,
 
I just attempted to install with the bundled pjproject however the following 
error stopped the build:
 
Generating embedded module rules ...
   [CC] astdb2sqlite3.c -> astdb2sqlite3.o
   [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
   [CC] astdb2bdb.c -> astdb2bdb.o
   [LD] astdb2bdb.o db1-ast/libdb1.a -> astdb2bdb
[pjproject]  Making dependencies
[pjproject]  Compiling libs
[pjproject]  Generating symbols
[pjproject]  Compiling apps
[pjproject]  Compiling python bindings
make[2]: *** [source/pjsip-apps/src/python/build/_pjsua.so] Error 1
make[1]: *** [pjproject] Error 2
make: *** [third-party] Error 2

​I'll bet you don't have the python development libraries installed.  The 
install_prereq script was updated to include python-devel or python-dev 
depending on the distribution.​

Kind regards,
 
ROss
 
From: george.jos...@fairview5.com
Date: Mon, 7 Mar 2016 12:28:23 -0700
To: asterisk-dev@lists.digium.com; asterisk-us...@lists.digium.com
Subject: [asterisk-dev] Asterisk now available with bundled pjproject!

The current Asterisk 13 and master git branches have a new feature that will be 
included in 13.8.0:  The ability to compile and run Asterisk with a bundled 
version of pjproject.
​​
Why would you want to do this?  Several reasons:
Predictability:  When built with the ​bundled pjproject, you're always certain 
of the version you're running against, no matter where it's installed.
Scalability:  The default pjproject configuration is optimized for client 
applications. The bundled version's configuration is optimized for server use.
Usability:  Several feature patches, which have been submitted upstream to 
pjproject but not yet released, have been included in the bundled version.
Safety:  If a security or critical issue is identified in pjproject, it can be 
patched and made available with a new release of Asterisk instead of ​having to 
​waiting for a new release of pjproject​​.Maintainability:  You don't need to 
build and install separate packages.
Supportability:  When asking others for help, there's no question about which 
version of pjproject you're using and what options it was compiled with.
Compatibility:  This is especially important from a development perspective 
because it means we can be sure that new pjproject APIs that have been 
introduced​,​ or old ones that have been deprecated​,​ are handled and tested 
appropriately in Asterisk.
Reliability:  You can be sure that Asterisk was tested against the bundled 
version.

So now that you're sold, here's how you use it:

All you have to do is add the "--with-pjproject-bu

Re: [asterisk-dev] CDR billsec Set To 0 When disposition = ANSWERED

[Ross Beer]

Looking at this, it looks like only the 'Local' channel doesn't have the value 
set, however other CDRs do.
 
The Local channel is using the /n option so that it is not optimised.
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 15 Mar 2016 14:51:16 +
Subject: [asterisk-dev] CDR billsec Set To 0 When disposition = ANSWERED




 Hi,
 
Have there been any changed to the trunk since the release of Asterisk 13.7.2 
that would cause the billsec of a CDR to be set to 0 for an answered call?
 
The example I have been working with is a call to a phone that forwards a call, 
a local channel is Dialled and answered. The resulting CDR is a duration set to 
12, disposition set to 'ANSWRED' and billsec set to 0, which is incorrect.
 
Can someone please confirm the issue before I raise a ticket?
 
Thanks,
 
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
  -- 
_
-- 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] CDR billsec Set To 0 When disposition = ANSWERED

[Ross Beer]

 Hi,
 
Have there been any changed to the trunk since the release of Asterisk 13.7.2 
that would cause the billsec of a CDR to be set to 0 for an answered call?
 
The example I have been working with is a call to a phone that forwards a call, 
a local channel is Dialled and answered. The resulting CDR is a duration set to 
12, disposition set to 'ANSWRED' and billsec set to 0, which is incorrect.
 
Can someone please confirm the issue before I raise a ticket?
 
Thanks,
 
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] Endpoint matching on Username

[Ross Beer]

George,
 
I've raise the issue under 
https://issues.asterisk.org/jira/browse/ASTERISK-25835
 
Thank you,
 
Ross
 
From: george.jos...@fairview5.com
Date: Mon, 7 Mar 2016 12:37:39 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Endpoint matching on Username



On Mon, Mar 7, 2016 at 12:21 PM, Joshua Colp  wrote:
Ross Beer wrote:


Hi,



Is there a way Asterisk 13 PJSIP can authenticate a call based on the

username passed in the 'Username' section of an auth request in the same

way chan_sip can?



At the moment the based on the 'es_pjsip_endpoint_identifier_user'

module it pulls the username from the 'From' header. This is failing as

the invite contains the users Caller ID instead of the username.



Have I missed something or does an extra module need to be produced to

resolve this?




No existing endpoint identifier supports this, additional functionality would 
need to be written to do it.



​Ross: ​I've been messing about in those modules lately so open a Jira issue.  
I might be able knock this one out.

 


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

[asterisk-dev] Endpoint matching on Username

[Ross Beer]

 Hi,
 
Is there a way Asterisk 13 PJSIP can authenticate a call based on the username 
passed in the 'Username' section of an auth request in the same way chan_sip 
can?
 
At the moment the based on the 'es_pjsip_endpoint_identifier_user' module it 
pulls the username from the 'From' header. This is failing as the invite 
contains the users Caller ID instead of the username. 
 
Have I missed something or does an extra module need to be produced to resolve 
this?
 
Thanks,
 
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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
I've just rolled back to 13.7.2 and the following modules are in the latest git 
repository and not in 13.7.2:
 
res_pjproject.so
res_odbc_transaction.so
res_pjsip_history.so
 
Not sure if any of these would make a difference to the load time?
 
Regards,
 
Ross
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Wed, 2 Mar 2016 18:04:15 +
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




Hi George,
 
I have commented out those lines and it hasn't improved the load times, its 
still taking 15 mins. It has improved it a little.
 
Regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Wed, 2 Mar 2016 08:19:01 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer  wrote:



Hi George,
 
I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP 
and Asterisk hasn't crashed after reload. However it did take 25 mins to load.
 
As requested I have opened a ticket for the realtime issue:
 
https://issues.asterisk.org/jira/browse/ASTERISK-25826
​Got it, thanks.​ 
 
Basically, I think this could be resolved by a configuration option that stops 
sourcery/pjsip loading all peers at start-up as this is not needed for the 
current setup. This has been discussed before on the mailing list however it 
doesn't look like it progresses any further.

​If you're up for trying something, ​you can comment out the 
qualify_and_schedule_all function ​in ​line​s​ 1135​-1147​ of 
res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines 1245 
and 1281.  If that drops your startup times, then we know we're on the right 
track.
 
 
I would like to thank you for all of your help tying to identify the issue and 
hope that we can resolve it soon.

​No worries!​ 
 
Kind regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 16:27:06 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer  wrote:



ok,
 
That took 15 mins to load and then crashed. This will be due to the 
pjsip_dlg_create_uas_and_inc_lock commit.
​It should not have crashed.  That commit had the fix for it.  If it did crash 
with that commit, open a Jira issue and ​attach a full backtrace. 
 
However 15 mins to start is a long time and would cause issues in a production 
environment.
​Would you open a Jira issue on the realtime problem (if one isn't already 
open).I'm starting to look at alternatives.


 
Thank you for your help here,
 
Ross

 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 14:02:38 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer  wrote:



Hi George,
 
Using a development test box for testing!!
 
Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240

​Ok, try this combination..."git checkout 
c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching.
The commit I referenced is the one that handles the 
pjsip_dlg_create_uas_and_inc_lock​


  
Qualify time on the aor is set to zero, I guess a query could be made to check 
for a value greater than zero instead of loading all endpoints.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer  wrote:



Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.

​Try 13.7.2 without the cache.  I'm trying to understand where the time is 
being spent.​  I know it will crash because of that bug.  You're not doing this 
on a production system are you??  
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.

​How do you know they're not qualified if you don't load them? :)
Time to load up a database with 20,000 endpoints I guess.​  
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy 

Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
I have commented out those lines and it hasn't improved the load times, its 
still taking 15 mins. It has improved it a little.
 
Regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Wed, 2 Mar 2016 08:19:01 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer  wrote:



Hi George,
 
I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP 
and Asterisk hasn't crashed after reload. However it did take 25 mins to load.
 
As requested I have opened a ticket for the realtime issue:
 
https://issues.asterisk.org/jira/browse/ASTERISK-25826
​Got it, thanks.​ 
 
Basically, I think this could be resolved by a configuration option that stops 
sourcery/pjsip loading all peers at start-up as this is not needed for the 
current setup. This has been discussed before on the mailing list however it 
doesn't look like it progresses any further.

​If you're up for trying something, ​you can comment out the 
qualify_and_schedule_all function ​in ​line​s​ 1135​-1147​ of 
res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines 1245 
and 1281.  If that drops your startup times, then we know we're on the right 
track.
 
 
I would like to thank you for all of your help tying to identify the issue and 
hope that we can resolve it soon.

​No worries!​ 
 
Kind regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 16:27:06 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer  wrote:



ok,
 
That took 15 mins to load and then crashed. This will be due to the 
pjsip_dlg_create_uas_and_inc_lock commit.
​It should not have crashed.  That commit had the fix for it.  If it did crash 
with that commit, open a Jira issue and ​attach a full backtrace. 
 
However 15 mins to start is a long time and would cause issues in a production 
environment.
​Would you open a Jira issue on the realtime problem (if one isn't already 
open).I'm starting to look at alternatives.


 
Thank you for your help here,
 
Ross

 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 14:02:38 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer  wrote:



Hi George,
 
Using a development test box for testing!!
 
Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240

​Ok, try this combination..."git checkout 
c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching.
The commit I referenced is the one that handles the 
pjsip_dlg_create_uas_and_inc_lock​


  
Qualify time on the aor is set to zero, I guess a query could be made to check 
for a value greater than zero instead of loading all endpoints.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer  wrote:



Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.

​Try 13.7.2 without the cache.  I'm trying to understand where the time is 
being spent.​  I know it will crash because of that bug.  You're not doing this 
on a production system are you??  
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.

​How do you know they're not qualified if you don't load them? :)
Time to load up a database with 20,000 endpoints I guess.​  
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy  wrote:


Hello,
 
Please see this discussion 
http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.
​It's possible.​
 

 
Michael
 
On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all 
> endpoints are registered only about 200, yet asterisk loops through every 
> endpoint which 

[asterisk-dev] Asterisk Crash

[Ross Beer]

 Hi,
 
PJSIP just caused a seg fault at the current location:
 
[?1034h(gdb) bt
#0  __pthread_mutex_unlock_usercnt (mutex=0x0) at pthread_mutex_unlock.c:289
#1  __pthread_mutex_unlock (mutex=0x0) at pthread_mutex_unlock.c:290
#2  0x2b686ac0f203 in pj_mutex_unlock () from /usr/lib64/libpj.so.2
#3  0x2b6868c641f6 in pjsip_dlg_dec_lock () from /usr/lib64/libpjsip.so.2
#4  0x2b68708393f8 in distributor (rdata=0x2b6904021178) at 
res_pjsip/pjsip_distributor.c:301
#5  0x2b6868c47e16 in pjsip_endpt_process_rx_data () from 
/usr/lib64/libpjsip.so.2
#6  0x2b6868c4809a in endpt_on_rx_msg () from /usr/lib64/libpjsip.so.2
#7  0x2b6868c50368 in pjsip_tpmgr_receive_packet () from 
/usr/lib64/libpjsip.so.2
#8  0x2b6868c51e3b in udp_on_read_complete () from /usr/lib64/libpjsip.so.2
#9  0x2b686ac0be96 in ioqueue_dispatch_read_event () from 
/usr/lib64/libpj.so.2
#10 0x2b686ac0db24 in pj_ioqueue_poll () from /usr/lib64/libpj.so.2
#11 0x2b6868c47b21 in pjsip_endpt_handle_events2 () from 
/usr/lib64/libpjsip.so.2
#12 0x2b6868c47bcf in pjsip_endpt_handle_events () from 
/usr/lib64/libpjsip.so.2
#13 0x2b6870823a9c in monitor_thread_exec (endpt=0x0) at res_pjsip.c:3555
#14 0x2b686ac0e88f in thread_main () from /usr/lib64/libpj.so.2
#15 0x2b66fa7e2a51 in start_thread (arg=0x2b68416a5700) at 
pthread_create.c:301
#16 0x2b66fb67493d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt full
#0  __pthread_mutex_unlock_usercnt (mutex=0x0) at pthread_mutex_unlock.c:289
type = 
#1  __pthread_mutex_unlock (mutex=0x0) at pthread_mutex_unlock.c:290
No locals.
#2  0x2b686ac0f203 in pj_mutex_unlock () from /usr/lib64/libpj.so.2
No symbol table info available.
#3  0x2b6868c641f6 in pjsip_dlg_dec_lock () from /usr/lib64/libpjsip.so.2
No symbol table info available.
#4  0x2b68708393f8 in distributor (rdata=0x2b6904021178) at 
res_pjsip/pjsip_distributor.c:301
dlg = 0x2b68b00f58a8
dist = 0x2b6b893723c8
serializer = 0x2b6b89673578
req_serializer = 0x2b6b89673578
clone = 0x2b69040517e8
#5  0x2b6868c47e16 in pjsip_endpt_process_rx_data () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#6  0x2b6868c4809a in endpt_on_rx_msg () from /usr/lib64/libpjsip.so.2
No symbol table info available.
#7  0x2b6868c50368 in pjsip_tpmgr_receive_packet () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#8  0x2b6868c51e3b in udp_on_read_complete () from /usr/lib64/libpjsip.so.2
No symbol table info available.
#9  0x2b686ac0be96 in ioqueue_dispatch_read_event () from 
/usr/lib64/libpj.so.2
No symbol table info available.
#10 0x2b686ac0db24 in pj_ioqueue_poll () from /usr/lib64/libpj.so.2
No symbol table info available.
#11 0x2b6868c47b21 in pjsip_endpt_handle_events2 () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#12 0x2b6868c47bcf in pjsip_endpt_handle_events () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#13 0x2b6870823a9c in monitor_thread_exec (endpt=0x0) at res_pjsip.c:3555
delay = {sec = 0, msec = 10}
#14 0x2b686ac0e88f in thread_main () from /usr/lib64/libpj.so.2
No symbol table info available.
#15 0x2b66fa7e2a51 in start_thread (arg=0x2b68416a5700) at 
pthread_create.c:301
__res = 
pd = 0x2b68416a5700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {47726774081280, 
3565715072785538793, 140727544518944, 47726774081984, 44910560, 3, 
7470192104369774313, 7473162878733999849}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, 
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#16 0x2b66fb67493d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
No locals.
 
Can anyone advise if this is fixed by PJSIP commit 5243?
 
Thanks,
 
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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP 
and Asterisk hasn't crashed after reload. However it did take 25 mins to load.
 
As requested I have opened a ticket for the realtime issue:
 
https://issues.asterisk.org/jira/browse/ASTERISK-25826
 
Basically, I think this could be resolved by a configuration option that stops 
sourcery/pjsip loading all peers at start-up as this is not needed for the 
current setup. This has been discussed before on the mailing list however it 
doesn't look like it progresses any further.
 
I would like to thank you for all of your help tying to identify the issue and 
hope that we can resolve it soon.
 
Kind regards,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 16:27:06 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer  wrote:



ok,
 
That took 15 mins to load and then crashed. This will be due to the 
pjsip_dlg_create_uas_and_inc_lock commit.
​It should not have crashed.  That commit had the fix for it.  If it did crash 
with that commit, open a Jira issue and ​attach a full backtrace. 
 
However 15 mins to start is a long time and would cause issues in a production 
environment.
​Would you open a Jira issue on the realtime problem (if one isn't already 
open).I'm starting to look at alternatives.


 
Thank you for your help here,
 
Ross

 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 14:02:38 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer  wrote:



Hi George,
 
Using a development test box for testing!!
 
Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240

​Ok, try this combination..."git checkout 
c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching.
The commit I referenced is the one that handles the 
pjsip_dlg_create_uas_and_inc_lock​


  
Qualify time on the aor is set to zero, I guess a query could be made to check 
for a value greater than zero instead of loading all endpoints.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer  wrote:



Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.

​Try 13.7.2 without the cache.  I'm trying to understand where the time is 
being spent.​  I know it will crash because of that bug.  You're not doing this 
on a production system are you??  
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.

​How do you know they're not qualified if you don't load them? :)
Time to load up a database with 20,000 endpoints I guess.​  
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy  wrote:


Hello,
 
Please see this discussion 
http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.
​It's possible.​
 

 
Michael
 
On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all 
> endpoints are registered only about 200, yet asterisk loops through every 
> endpoint which has been defined. It does this if contacts are in realtime or 
> not.
>  
> Its almost like pjsip is loading them to check if they need to be qualified 
> etc.
>  
> Asterisk 1.8 only put things into cache once they were accessed, is this an 
> option for sourcery?
​Well, in order to initiate qualify of contacts, Asterisk does have to "access" 
them all​ so I'm not quite sure what the problem is.
Can we reset to a known config and see what happens?

pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 
tarball.Disable memory_cache altogether in sorcery.conf.

See what happens.
Give me an estimate of how many endpoints and aors there are in the database, 
how many of thos

Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

ok,
 
That took 15 mins to load and then crashed. This will be due to the 
pjsip_dlg_create_uas_and_inc_lock commit.
 
However 15 mins to start is a long time and would cause issues in a production 
environment.
 
Thank you for your help here,
 
Ross

 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 14:02:38 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer  wrote:



Hi George,
 
Using a development test box for testing!!
 
Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240

​Ok, try this combination..."git checkout 
c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching.
The commit I referenced is the one that handles the 
pjsip_dlg_create_uas_and_inc_lock​


  
Qualify time on the aor is set to zero, I guess a query could be made to check 
for a value greater than zero instead of loading all endpoints.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer  wrote:



Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.

​Try 13.7.2 without the cache.  I'm trying to understand where the time is 
being spent.​  I know it will crash because of that bug.  You're not doing this 
on a production system are you??  
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.

​How do you know they're not qualified if you don't load them? :)
Time to load up a database with 20,000 endpoints I guess.​  
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy  wrote:


Hello,
 
Please see this discussion 
http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.
​It's possible.​
 

 
Michael
 
On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all 
> endpoints are registered only about 200, yet asterisk loops through every 
> endpoint which has been defined. It does this if contacts are in realtime or 
> not.
>  
> Its almost like pjsip is loading them to check if they need to be qualified 
> etc.
>  
> Asterisk 1.8 only put things into cache once they were accessed, is this an 
> option for sourcery?
​Well, in order to initiate qualify of contacts, Asterisk does have to "access" 
them all​ so I'm not quite sure what the problem is.
Can we reset to a known config and see what happens?

pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 
tarball.Disable memory_cache altogether in sorcery.conf.

See what happens.
Give me an estimate of how many endpoints and aors there are in the database, 
how many of those aors have static contacts defined, and what's your qualify 
interval.
An idea of your database setup would help as well.  Same server, local, remote, 
etc.
Let's solve 1 problem at a time.
 




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



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

Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
Using a development test box for testing!!
 
Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240
 
Qualify time on the aor is set to zero, I guess a query could be made to check 
for a value greater than zero instead of loading all endpoints.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer  wrote:



Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.

​Try 13.7.2 without the cache.  I'm trying to understand where the time is 
being spent.​  I know it will crash because of that bug.  You're not doing this 
on a production system are you??  
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.

​How do you know they're not qualified if you don't load them? :)
Time to load up a database with 20,000 endpoints I guess.​  
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy  wrote:


Hello,
 
Please see this discussion 
http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.
​It's possible.​
 

 
Michael
 
On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all 
> endpoints are registered only about 200, yet asterisk loops through every 
> endpoint which has been defined. It does this if contacts are in realtime or 
> not.
>  
> Its almost like pjsip is loading them to check if they need to be qualified 
> etc.
>  
> Asterisk 1.8 only put things into cache once they were accessed, is this an 
> option for sourcery?
​Well, in order to initiate qualify of contacts, Asterisk does have to "access" 
them all​ so I'm not quite sure what the problem is.
Can we reset to a known config and see what happens?

pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 
tarball.Disable memory_cache altogether in sorcery.conf.

See what happens.
Give me an estimate of how many endpoints and aors there are in the database, 
how many of those aors have static contacts defined, and what's your qualify 
interval.
An idea of your database setup would help as well.  Same server, local, remote, 
etc.
Let's solve 1 problem at a time.
 




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



-- 
_
-- 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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
No endpoints are qualified, there are 20,000 endpoints with only 75 static 
contacts defined in the aors. The database is a MySQL cluster.
 
With the current Asterisk 13 branch with cache disabled and the latest PJSIP it 
takes 5 mins and then before finishing it crashes.
 
With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due 
to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices.
 
The main issue here is that the endpoints are loaded as soon as PJSIP loads, 
ideally endpoints would only be loaded once a device registers or attempts to 
make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime.
 
There is no need to load the endpoints as they are not qualified.
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy  wrote:


Hello,
 
Please see this discussion 
http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.
​It's possible.​
 

 
Michael
 
On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all 
> endpoints are registered only about 200, yet asterisk loops through every 
> endpoint which has been defined. It does this if contacts are in realtime or 
> not.
>  
> Its almost like pjsip is loading them to check if they need to be qualified 
> etc.
>  
> Asterisk 1.8 only put things into cache once they were accessed, is this an 
> option for sourcery?
​Well, in order to initiate qualify of contacts, Asterisk does have to "access" 
them all​ so I'm not quite sure what the problem is.
Can we reset to a known config and see what happens?

pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 
tarball.Disable memory_cache altogether in sorcery.conf.

See what happens.
Give me an estimate of how many endpoints and aors there are in the database, 
how many of those aors have static contacts defined, and what's your qualify 
interval.
An idea of your database setup would help as well.  Same server, local, remote, 
etc.
Let's solve 1 problem at a time.
 




-- 
_
-- 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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
We need to store contacts in realtime for our system. However not all endpoints 
are registered only about 200, yet asterisk loops through every endpoint which 
has been defined. It does this if contacts are in realtime or not.
 
Its almost like pjsip is loading them to check if they need to be qualified etc.
 
Asterisk 1.8 only put things into cache once they were accessed, is this an 
option for sourcery?
 
Thanks,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 10:42:58 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 10:29 AM, Ross Beer  wrote:



Hi George,
 
I have now got asterisk 13 trunk, however loading is very slow. This is due to 
asterisk reading all of the realtime Sorcery peers and marking them all as 
'Unknown'. Is there a way to only cache peers that have tried to register?


​When you say "Asterisk 13 trunk"​ ​you do mean "branch"​ correct?
​Assuming you have contacts coming from realtime, the only was to prevent them 
from being qualified is to ​delete them from the ps_contacts table before 
starting Asterisk.  You really don't gain anything by using realtime for 
contacts anyway.  I'd just disable it and let Asterisk use the internal sqlite3 
database to keep track of them. 
 
So far its taking 20 mins to load!!
 
Also asterisk has the following warning:
 
taskprocessor.c:803 taskprocessor_push: The 
'subm:ast_device_state_topic-55d0' task processor queue reached 500 
scheduled tasks.
 

​Whoa!​  This makes me think I might have messed something up in the fix for 
contacts not being cached correctly.
Don't use realtime for contacts and see what happens.  I'm going to re-test.
 Neither were issues in the previous release.
 
Thank you for your assistance,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 09:08:37 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer  wrote:



Further to my previous email it appears this bug won't be easily resolved by 
changing the method:
 
pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock().
 
Asterisk starts ok, allows registrations but no calls progress.


​You have to pull Asterisk from the 13 branch.  ​This should have been fixed 
with review 2236 and I've been running with that patch and pjproject trunk.
 
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:49:55 +
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




I've just found an open issue for this 
https://issues.asterisk.org/jira/browse/ASTERISK-25751

 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:06:09 +
Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




 Hi,

Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk 
crashes when a device registers.

The commit resolves the following:
 
• Crash when endpoint has multiple worker threads and SIP TCP transport is 
disconnected during incoming call handling.
• Deprecated pjsip_dlg_create_uas(), replaced by 
pjsip_dlg_create_uas_and_inc_lock().
• Serialized transaction state notifications (of 'terminated' and 'destroyed') 
in case of transport error.
 
This commit should resolve a previous segfault within Asterisk, however due to 
the deprecated method I believe this is causing an additional issue. 
 
Can this be easily resolved to resolve both segfaults?
 
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
  

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



-- 
_
-- 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 Segfault After PJSIP Commit 5241

[Ross Beer]

Hi George,
 
I have now got asterisk 13 trunk, however loading is very slow. This is due to 
asterisk reading all of the realtime Sorcery peers and marking them all as 
'Unknown'. Is there a way to only cache peers that have tried to register?
 
So far its taking 20 mins to load!!
 
Also asterisk has the following warning:
 
taskprocessor.c:803 taskprocessor_push: The 
'subm:ast_device_state_topic-55d0' task processor queue reached 500 
scheduled tasks.
 
Neither were issues in the previous release.
 
Thank you for your assistance,
 
Ross
 
From: george.jos...@fairview5.com
Date: Tue, 1 Mar 2016 09:08:37 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer  wrote:



Further to my previous email it appears this bug won't be easily resolved by 
changing the method:
 
pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock().
 
Asterisk starts ok, allows registrations but no calls progress.


​You have to pull Asterisk from the 13 branch.  ​This should have been fixed 
with review 2236 and I've been running with that patch and pjproject trunk.
 
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:49:55 +
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




I've just found an open issue for this 
https://issues.asterisk.org/jira/browse/ASTERISK-25751

 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:06:09 +
Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




 Hi,

Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk 
crashes when a device registers.

The commit resolves the following:
 
• Crash when endpoint has multiple worker threads and SIP TCP transport is 
disconnected during incoming call handling.
• Deprecated pjsip_dlg_create_uas(), replaced by 
pjsip_dlg_create_uas_and_inc_lock().
• Serialized transaction state notifications (of 'terminated' and 'destroyed') 
in case of transport error.
 
This commit should resolve a previous segfault within Asterisk, however due to 
the deprecated method I believe this is causing an additional issue. 
 
Can this be easily resolved to resolve both segfaults?
 
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
  

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



-- 
_
-- 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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

Further to my previous email it appears this bug won't be easily resolved by 
changing the method:
 
pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock().
 
Asterisk starts ok, allows registrations but no calls progress.
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:49:55 +
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




I've just found an open issue for this 
https://issues.asterisk.org/jira/browse/ASTERISK-25751

 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:06:09 +
Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




 Hi,

Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk 
crashes when a device registers.

The commit resolves the following:
 
• Crash when endpoint has multiple worker threads and SIP TCP transport is 
disconnected during incoming call handling.
• Deprecated pjsip_dlg_create_uas(), replaced by 
pjsip_dlg_create_uas_and_inc_lock().
• Serialized transaction state notifications (of 'terminated' and 'destroyed') 
in case of transport error.
 
This commit should resolve a previous segfault within Asterisk, however due to 
the deprecated method I believe this is causing an additional issue. 
 
Can this be easily resolved to resolve both segfaults?
 
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
  

-- 
_
-- 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] Asterisk Segfault After PJSIP Commit 5241

[Ross Beer]

I've just found an open issue for this 
https://issues.asterisk.org/jira/browse/ASTERISK-25751

 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 1 Mar 2016 11:06:09 +
Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241




 Hi,

Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk 
crashes when a device registers.

The commit resolves the following:
 
• Crash when endpoint has multiple worker threads and SIP TCP transport is 
disconnected during incoming call handling.
• Deprecated pjsip_dlg_create_uas(), replaced by 
pjsip_dlg_create_uas_and_inc_lock().
• Serialized transaction state notifications (of 'terminated' and 'destroyed') 
in case of transport error.
 
This commit should resolve a previous segfault within Asterisk, however due to 
the deprecated method I believe this is causing an additional issue. 
 
Can this be easily resolved to resolve both segfaults?
 
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
  -- 
_
-- 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 Segfault After PJSIP Commit 5241

[Ross Beer]

 Hi,

Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk 
crashes when a device registers.

The commit resolves the following:
 
• Crash when endpoint has multiple worker threads and SIP TCP transport is 
disconnected during incoming call handling.
• Deprecated pjsip_dlg_create_uas(), replaced by 
pjsip_dlg_create_uas_and_inc_lock().
• Serialized transaction state notifications (of 'terminated' and 'destroyed') 
in case of transport error.
 
This commit should resolve a previous segfault within Asterisk, however due to 
the deprecated method I believe this is causing an additional issue. 
 
Can this be easily resolved to resolve both segfaults?
 
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] Sorcery Cache Error

[Ross Beer]

Hi George,
 
I have created an issue on Jira as requested, the issue can be found here:
 
https://issues.asterisk.org/jira/browse/ASTERISK-25811
 
Thank you for your assistance with this bug,
 
Kind regards,

Ross
 
From: george.jos...@fairview5.com
Date: Thu, 25 Feb 2016 08:15:15 -0700
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] Sorcery Cache Error



On Thu, Feb 25, 2016 at 7:20 AM, Ross Beer  wrote:



Hi,
 
I am receiving the below message when using Sorcery cache:
 
[2016-02-25 13:47:02] ERROR[17353]: res_sorcery_memory_cache.c:1559 
sorcery_memory_cache_delete: Unable to delete object 
';@115bb1375dae1799c68048e7abef7e05' from sorcery cache
 Contact /sip:@:39212;transport=TLS has been 
deleted
-- Added contact 'sip:@:39212;transport=TLS' to AOR 
'' with expiration of 60 seconds
 Contact /sip:@:39212;transport=TLS has been 
created
 Contact /sip:@:39212;transport=TLS is now 
Unknown.  RTT: 0.000 msec
 
The device had previously registered and therefore the device should have been 
in the cache. When this issue occurs it blocks the registration of an endpoint 
causing it to go offline. I can replicate this issue by pressing 'Re-register' 
within the Snom interface.
 
Firstly I can't find documentation on 'full_backend_cache' on the Wiki page: 
https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching
​I think this was on my todo list from a few weeks ago when I was experimenting 
with full_backend_cache. :)​ 
 
Therefore is full cache setup in the same way as other object settings?
 
[res_pjsip] ; 
auth/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
auth=config,pjsip.conf,criteria=type=auth
auth=realtime,ps_auths
 
aor/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
aor=config,pjsip.conf,criteria=type=aor
aor=realtime,ps_aors
 
domain_alias/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
domain_alias=config,pjsip.conff,criteria=type=domain_alias
domain_alias=realtime,ps_domain_aliases
 
endpoint/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints
 
contact/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
contact=config,pjsip.conf,criteria=type=contact
contact=realtime,ps_contacts
​If you don't use realtime for contacts and let it default to the astdb, does 
everything else work?​ 

 
[res_pjsip_endpoint_identifier_ip]
identify/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
identify=config,pjsip.conf,criteria=type=identify
identify=realtime,ps_endpoint_id_ips

Looking at the real-time database the ID is present all be it encoded with 
^3B which is the encoding for a semicolon. Therefore it looks like 
the cache isn't matching the object correctly or not being inserted in the 
first place. 

​I can look at this this afternoon.​  Can you open an Jira issue?

 
I don't believe this relates to the full_backend_cache as this issue is also 
present on another test box which is using standard cache.
 
Any advice on how to resolve/investigate the issue would be helpful.


​I think you've provided enough.​ 
 
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



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

[asterisk-dev] Sorcery Cache Error

[Ross Beer]

Hi,
 
I am receiving the below message when using Sorcery cache:
 
[2016-02-25 13:47:02] ERROR[17353]: res_sorcery_memory_cache.c:1559 
sorcery_memory_cache_delete: Unable to delete object 
';@115bb1375dae1799c68048e7abef7e05' from sorcery cache
 Contact /sip:@:39212;transport=TLS has been 
deleted
-- Added contact 'sip:@:39212;transport=TLS' to AOR 
'' with expiration of 60 seconds
 Contact /sip:@:39212;transport=TLS has been 
created
 Contact /sip:@:39212;transport=TLS is now 
Unknown.  RTT: 0.000 msec
 
The device had previously registered and therefore the device should have been 
in the cache. When this issue occurs it blocks the registration of an endpoint 
causing it to go offline. I can replicate this issue by pressing 'Re-register' 
within the Snom interface.
 
Firstly I can't find documentation on 'full_backend_cache' on the Wiki page: 
https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching
 
Therefore is full cache setup in the same way as other object settings?
 
[res_pjsip] ; 
auth/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
auth=config,pjsip.conf,criteria=type=auth
auth=realtime,ps_auths
 
aor/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
aor=config,pjsip.conf,criteria=type=aor
aor=realtime,ps_aors
 
domain_alias/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
domain_alias=config,pjsip.conff,criteria=type=domain_alias
domain_alias=realtime,ps_domain_aliases
 
endpoint/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints
 
contact/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
contact=config,pjsip.conf,criteria=type=contact
contact=realtime,ps_contacts
 
[res_pjsip_endpoint_identifier_ip]
identify/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
identify=config,pjsip.conf,criteria=type=identify
identify=realtime,ps_endpoint_id_ips

Looking at the real-time database the ID is present all be it encoded with 
^3B which is the encoding for a semicolon. Therefore it looks like 
the cache isn't matching the object correctly or not being inserted in the 
first place. 
 
I don't believe this relates to the full_backend_cache as this issue is also 
present on another test box which is using standard cache.
 
Any advice on how to resolve/investigate the issue would be helpful.
 
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] Asterisk 13.7.2 Failed to create new channel thread

[Ross Beer]

Ok, I'll continue to investigate.
 
You've also been looking at a segfault which I'm trying to debug with PJSIP on 
ticket ASTERISK-25785 could you take another look, I've updated the status 
today with a fresh backtrace.
 
Kind regards,
 
Ross
 
> Date: Mon, 22 Feb 2016 08:04:40 -0400
> From: jc...@digium.com
> To: asterisk-dev@lists.digium.com
> Subject: Re: [asterisk-dev] Asterisk 13.7.2 Failed to create new channel  
> thread
> 
> Ross Beer wrote:
> > Hi Joshua,
> >
> > Do you know what could be causing this issue?
> 
> Not off the top of my head. If I had an inkling it would have been in my 
> original email. I've only seen such things when you're really stressing 
> the system, and 500 channels (probably) shouldn't do it.
> 
> -- 
> Joshua Colp
> Digium, Inc. | Senior 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
  -- 
_
-- 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 13.7.2 Failed to create new channel thread

[Ross Beer]

Hi Joshua,
 
Do you know what could be causing this issue?
 
There is plenty of memory and ports available. As you can see the ulimit 
settings are mostly unlimited.
 
Kind regards,
 
Ross 
 
> Date: Mon, 22 Feb 2016 07:45:28 -0400
> From: jc...@digium.com
> To: asterisk-dev@lists.digium.com
> Subject: Re: [asterisk-dev] Asterisk 13.7.2 Failed to create new channel  
> thread
> 
> Ross Beer wrote:
> > *Hi,*
> > **
> > *We are receiving the following error when hitting around 500 channels
> > in a queue using PJSIP:*
> >
> > [2016-02-22 09:20:42] WARNING[31097]: pbx.c:6980 ast_pbx_start:
> > Failed to create new channel thread
> > [2016-02-22 09:20:42] WARNING[31097]: chan_pjsip.c:2202
> > pbx_start_incoming_request: Failed to start PBX ;(
> 
> 
> This would be coming from the system when we try to create a thread.
> 
> >
> >
> > *Limits are set as follows:*
> >
> > ulimit -a
> > core file size (blocks, -c) unlimited
> > data seg size (kbytes, -d) unlimited
> > scheduling priority (-e) 0
> > file size (blocks, -f) unlimited
> > pending signals (-i) unlimited
> > max locked memory (kbytes, -l) unlimited
> > max memory size (kbytes, -m) unlimited
> > open files (-n) 80
> > pipe size (512 bytes, -p) 8
> > POSIX message queues (bytes, -q) unlimited
> > real-time priority (-r) 0
> > stack size (kbytes, -s) unlimited
> > cpu time (seconds, -t) unlimited
> > max user processes (-u) unlimited
> > virtual memory (kbytes, -v) unlimited
> > file locks (-x) unlimited
> >
> >
> > *Can this be resolved by configuring pjproject in the following way?*
> >
> > ./configure CFLAGS="-DNDEBUG -DPJ_HAS_IPV6=1 -DPJSUA_MAX_CALLS=5000
> > -DPJSUA_MAX_PLAYERS=5000" --prefix=/usr --libdir=/usr/lib64
> > --enable-shared --disable-video --disable-sound --disable-opencore-amr
> >
> > *Basically setting PJSUA_MAX_CALLS=5000 and PJSUA_MAX_PLAYERS=5000
> > higher than the default?*
> 
> No, those have no impact on threading or constraints within Asterisk 
> itself. They will do nothing when used with Asterisk.
> 
> -- 
> Joshua Colp
> Digium, Inc. | Senior 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
  -- 
_
-- 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 13.7.2 Failed to create new channel thread

[Ross Beer]

Hi,
 
We are receiving the following error when hitting around 500 channels in a 
queue using PJSIP:
 
[2016-02-22 09:20:42] WARNING[31097]: pbx.c:6980 ast_pbx_start: Failed to 
create new channel thread
[2016-02-22 09:20:42] WARNING[31097]: chan_pjsip.c:2202 
pbx_start_incoming_request: Failed to start PBX ;(
 
Limits are set as follows:
 
ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory   (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files  (-n) 80
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
real-time priority  (-r) 0
stack size  (kbytes, -s) unlimited
cpu time   (seconds, -t) unlimited
max user processes  (-u) unlimited
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited
 
Can this be resolved by configuring pjproject in the following way?
 
./configure CFLAGS="-DNDEBUG -DPJ_HAS_IPV6=1 -DPJSUA_MAX_CALLS=5000 
-DPJSUA_MAX_PLAYERS=5000" --prefix=/usr --libdir=/usr/lib64 --enable-shared 
--disable-video --disable-sound --disable-opencore-amr
 
Basically setting PJSUA_MAX_CALLS=5000 and PJSUA_MAX_PLAYERS=5000 higher than 
the default? I would be grateful for any advice you can offer. 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

[asterisk-dev] Re-visit ASTERISK-25444 for Asterisk 13.7.2

[Ross Beer]

 Hi,
 
It is possible to revisit ticket ASTERISK-25444, basically RealTime MoH causes 
a lot of messages to be displayed on queues due to the way an error message is 
being used.
 
For example:
 
[2016-02-22 09:20:42] WARNING[7562][C-34c5]: res_musiconhold.c:884 
_get_mohbyname: Music on Hold class 'default' not found in memory. Verify your 
configuration.
 
However MoH is stored in RealTime and plays correctly.
 
Also is there a way Sourcery can cache RealTime MoH?
 
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] Unable to register OPTIONS transaction (key exists)

[Ross Beer]

Hi Joshua,
 
I've started getting the same issue with registrations to a quiet test box:
 
[2016-02-14 10:20:12] WARNING[13927]: pjsip:0 :  sip_transactio Unable 
to register REGISTER transaction (key exists)
-- Added contact 'sip:ENDPOINT@:8300' to AOR 'ENDPOINT' with 
expiration of 60 seconds
 Contact ENDPOINT/sip:ENDPOINT@:8300 has been created
 
The phone is registering every 60 seconds and is doing so successfully without 
packet loss therefore the transaction should be closed as soon as the phone 
successfully registers. My question is therefore why does a transaction still 
exist? How can I help diagnose this issue? Kind regards, Ross
 > Date: Mon, 8 Feb 2016 10:32:23 -0400
> From: jc...@digium.com
> To: asterisk-dev@lists.digium.com
> Subject: Re: [asterisk-dev] Unable to register OPTIONS transaction (key   
> exists)
> 
> Ross Beer wrote:
> > Hi,
> >
> > I'm seeing a lot of 'Unable to register OPTIONS transaction' when
> > Asterisk 13.7.2 is under load. Are transactions being cleared once a 200
> > response has been sent?
> 
> How loaded is loaded? Depending on the speed at which things are being 
> handled you can run into a situation where retransmissions are in queue 
> and are handled close to each other.
> 
> >
> > [Feb 8 08:03:12] WARNING[41498]: pjsip:0 : sip_transactio .Unable to
> > register OPTIONS transaction (key exists)
> > [Feb 8 08:03:12] ERROR[41498]: res_pjsip/pjsip_options.c:687
> > send_options_response: Unable to send response (-1)
> > [Feb 8 08:03:13] WARNING[42777]: pjsip:0 : sip_transactio .Unable to
> > register OPTIONS transaction (key exists)
> > [Feb 8 08:03:13] ERROR[42777]: res_pjsip/pjsip_options.c:687
> > send_options_response: Unable to send response (-1)
> > [Feb 8 08:03:14] WARNING[40797]: pjsip:0 : sip_transactio .Unable to
> > register OPTIONS transaction (key exists)
> > [Feb 8 08:03:14] ERROR[40797]: res_pjsip/pjsip_options.c:687
> > send_options_response: Unable to send response (-1)
> > [Feb 8 08:03:14] WARNING[46095]: pjsip:0 : sip_transactio .Unable to
> > register OPTIONS transaction (key exists)
> > [Feb 8 08:03:14] ERROR[46095]: res_pjsip/pjsip_options.c:687
> > send_options_response: Unable to send response (-1)
> >
> > I have a feeling that the transactions are not being cleared quick
> > enough, however option pings are being received every minute. Is this an
> > issue with Asterisk or the PJSIP library?
> 
> It could be in either but most likely our usage. It really depends on 
> the above question about being loaded though.
> 
> -- 
> Joshua Colp
> Digium, Inc. | Senior 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
  -- 
_
-- 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] Unable to register OPTIONS transaction (key exists)

[Ross Beer]

Hi,
 
I'm seeing a lot of 'Unable to register OPTIONS transaction' when Asterisk 
13.7.2 is under load. Are transactions being cleared once a 200 response has 
been sent?
 
[Feb  8 08:03:12] WARNING[41498]: pjsip:0 :  sip_transactio .Unable to 
register OPTIONS transaction (key exists)
[Feb  8 08:03:12] ERROR[41498]: res_pjsip/pjsip_options.c:687 
send_options_response: Unable to send response (-1)
[Feb  8 08:03:13] WARNING[42777]: pjsip:0 :  sip_transactio .Unable to 
register OPTIONS transaction (key exists)
[Feb  8 08:03:13] ERROR[42777]: res_pjsip/pjsip_options.c:687 
send_options_response: Unable to send response (-1)
[Feb  8 08:03:14] WARNING[40797]: pjsip:0 :  sip_transactio .Unable to 
register OPTIONS transaction (key exists)
[Feb  8 08:03:14] ERROR[40797]: res_pjsip/pjsip_options.c:687 
send_options_response: Unable to send response (-1)
[Feb  8 08:03:14] WARNING[46095]: pjsip:0 :  sip_transactio .Unable to 
register OPTIONS transaction (key exists)
[Feb  8 08:03:14] ERROR[46095]: res_pjsip/pjsip_options.c:687 
send_options_response: Unable to send response (-1)
 
I have a feeling that the transactions are not being cleared quick enough, 
however option pings are being received every minute. Is this an issue with 
Asterisk or the PJSIP library?
 
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

[asterisk-dev] Asterisk 13.7.0 Crash

[Ross Beer]

Hi,
 
I've had a crash on a couple of test boxes which look to be related to 
'strcmp'. Is the following issue with Asterisk or PJSIP?
 
bt
#0  __strncasecmp_l_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:259
#1  0x2b2492c21ac8 in pj_stricmp () from /usr/lib64/libpj.so.2
#2  0x2b2490e44ec1 in pjsip_msg_find_hdr_by_name () from 
/usr/lib64/libpjsip.so.2
#3  0x2b2490e7004a in dlg_beautify_response () from /usr/lib64/libpjsip.so.2
#4  0x2b2490e70504 in pjsip_dlg_send_response () from 
/usr/lib64/libpjsip.so.2
#5  0x2b2490a0e888 in pjsip_inv_send_msg () from /usr/lib64/libpjsip-ua.so.2
#6  0x2b255a0f282d in indicate (data=0x2b27ce162a38) at chan_pjsip.c:1021
#7  0x005acf34 in ast_taskprocessor_execute (tps=0x2b27cc699de8) at 
taskprocessor.c:784
#8  0x005b4380 in execute_tasks (data=0x2b27cc699de8) at 
threadpool.c:1320
#9  0x005acf34 in ast_taskprocessor_execute (tps=0x25e1b98) at 
taskprocessor.c:784
#10 0x005b5512 in threadpool_execute (arg=0x2b24a00025d8) at 
threadpool.c:351
#11 worker_active (arg=0x2b24a00025d8) at threadpool.c:1103
#12 worker_start (arg=0x2b24a00025d8) at threadpool.c:1023
#13 0x005c03fb in dummy_start (data=) at 
utils.c:1237
#14 0x2b23402b0a51 in start_thread (arg=0x2b23905d0700) at 
pthread_create.c:301
#15 0x2b234114293d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) bt full
#0  __strncasecmp_l_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:259
No locals.
#1  0x2b2492c21ac8 in pj_stricmp () from /usr/lib64/libpj.so.2
No symbol table info available.
#2  0x2b2490e44ec1 in pjsip_msg_find_hdr_by_name () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#3  0x2b2490e7004a in dlg_beautify_response () from /usr/lib64/libpjsip.so.2
No symbol table info available.
#4  0x2b2490e70504 in pjsip_dlg_send_response () from 
/usr/lib64/libpjsip.so.2
No symbol table info available.
#5  0x2b2490a0e888 in pjsip_inv_send_msg () from /usr/lib64/libpjsip-ua.so.2
No symbol table info available.
#6  0x2b255a0f282d in indicate (data=0x2b27ce162a38) at chan_pjsip.c:1021
packet = 0x2b27ce7c1188
ind_data = 0x2b27ce162a38
session = 0x2b27cc08e578
response_code = 
#7  0x005acf34 in ast_taskprocessor_execute (tps=0x2b27cc699de8) at 
taskprocessor.c:784
local = {local_data = 0x1, data = 0x2b27cc699de8}
t = 0x2b27ce569f10
size = 
__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#8  0x005b4380 in execute_tasks (data=0x2b27cc699de8) at 
threadpool.c:1320
tps = 0x2b27cc699de8
#9  0x005acf34 in ast_taskprocessor_execute (tps=0x25e1b98) at 
taskprocessor.c:784
local = {local_data = 0x2b24a00025d8, data = 0x2b23905cfc90}
t = 0x2b27ccd99b90
size = 
__PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#10 0x005b5512 in threadpool_execute (arg=0x2b24a00025d8) at 
threadpool.c:351
No locals.
#11 worker_active (arg=0x2b24a00025d8) at threadpool.c:1103
alive = 
#12 worker_start (arg=0x2b24a00025d8) at threadpool.c:1023
worker = 0x2b24a00025d8
__PRETTY_FUNCTION__ = "worker_start"
#13 0x005c03fb in dummy_start (data=) at 
utils.c:1237
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = 
{47436303184768, -1066308947863748480, 47436222724960, 47431745866176, 
47449970585040, 3, -6380310873237176192, -1066309600761823104}, 
__mask_was_saved = 0}}, __pad = {
0x2b23905cfe30, 0x0, 0x2b23413e4850, 0x2b23413e4858}}
__cancel_arg = 0x2b23905d0700
not_first_call = 
ret = 
a = {start_routine = 0x5b5300 , data = 0x2b24a00025d8, 
name = 0x2b23905cfd10 "\200\063"}
#14 0x2b23402b0a51 in start_thread (arg=0x2b23905d0700) at 
pthread_create.c:301
__res = 
pd = 0x2b23905d0700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {47431745865472, 
-1066308947863748480, 47436222724960, 47431745866176, 47449970585040, 3, 
-6380310873197330304, -6380133926661078912}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 
  0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#15 0x2b234114293d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
No locals. 
 
Thanks,
 
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

[asterisk-dev] Asterisk 13.7.0 app PAGE plays participant count

[Ross Beer]

 


 Hi,
 
I'm having an issue with the PAGE feature in Asterisk 13.7.0, when connecting a 
PAGE it says 'there is only one other participant in the conference'. 
 
This shouldn't be happening, I know that PAGE used ConfBridge however it should 
only use this to bridge the call.
 
The options I am using are as follows:
 
Page(,ni)
 
The options should suppress any messages however this is not the case. Is this 
currently a bug with the PAGE feature?
 
Thanks,
 
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] Asterisk 13.7 Dial Timeout - Blocker

[Ross Beer]

Please ignore my previous message, I've found the issue.
 
From: ross.b...@outlook.com
To: asterisk-dev@lists.digium.com
Date: Tue, 26 Jan 2016 10:10:38 +
Subject: [asterisk-dev] Asterisk 13.7 Dial Timeout - Blocker




Hi,
 
The Dial Timeout is not working for PJSIP channels in Asterisk 13.7, can this 
be confirmed before I open a issue?
 
For example when using the following command from Realtime the call never stops 
ringing.
 
Dial(PJSIP/100,10)
 
Thanks,
 
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
  -- 
_
-- 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 13.7 Dial Timeout - Blocker

[Ross Beer]

Hi,
 
The Dial Timeout is not working for PJSIP channels in Asterisk 13.7, can this 
be confirmed before I open a issue?
 
For example when using the following command from Realtime the call never stops 
ringing.
 
Dial(PJSIP/100,10)
 
Thanks,
 
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

[asterisk-dev] Re-open ASTERISK-25457

[Ross Beer]

 Hi,
 
Can we please re-open issue ASTERISK-25457, the issue is still present in 
13.7.0?
 
Previously I tried using SVN and it resolve the issue, the patch was supposed 
to be in 13.7.0 however music on hold is still not being played.
 
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

[asterisk-dev] CDR hangup_handler & ResetCDR

[Ross Beer]

 Hi,
 
I have been working through the issue ASTERISK-25458 and have identified 
another issue with ResetCDR.
 
It appears that the reset sets all variables to their defaults, however the 
billsec variable is not reset and therefore shows a value even if the call is 
not answered.
 
For example I answer a call to play a prompt and the user selects if they wish 
to continue. If they continue the CDR is reset and the call progresses. If the 
far end does not answer the CDR shows the following:
 
duration: 8
billsec: 9
disposition: No Answer
 
I would have expected the billsec to be set to 0 as the call was not answered. 
Is the logic incorrect for the ResetCDR in this situation?
 
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] RTP/SAVP & TLS

[Ross Beer]

 
> Date: Wed, 6 Jan 2016 08:22:34 -0400
> From: jc...@digium.com
> To: asterisk-dev@lists.digium.com
> Subject: Re: [asterisk-dev] RTP/SAVP & TLS
> 
> Ross Beer wrote:
> > Hi Dev,
> >
> > In Asterisk 1.8 Snom phones accept calls when RTP/SAVP is set to
> > 'mandatory' which means that the RTP/SAVP options appear in the SDP 'm'
> > lines. However in Asterisk 13 chan_pjsip, no such lines exist when using
> > 'SDES' encryption.
> 
> The "media_encryption=sdes" option turns on SRTP support and thus makes 
> the media RTP/SAVP. You can also turn on optimistic SRTP support as well 
> using "media_encryption_optimistic=yes" which will use RTP/AVP but 
> include a crypto line. I just checked the testsuite tests for SDP 
> offer/answer and they are passing, I also manually enabled it and 
> confirmed it is RTP/SAVP. You may have a configuration error. Snom devices 
> work correctly when 'media_encryption_optimistic=no', when this is set to yes 
> the RTP/SAVP is replaced: Set to No = "m=audio 41988 RTP/SAVP 8 0 3 101" Set 
> to Yes = "m=audio 36240 RTP/AVP 8 0 3 101" I have updated my configuration to 
> not use the optimistic setting.
> 
> >
> > Therefore Snom phones require this option to be set to 'off'. Should
> > Asterisk 13 be offering RTP/SAVP in the same way as chan_sip did?
> >
> > With regards to TLS, devices reject calls if a 'transport=transport-tls'
> > is specified. Is this also a bug as it appears that Asterisk doesn't
> > re-use an active connection in this situation?
> 
> This is a bug in PJSIP which has an issue on our side[1]. If an explicit 
> transport is specified PJSIP will not reuse a connection.
> 
> [1] https://issues.asterisk.org/jira/browse/ASTERISK-22658
>  Great, I can work around this until a fix is in place. Thank you for your 
> assistance.
> -- 
> Joshua Colp
> Digium, Inc. | Senior 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
  -- 
_
-- 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