Jeremy Gault . com https://www.jeremygault.com VoIP, Broadcasting, Voice Production, and Engineering Sun, 20 May 2018 20:33:01 +0000 en-US hourly 1 https://wordpress.org/?v=5.0.1 136641018 HOWTO: Use Icecast as a backup STL for Nautel transmitters (Part 2) https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-2/ https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-2/#respond Sun, 20 May 2018 20:33:01 +0000 https://www.jeremygault.com/?p=208 Continue reading "HOWTO: Use Icecast as a backup STL for Nautel transmitters (Part 2)"

]]>
In the last post on this subject, I walked you through how to setup your Nautel transmitter to pull audio from an Icecast server. This can be used on a permanent basis if your station does not have a terrestrial microwave or T-1 link normally used as your STL. However, since the quality of Internet connectivity can vary, some stations do prefer to have a non-Internet link for STL purposes.

That said, you can still use the Icecast server as a backup to your normal STL. This works for us because our normal streaming service (for our website and various apps) uses Icecast, at a high bitrate (192Kbps MP3.) We simply tie the Nautel to that stream as an additional listener.

Once you have two presets (STL and Internet) configured, you can switch between them at-will, or as needs arise. However, it is also possible to configure your Nautel to switch automatically in the event of an outage.

In this HOWTO, I’m working on the assumption that you have a terrestrial microwave link for your STL (although satellite links can work as well), which you wish to use as a primary feed. Your Icecast server will serve as a backup feed. (Of course, it wouldn’t take much to adapt this HOWTO to use Icecast as your primary, and your regular STL as a backup instead.)

These directions make one very important assumption — and requirement. When there is a failure of your normal STL, it must fail silent. If it fails to static, your transmitter will sense modulation and never switch over. If you have an analog STL that’s failing to something other than static, you may have to adjust the squelch of your receiver(s). Again, you want any failure in the link to fail to silence, not static, tone, or anything else.

To configure automatic failover to your backup source: Log in to your Nautel AUI. Click the Menu button at the bottom of the AUI, and then Presets. Click Load and then select the preset corresponding to your primary STL’s audio input, and click OK. This will load that preset into the editor.

Click on the Other Settings tab. Set the Mod Loss Timeout to enabled.  This will expose a few other options which you will need to configure.

In the Action field, select “Change Preset.” For Mod Loss Preset you will want to select the preset you created for your Icecast server. (If you do not have one, read my previous post for information on how to do this. Set it up and verify that you can manually switch to it and have audio on-air, then come back here.) For Timeout Minutes, I recommend leaving it at zero. (More discussion on this later.) For Timeout Seconds, put a reasonable value in (I use 30.) Set the Threshold to something reasonable (I use 60, but more discussion on this later.)

Once you have these values set, click Save on the left to save the preset. Then use the preset dropdown at the top of the AUI (below your TPO reading) and select the preset, and click Activate to make it active. Note that even if the preset was already active when you started editing (and saved) it, you will still need to activate it again for your changes to take effect. (This holds true anytime you make a change to the preset that’s currently active — and not the “Current Settings.”)

As I mentioned earlier, you’ll need to set an appropriate timeout and threshold:

The timeout you specify is the amount of time the transmitter’s modulation must be below your configured threshold before changing to the Icecast preset. Keep in mind that a failing STL may drop in and out. I originally used a two-minute timeout, but immediately changed that when I heard rain issues causing the station to be silent for 20-30 seconds at a time, with the occasional 2-3 seconds of audio popping in before dropping out again. Obviously, the station was unlistenable for most, but it wasn’t hitting that two-minute threshold. A two-minute timeout will ensure you don’t switch to the Icecast server unless your STL is truly dead, but you risk (depending on the issue) having a period of time where the signal is unusable. I decreased my timeout to 30 seconds, and left it at that. The drawback being a board-op who misses a break during your local high school football game because he/she went to the restroom may cause your transmitter to switch to Icecast. You’ll have to decide what value is acceptable here.

