Wednesday, September 2, 2015

ACCESS/BRIC-Link 4.0 beta testing

If you're a "cutting edge" type of audio IP codec user, you can now give our 4.0 firmware a spin. It includes the CrossLock VPN reliability layer, which enables the use of multiple networks on a single codec. It also includes support for the U620L modem from Verizon.

4.0 works on all ACCESS Racks, BRIC-Links, and BRIC-Link IIs. It also works on most ACCESS Portable 2USB modems (without the card slot) but you'll need to check with Comrex support to make sure your hardware qualifies.

Monday, August 3, 2015

Verizon's new 4G modem

The modem situation on Verizon's 4G network has not been pretty for the last months. But Big Red has finally introduced a new 4G modem that covers their entire spectrum, deployed and "yet-to-be". It's the U620L and it replaces the "a lot to be desired" 551L modem. It came out in mid-July and we've already integrated support in our ACCESS and LiveShot firmware. LiveShot beta firmware is available now, and ACCESS support is coming in 4.0

Allow me a line or two to whine about USB modems. This is Verizon's fourth-gen 4G modem. So far each modem has used an entirely different software interface, (requiring a firmware update)and a different SIM card size (the U620L uses the Apple-style nano SIM).

Keep making it easy on us Verizon, we love you!

CrossLock is coming to ACCESS/BRIC-Link

We'll be cutting a beta-level release of new audio codec firmware in a couple of weeks.  It will be all about reliability.

As you many have noticed, we've been toiling hard the last few years in the video segment.  It's a lot harder to move video over 3G/4G networks than audio, since it's 10-20 times the digital bandwidth for HD video. So this required that we take a look at how we can stabilize a poor data channel even further. It also required the ability to aggregate multiple IP networks for increased bandwidth.

What we came up with for video was coined "CrossLock". Essentially it's entirely new VPN layer that gets established between your hardware devices. It has all new error correction facilities (including both FEC and ARQ styles) throttling, and the ability to use multiple networks on each end of the link. It's the "killer app" for IP reliability and it's time to deliver it to audio codec users in firmware 4.0

Watch this space for firmware 4.0 release before Sept 1.

Wednesday, March 4, 2015

Are Robo-calls tying up your IP codecs?

Many ACCESS and BRIC-Link users set their codecs to accept incoming SIP calls, which is required for the the system to be compatible with apps like LinPhone and WebRTC. But a side effect of opening these ports is that they will also answer calls from other SIP-based sources.

We are finding an increasing number of SIP-based "probes" or robo-callers, attempting to make connections with random IP addresses. When one of these hits your codec, it will attempt to answer the call. This typically results in a "hang" condition of the codec until the bad-call timer runs out, defaulted at 60 seconds. This is annoying but not usually a major concern.

Until recently, when we've started seeing a persistence of these dialers to hang on to a codec. When the codec disconnects, the dialer reconnects, resulting in a Denial-of-Service like condition. The user generally needs to reboot his system (maybe a couple of times) for the call to completely clear.

So we took a look at the incoming parameters of these calls to see if there was some way to reject them out-of-hand. And we found a series of "user agents" (the name of the software used to make the call) that were common among these calls.

We now have a beta-level version of firmware for ACCESS and BRIC-Link that adds a "blacklist" which defaults to the three most common user agents we have found in these dialers.  The list can be expanded by the user. If you're experiencing incoming SIP calls on your codecs that tie up your system, ask our support department about an upgrade.  You can reach them at techies@comrex.com.

Edit 3/17/15: Firmware 3.0p6, available at our support page for all models, has this fix. And our UML295s are in stock.

Tuesday, March 3, 2015

USB modem situation worsens on Verizon

It seems LTE USB modems are going the way of the Dodo bird and ISDN lines fast.  Verizon recently killed off it's line of Pantech modems, and the remaining one, the Novatel USB551L has a lot to be desired (see reviews from the Verizon site on left).

This is even more so on versions recently purchased from Verizon. We got some troubling reports, and got our hands on a sample.  This modem works fine on a computer, but there's a fundamental hardware timing issue that makes it unable to associate with our ACCESS codecs. It doesn't look like there's any work-around, either. So don't buy these.

We will be announcing a long-term solution to the USB modem issue next month at NAB. Until that solution is in place, we'll be stocking the Pantech UML295 (yes, we got a hold of a limited supply) for sale. This is the only USB modem that can take advantage of all of Verizon's LTE bands. And is hands down the best USB solution we have seen so far. Contact our sales department for more info.

Oh and don't forget the idea of using the ACCESS Wifi modem in conjunction with a hotspot device on Verizon! This lets you share your 4G with a computer in the field.

Thursday, February 26, 2015

AT&T Please fix tower 15932433


We spend a lot of time testing codec performance on real-life 4G networks. We've found several spots in cities that function well as worst-case scenarios, including the vicinity of the White House and Times Square. We've also found a good testing ground closer to home--the Boston Common. It's a wide open spot in the center of the city where you can count on changing cell towers pretty regularly as you walk around.

We had some interesting results yesterday while testing our LiveShot video codec there. We had three modems attached. (for you audio codec users, this capability is coming soon in firmware 4.0) Verizon and Sprint modems were champs, but depending on location our AT&T modem would behave miserably--to the point where it's presence was actually more of a hindrance to the overall stream than a help.

That was actually good news, since we were trying to tweak our algorithms to minimize or quarantine the data from a bad network. But we took it a bit further and started reading the stats on the modem as it entered and exited the "zone of doom". Sure enough, it was a discrete tower switch at the exact moment the channel fell apart.

The above graph illustrates the percentage of packet loss over time in one second intervals. When viewed on the product, this graph moves in real-time from right (most recent) to left (60 seconds ago). It's pretty obvious when you're on the bad tower.

Why is this particular cell so bad?  Is it located in a place where multipath is a problem on the Common? Is there a local transmitter with a spur in the 700MHz region blanking the cell tower receiver? I'm sure bribing an AT&T tech would be the only answer, and none were around.

In case you think this problem is specific to AT&T, we were at this exact location about 10 months ago, and AT&T was flawless throughout the area. But at that time, an identical situation occurred on Verizon, at the opposite end of the test area. Go figure.

Wednesday, February 25, 2015

Is POTS dead?

No profound insights or innovative solutions to talk about today. Just a bit of navel-gazing.

We're getting more and more war stories of broadcasters unable to find a "real" POTS line at a venue from which they need to broadcast. The phone jacks they used to rely on get terminated in a VoIP switch. POTS codecs rely on a very intricate modem balance on a phone line. And VoIP systems treat modems like a weed on a putting green-- A nuisance to be destroyed.

Of course the answer is "Go IP", but that's a pretty cold response to someone who doesn't have the budget for shiny new hardware. And IP codecs are still hot commodities hard to find on Ebay. POTS codecs are relatively easy and cheap to find there (possibly a testament to their demise?)

It's really hard to gauge how rough things really are-- we don't hear about the successes as often as the failures. But at a minimum it seems those who show up assuming that RJ-11 is connected to the CO by a pair of copper wires will be disappointed in short order.