[App_rpt-users] Registry re-requests and Audio drop-outs

Benjamin L. Naber benjamin at project23d.com
Thu Mar 23 04:18:35 UTC 2017


Bill,

There is a myriad of reasons as to why you are experiencing audio drop outs.

There are a few things to look at:

1. Your network the Allstarlink node is connected to. Even though you 
may have more then enough bandwidth, TOS/QoS needs to be setup on the 
Internet facing router in order implement a packet queuing discipline.

On my home router, setting only (WAN <-> LAN hostIP) UDP 4569 as highest 
priority, there are zero audio drop-outs or dropped packets, even though 
someone is watching youtube and netflix, while I'm conversing with one 
or several others over Allstarlink.


2. You ISP could possibly be having issues. Case in point: East Alabama 
Cable has very poor network management. Running Wireshark directly 
connected to the cable modem yield several thousand packets/minute of 
ARP requests and other broadcast stuff.... for network hosts NOT 
residing on the customer trunks.

Thus far, with East Alabama Cable, we experience anywhere between 5 to 
17% packet loss regardless of time of day, night, and wee hours of the 
morning.

I have WoW at home, and I *may* see one or two packets dropped out of 
several thousand... even with the kids watching their junk on the internet.


3. Another possibility is the USB host I/O chip on you computer. 
Real-time USB audio is minorly CPU intensive, and if the machine is 
running a lot of tasks,  you may need to adjust the 'nice' levels, give 
the audio related processes, and asterisk, a higher priority. And 
honestly, some computers, usually those with RealTek USB host 
controllers, are more problematic than others.

.......
The registry re-requests, while annoying to see, is your Allstarlink box 
telling the Allstarlink register server your node number(s) are alive, 
and made available for connections. The register process is also the 
authentication of the Allstarlink server to allow your node to make 
outbound connections(calls).


~Benjamin, KB9LFZ


On 03/22/2017 12:17 PM, William Higgins wrote:
> Steve,
>
> I have felt that it was ok. I seem to be able to get to it remotely 
> via SSH at will and I have not noticed any loss of SNMP data.
>
> One more interesting note. I took a look at my simplex multinode 
> (43758 and 43936) here at my QTH and it's doing exactly the same 
> thing.  That system is a mini ITX PC based DIAL system.  The only 
> things these two systems have in common are:  1.) I was the builder, 
> 2.) they're both using RIM LITE style interfaces, and 3.) they are 
> both behind NAT routers (with the appropriate ports forwarded of course).
>
> Bill
>
>
> >William,
> >Have you verified good connectivity from your node to the net? I am
> >watching the reregistration server now to see I can catch any hints.
> >
> >73, Steve
> >
> >On 03/21/2017 05:52 PM, William Higgins wrote:
> > Still on a quest to find out why my repeater node is behaving badly
> > re: audio dropouts, I decided to look with more depth at the events in
> > asterisk.
> >
> > I set verbose level to 6 and saw this recurring pattern.
> >
> > A section of the log output to the console follows:
> >
> > [Mar 21 16:36:58] WARNING[818]: chan_iax2.c:10127 iax2_do_register:
> > REGISTER-LOG: Sending registration request for '44011'
> > [Mar 21 16:37:00] WARNING[822]: chan_iax2.c:7690 registry_rerequest:
> > REGISTER-LOG: registry rereqquest
> > [Mar 21 16:37:50] WARNING[815]: chan_iax2.c:10127 iax2_do_register:
> > REGISTER-LOG: Sending registration request for '44011'
> > [Mar 21 16:37:52] WARNING[818]: chan_iax2.c:7690 registry_rerequest:
> > REGISTER-LOG: registry rereqquest
> >     -- Received OK from Echolink server nawest.echolink.org <http://nawest.echolink.org/>
> > <http://nawest.echolink.org/>
> >     -- Received OK from Echolink server nawest.echolink.org <http://nawest.echolink.org/>
> > <http://nawest.echolink.org/>
> >     -- Directory pgm done downloading(partial,compressed), 394 records
> > [Mar 21 16:38:42] WARNING[819]: chan_iax2.c:10127 iax2_do_register:
> > REGISTER-LOG: Sending registration request for '44011'
> > [Mar 21 16:38:44] WARNING[815]: chan_iax2.c:7690 registry_rerequest:
> > REGISTER-LOG: registry rereqquest
> > [Mar 21 16:39:34] WARNING[816]: chan_iax2.c:10127 iax2_do_register:
> > REGISTER-LOG: Sending registration request for '44011'
> > [Mar 21 16:39:36] WARNING[819]: chan_iax2.c:7690 registry_rerequest:
> > REGISTER-LOG: registry rereqquest
> >
> > After looking at it for a while, I noticed that the time delta between
> > the "registry rerequests" and the following "do_register" is exactly
> > 50 seconds.  Is this normal?  Does it really need to re-register that
> > often or does it indicate a network problem with the Rpi's connection
> > to the outside world?
> >
> > My configuration again is:
> >
> > Raspberry Pi 3 with DIAL RAT_RC1.img
> > Repeater Builder RB-USB Rim Lite Interface
> > Vertex VXR-7000 Repeater
> > Metallic case for the Pi
> > Modular connectors and Cat-7 cable for the interface with snap-on
> > chokes at both ends
> > Pi is connected to the local network via Wifi (We are prepared to move
> > this to Ethernet, but need approval of the host to do so)
> > Pi is connected to an external server via OpenVPN for collection of
> > mgmt. statistics via SNMP
> > Pi also runs Apache2 and Allmon2
> > Echolink is enabled (Node 746074)
> > AllStarLink of course (Node 44011)
> >
> > Thanks for any insight you might be able to lend!
> >
> > Bill Higgins
> > N0NOE
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20170323/0f9c090d/attachment.html>


More information about the App_rpt-users mailing list