The modulation threshold you specify is also important. Keep in mind that a dead STL may not drop to 0% modulation. For example, in testing I simply stopped our automation system’s audio output, and found that the transmitter was still showing 40-50% modulation. Mind you, the STL was still up, and perhaps muting during a signal loss on the STL would bring it below this, but you may want to set some kind of value here in case you don’t end up with a totally “silent” link. The modulation will have to drop below this threshold for the timeout duration before the preset will switch. I am set to 60%, but again, this is a decision you will need to make for your use case.

One other important item to note: If your transmitter switches to Icecast, it will not switch back to your STL automatically upon return of audio on that link! At first, that seems a bit annoying. However, if you’ve failed over to Icecast and your STL starts coming back intermittently, you really don’t want to flip flop between two feeds. That’d just sound horrible! So, once your STL is restored, you’ll have to manually log in and switch presets. This also applies if a board op misses a break cue in the restroom during a high school game, as well. (You may be able to fudge the modulation threshold if you can determine enough difference between a sleeping board op and a dead STL, but this is left as an exercise for the reader.)

On a side note: If you use the “RF Inhibit” action for modulation loss, it turns out the transmitter will bring up the RF stage whenever audio is restored.

As I mentioned in the last post, I spent a while tinkering with all this and figuring out how to make it work, without finding a whole lot of documentation on the subject (and some of it was just simply out-of-date, which led to me not finding things.) Hopefully this helps someone out there who’s setting out to do the same thing I did.

]]>
https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-2/feed/ 0 208
HOWTO: Use Icecast as a backup STL for Nautel transmitters (Part 1) https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-1/ https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-1/#respond Sat, 19 May 2018 22:56:24 +0000 https://www.jeremygault.com/?p=200 Continue reading "HOWTO: Use Icecast as a backup STL for Nautel transmitters (Part 1)"

]]>
Anyone who’s done any broadcast work can tell you that STLs aren’t perfect. Whether you’re using microwave or T-1, at some point, you’ll have an outage. I’ve run into this recently with one of our stations, where we apparently have a water intrusion issue on our link somewhere. Get the right amount of rain, and you’re off the air (or at least, broadcasting The Sound of Silence…)

One of the nice things about Nautel transmitters is their ability to pull audio from an Icecast or SHOUTcast server. I’d looked at this before, but never was able to figure out exactly how to make it work from the documentation provided. I recently sat down and started toying with it again, and successfully made it work.

This post will be the first in a two-part series. We’ll first set up a Nautel transmitter to pull its audio from an Icecast stream. In the second part, we’ll discuss how to make this work in a backup/failover configuration.

Before we start, you’ll already need to have a working Icecast stream of your station. Setup of the streaming server and encoder are beyond the scope of these posts, but I’ll recommend you use butt as your encoding software and Digital Ocean to host your Icecast server. (Sign up using my link and you’ll receive a $10 credit!) Once you have a working Icecast stream, return here…

Next, you will need to log in to your Nautel AUI over the web. Once logged in, click the Menu button at the bottom of your screen, and then on Audio Player within the AUI menu. Once the Audio Player opens, click on the Streams tab. Then, at the bottom left, click Add.

Once the “Add Audio Stream” dialog box comes up, you’ll want to fill it out with your stream information, like this:

You’ll first want to select the stream type. Once you select the stream type, the field for the URL will appear. You can give a descriptive name. Of course, the URL should be the URL of your Icecast stream. Then click OK.

At this point, the stream (and its information) should show up in the Audio Player screen. Click Menu at the bottom again, then click Presets. This will bring you to the current operating parameters of the transmitter. (At this point, I am assuming you have a working transmitter, on-air, with your presets defined for correct frequency, output, etc.)

While in “Current Settings”, click on Save New at the left. Specify a name for your new streaming preset, and click OK. You have now just duplicated your current operating parameters into the new Preset, but you still must load that preset into the editor. To do so, click Load on the left side, then select your newly-created preset, and click OK. The new preset name should show at the top of the editor, and you can begin making your changes.

