[asterisk-users] PJSIP call Delay DNS/Realtime

[Nick Olsen]

Sorry for the top post here.

Joshua, Thanks for the info. I can confirm adding

identify/cache = memory_cache,object_lifetime_stale=600,object_lifetime_maximum=1800,expire_on_reload=yes,full_backend_cache=yes 

ABOVE

identify = realtime,ps_endpoint_id_ips

in Sorcery.conf has resolved this issue. I can also confirm that simple memory_cache was not enough. full_backend_cache=yes was indeed required as you suspected. Thanks!

Nick Olsen
Network Engineer
Office: 321-408-5000
Mobile: 321-794-0763

----------------------------------------
From: "Joshua C. Colp" <jcolp at digium.com>
Sent: 5/16/19 1:59 PM
To: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] PJSIP call Delay DNS/Realtime
On Thu, May 16, 2019, at 2:57 PM, Joshua C. Colp wrote:
> On Thu, May 16, 2019, at 2:54 PM, Nick Olsen wrote:
> > Hello all,
> >
> > I'm migrating a box from PJSIP with normal Flatfiles to ODBC/Realtime,
> > Also 16.0.1 to 16.3.0. After adding a few peers to the new RT box, I
> > noticed a delay in call processing. All I had done thus far is added a
> > few endpoints for upstream carriers, And one downstream for the legacy
> > PBX it was replacing. After a bit of troubleshooting I found the issue
> > to be related to having the identify section matching a domain name
> > (Instead of an IP). Each endpoint with match=domain.name.here (The
> > specific name didn't really matter) added a bit of noticeable latency.
> > Once you were up to 4-5 of them, It was a ~5 second delay from the time
> > the invite came in until the time the call was routed and stood up with
> > audio. Even when you were routing between unrelated (non-dns matched)
> > endpoints. Looking at the debug logs, It seems like Asterisk looks
> > these peers up on some kind of time interval. As well as during _every_
> > inbound call. This also explains why the delay increased with every
> > single DNS based endpoint I added. Each extra peer means another DNS
> > lookup and process.
> >
> > To further test my theory, I stood up a local caching DNS resolver and
> > this significantly improved the delay. But it was still ~1 second with
> > 5 DNS based endpoints. Even with a caching resolver, This doesn't
> > scale. Doing a large number (and growing with scale) of DNS lookups for
> > every call (Maybe even every packet) just doesn't fly.
> >
> > So my questions are:
> > 1. Anyone have any idea why asterisk does this when using realtime but
> > NOT when using flatfiles?
>
> Unless you configure caching for the objects[1] then every time the
> identify object is pulled from the database it has to be looked up and
> resolved.

Oh, and it would need to be full backend caching. Just per-object caching doesn't do the trick because in order to iterate over all the identifies, you need all of them including any uncached ones. The full backend caching on the other hand caches everything so if I recall it doesn't hit the backend in that case.

--
Joshua C. Colp
Digium - A Sangoma Company | 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 --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190516/021a3897/attachment.html>