[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

Ross Beer ross.beer at outlook.com
Tue Mar 1 16:07:28 CST 2016


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.joseph at fairview5.com
Date: Tue, 1 Mar 2016 14:02:38 -0700
To: asterisk-dev at lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer <ross.beer at outlook.com> 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.joseph at fairview5.com
Date: Tue, 1 Mar 2016 12:45:28 -0700
To: asterisk-dev at lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer <ross.beer at outlook.com> 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.joseph at fairview5.com
Date: Tue, 1 Mar 2016 11:58:15 -0700
To: asterisk-dev at lists.digium.com
Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241



On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy <mulitskiy at acedsl.com> 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



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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160301/28d646e7/attachment.html>


More information about the asterisk-dev mailing list