First, on the “General” tab, verify your frequency, output power, and mode are correct. Then move to the “Main Audio” tab.

Once in the “Main Audio” tab, verify your Audio Source is set to “AES/EBU 2” , then set your secondary source to the stream you just created. Set Audio Mode appropriately (stereo or mono, depending on your station and stream. If you’re a stereo station but only streaming in mono, you can safely use mono here.) Enable the low-pass filter as desired, and set your Preemphasis appropriately (75us in the USA.) Failure to set this will result in less than optimal audio quality, to put it lightly.

On the left, click the Save button to save this preset.

You should now be able to select the preset from the drop-down at the top of your AUI and activae it. After a few seconds of dead air, you should hear your stream on-air. If not, verify you’ve entered the correct URL, etc.

Note that you may need to edit this new preset and adjust the Digital Level and Audio Mod Adjustment to get your modulation where you need it to be. In my case, Digital Level is set to -5.0dBFS and Audio Mod Adjustment is at 0.0dB which renders audio that is barely distinguishable with what our composite STL is feeding. For reference: My setup is feeding composite out of an Optimod FM 8200 through a two-hop 900MHz link to the transmitter site, and the streaming encoder is fed from the XLR outputs of the same Optimod unit.  My streaming preset’s audio mode is set to stereo (to enable the Nautel’s internal stereo generator when streaming), and preemphasis is set to 75us.

As always, your mileage may vary, but if you’re messing with this kind of thing, chances are you know what you’re doing and can make the proper adjustments.

In part 2, I’ll explain how to failover from the composite STL to streaming, stay tuned!

]]>
https://www.jeremygault.com/2018/05/howto-use-icecast-as-a-backup-stl-for-nautel-transmitters-part-1/feed/ 0 200
FreePBX Distro (SNG7) on Amazon EC2 https://www.jeremygault.com/2018/04/freepbx-distro-sng7-on-amazon-ec2/ https://www.jeremygault.com/2018/04/freepbx-distro-sng7-on-amazon-ec2/#respond Thu, 19 Apr 2018 06:16:06 +0000 https://www.jeremygault.com/?p=192 Continue reading "FreePBX Distro (SNG7) on Amazon EC2"

]]>
NOTE: Special thanks to Andrew Nagy at Sangoma for pointing me to some information that formed the basis of this fix. I had originally created a bug report with a patch that fixed this script, which set the entire thing in motion. Also, this information is being contributed to the community by myself, and the company I own (Voiceopia Communications), in hopes it’ll be of assistance to others. Of course, if you need some turn-key FreePBX stuff, drop us a line!

For quite some time, I have been happily running FreePBX 13 systems (under FreePBX Distro) in the Amazon EC2 cloud without any issues. Once FreePBX 14 went stable, it was the next logical step to set it up to run within EC2 as well, with the idea being to upgrade some of my 13 systems over to it.

Several months of experimentation went by, and I kept running into a common issue: The systems seemed to drop off the network after an hour or so of uptime. Restarting the system via AWS seemed to get things back in order — for another hour or so. Then the process repeats itself.

After spending a fair amount of time on this, as well as reaching out to AWS paid support (who was not able to figure this out, either), I came to the determination that the systems weren’t losing their IP address per-se, but they were losing their default gateway. Thus, they were unable to communicate with anything outside of their subnet within AWS.

To add insult to injury, it seemed this was an issue that happened only within AWS. I was able to spin up the same systems at other providers, as well as within our own virtual environment at the office, and everything worked just fine for months on end.

Scouring the ‘net revealed the problem to be a new “valid_lft” and “preferred_lft” parameter used when binding the IP address to the interface. It was suggested to remove those from the DHCP client’s script (/usr/sbin/dhclient-script) and that would fix the problem. I gave that a try, and sure enough, it worked!

At least until an updated dhclient package was released…

Searching for a more permanent solution, I created a patch file and submitted it to FreePBX as a bug report. I’m fairly convinced it’s an AWS issue, but they were of no help before, so I figured I’d start somewhere.

I’ll let you read the backstory on the bug report if you’re interested. However, Mr. Nagy’s link provided a bit of inspiration: Can I redefine the problem functions in a dhclient hook?

It turns out that’s entirely possible, and that’s the basis of my fix. The path given for “enter” hooks in the link provided is incorrect (apparently there is no dhclient-enter-hooks.d directory), but by looking at the dhclient-script file I was able to figure out where these need to go.

So… how do you fix it?

For the current FreePBX Distro of this writing, you will need to obtain a copy of my dhclient-enter-hooks script at the GitHub repository. (direct download)

Once you have downloaded this script, upload it to the /etc/dhcp directory on your FreePBX system at AWS. Once that’s done, you can reboot your system, or use the following command to restart networking:

ifdown eth0 ; ifup eth0

Note that you must execute that all on one line — otherwise you’ll lock yourself out of your server.

Once that’s completed, run: ip addr

Pay attention to the output for eth0. It should look like:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.xx.x.xx/23 brd 10.xx.x.xxx scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2600:1f18:4550:xxxx:x:dead:beef:cafe/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::418:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

Pay attention to your system’s inet and inet6 addresses, in particular the “valid_lft” and “preferred_lft” values. If they say “forever” as above, then you have successfully applied the fix. If they show a numeric value (which will decrease when you re-execute the command), double check that you named the script “dhclient-enter-hooks” and saved it into /etc/dhcp on your system.

The fix you apply here should survive updates to the dhclient package from upstream.

]]>
https://www.jeremygault.com/2018/04/freepbx-distro-sng7-on-amazon-ec2/feed/ 0 192
“NO LAN CABLE” error on Grandstream? Try this! https://www.jeremygault.com/2018/01/no-lan-cable-error-on-grandstream-try-this/ https://www.jeremygault.com/2018/01/no-lan-cable-error-on-grandstream-try-this/#comments Sat, 06 Jan 2018 19:55:46 +0000 https://www.jeremygault.com/?p=176 Continue reading "“NO LAN CABLE” error on Grandstream? Try this!"

]]>
(NOTE: If you’re impatient, there’s a TL;DR at the bottom of the post, but it may not make much sense to you without the rest of the information in the post. Skip there at your own risk…)

A bit of backstory…

For many years, I’ve used the venerable Cisco SPA508G IP phone as my daily driver on both my home and office desks. Throw in a Cisco SPA500DS digital sidecar, and it’s a golden setup. Plenty of keys for speed dialing, other extensions, etc. and all of your sidecar labeling is controlled from the provisioning server — no more fooling with paper inserts!

As such, I’ve always used that setup as my benchmark when evaluating new IP phones for possible use with my customers. The Cisco equipment is solidly built, reliable, sounds great, and is fairly easy to work with.

A year or so back, I started evaluating more “modern” phones with features my customers would like to see, such as color screens, gigabit Ethernet (for passthrough to computers, etc.) I’ve tried phones by Sangoma, Yealink, and probably a few other vendors. The audio quality on the Sangoma, frankly, sucked. I tried to work with them on getting that fixed, to no avail. I can’t remember what happened with the Yealink or others — but in the end, the Cisco setup always ended up on my desk.

Enter Grandstream…

Back in the day, I used to deploy 2-line Grandstream ATAs. There’s probably one or two still in service on my network out there. More recently, I’ve deployed a few high-density (32-48 port) Grandstream ATAs for customers who needed a lot of analog extensions. Thus, I’m at least somewhat familiar with their equipment, and the fact that it has its quirks at times, but is reliable and definitely production-ready.

Long story as to how it happened (that’s for another post!), but I ended up trialing some Grandstream IP phones. My experience was the same: They have their quirks at times, but nothing that’s a show-stopper like some of the other brands I had tried.

As I tell people who ask about phone models: Is the Grandstream a Cisco? No. Is it still on my desk all these months later, used as my daily driver? Yes. I can’t say that about other brands of phones. So, obviously, Grandstream did something to impress me…

Until, the problem…

I started noticing that when I moved my Grandstream phone around on my home office desk (my primary work location, so I use it the most), I started getting a “NO LAN CABLE” error pop up on the display. All of my extensions would lose registration with their respective PBXen, and I couldn’t make or receive calls. Furthermore, if I was on a call when this happened (great when you’re talking to customers!), the audio just… dies. The call still shows up on the screen, timer runs, but you can’t hear them, and they can’t hear you.

To add insult to injury? My phone is powered via Power-over-Ethernet. That’s right — it’s missing its LAN cable, but it’s still powered on.

So, what did I try?

The  LAN cable I was using at the time was a custom cable that I had made years ago for some other project. It may have even been solid, not stranded, cable. Since the problem seemed to occur when I moved the phone, or jiggled the cable near the end, my first idea was to re-end the cable.

That didn’t work.

So, I decided it must be a break in the cable. I cut about six inches off the cable, installed another new end.

That didn’t work either.

I decided to just condemn the cable, and pull another 10-15 feet off my new(er) spool of cable, and start from scratch. Cut myself some slack, threw ends on it, put it into service.

Guess what? That didn’t work, either.

Obviously, it was the phone. Grandstream must have sold me a bum phone with a bad LAN port. No biggie, we have plenty more at the office, I’ll swap it. And I did.

Guess what? That seemed to work at first, but then I noticed the same issue crop up on short order. Same error would pop up.

Now I’m starting to get just a tiny bit disappointed with Grandstream, and pondering how to re-integrate my Cisco stuff into my daily life… I hated the idea — I’ve really started to like this phone, but I can’t have my calls being dropped like that, nor my phone going unavailable.

Then it hit me (and here is the fix…)

The other morning on the way to work, I had an epiphany. What if the problem wasn’t the LAN port… nor the first cable I re-ended twice, nor the new cable I made, nor my job of installing the ends (my success rate in installing ends is rather high, to be honest.) What if the problem was the actual RJ-45 connector I was installing on the cable? What if it was made in some Chinese factory in a land far, far, away, where specifications, standards, and tolerances have never been heard of? And what if Grandstream sources their LAN ports from the same place, who has never heard of these things? And thus you end up with a combination of LAN port and cable that has enough “wiggle room” to allow the data pins (1/2/3/6) to lose connectivity?

Luckily, I had a pre-made 15-foot Ethernet cable with molded ends in my laptop bag. I carry it around in case I need to cable up to a customer’s network, I’ll have a cable with some length to work comfortably. I decided to bust out that cable, connect it between my switch and the phone (same ports on both ends, of course), and guess what? PROBLEM SOLVED!

TL;DR…

If you get the “NO LAN CABLE” error, try replacing the LAN cable. If it’s a LAN cable you made yourself, use a store-bought one. If it’s a store-bought one, try one of a DIFFERENT store-bought brand. There’s a decent chance this fixes your problem. (For “why”, read through the rest of the post above…)

 

]]>
https://www.jeremygault.com/2018/01/no-lan-cable-error-on-grandstream-try-this/feed/ 1 176
2018 New Year’s Resolutions https://www.jeremygault.com/2018/01/2018-new-years-resolutions/ https://www.jeremygault.com/2018/01/2018-new-years-resolutions/#respond Wed, 03 Jan 2018 01:46:16 +0000 https://www.jeremygault.com/?p=161 Continue reading "2018 New Year’s Resolutions"

]]>
Welcome one and all! It’s 2018! Yeah, I know, we’re actually a few days into 2018 at this point… However, I’ve been a bit under the weather (to say the least) for the past week or so, and I’m just now starting to get back to my usual self. (Apparently my body doesn’t like this constant warm-cold-warm-freezing weather shenanigan that is going on, especially with these teens and single-digit temperatures this week!) For one, it’s completely killed my voice, which has made life interesting considering I work in broadcasting as well as do voice production. I digress…

At this time of year, everyone is busy making New Year’s resolutions. Okay, so by this point in the year, most “normal” people have already had their resolutions made for about 48 hours, and are well on their way to forgetting about the remaining one or two of them they haven’t failed on yet. But, anyone who knows me, knows I’m far from being a “normal” person. Thus, I’ve taken the time this year to think through my New Year’s resolutions. The goal: Make some resolutions I feel like I’ll actually keep, make them public, and stick to them — even if it means making them a few days “late” so-to-speak.

And now… I present to you… my 2018 New Year’s resolutions!

Okay, so there should have been some kind of applause sound in there, but oh well… I’m too lazy to dub one in. Maybe that means I should make laziness and procrastination my first resolution of the year? Here they are…

  1. Read the Bible more. Yes, seriously. You should, as well. Every day. At least once. And, if you already do once, do it twice.
  2. Have a better walk with God. This ties in to #1. Again, you should, as well. If you haven’t made your resolutions yet, include these two. If you have, well, add them to your existing ones if they aren’t there already. Make them your top two.
  3. Stop caring about what others think. Most people don’t like me. Most people don’t like much of anything I do. There are ideas in this world that get thrown by the wayside if I propose them, but would be adopted in a heartbeat so long as someone other than me proposes them. I get that. However, this year, I resolve to stop caring about that. Either you like me or you don’t. If you like me, great, you can run with me. If not, then you can do your own thing. But, life is too short to care about what others think, try to bend yourself to make them happy, etc. Thirty-six and a half years of life have taught me that.
  4. Share publicly. Yes, I have knowledge. Yes, I have opinions on just about everything. Yes, I make discoveries that are useful. Those are all usually shared within my circle of friends and co-workers, admittedly, most on Facebook. Nearly all of my posts for quite sometime on Facebook have been set to “Friends” — and while that’s fine for some stuff more personal in nature, there are things I have to say that would be valuable outside of my circle of friends. So, I’m no longer setting all my posts to “Friends” — anything that might be worthwhile to the public at-large will be posted as such. Also, I’m not going to restrict myself to Facebook (or even Twitter) as my only posting platform. Either one of those could go away tomorrow if their business interest changes. Why let some corporation control your communications platform? This website is run by me. Sure, it’s hosted on a server somewhere, but should that company choose to shut it down, I can always re-publish the content on a server elsewhere (or publish it on my server at home.) The same URL will work regardless of where I host it. Anything valuable enough to be shared with the world is valuable enough to be shared over a platform which I control. Expect to see more blog posts here. I’m shooting for three a week. No promises, but I’ll try.
  5. Step up my “cyber security” a few notches. This isn’t to say that I haven’t (or don’t) pay attention to security. I’m one of the more security-minded folks you’ll find out there. However, I don’t care how security-minded you are, you can always do better. This goes for my website. It also goes for my network at home, at the office(s) I manage networks for, etc. Things like more granular access control for user accounts, network access, etc. Securing all web properties I own or help manage (namely, enabling full HTTPS for all sites.) I’ve already enabled a lot of sites to HTTPS-only in 2017, and that’ll just continue as this year progresses. (Honestly, if you manage a website, you need to look into that as well, as many browsers will soon start labeling HTTP-only sites as “Not secure” to your visitors. I know, I know… SSL certificates and dedicated IPs are expensive. Two words: Let’s Encrypt and SNI.)
  6. Grow my voice production venture even more. Yes, I do voice production. Links for that are all over this site. I want to grow that more (a little money on the side never hurt), perhaps upgrade my studio a bit. Why not?

And, there you have it folks! We’ll see how this venture into 2018 goes. I feel confident that it’ll be the best year yet, though! Go Raiders!

]]>
https://www.jeremygault.com/2018/01/2018-new-years-resolutions/feed/ 0 161