Linphone is the Best Free Codec App

As you may know, Comrex doesn't publish its own mobile phone codec app. We feel there are so many strong third party offerings we prefer to concentrate on making our hardware codecs compatible with as many of the best ones as possible. Luci Live and Luci Live Lite are examples of good, pro-grade apps that talk to our codecs. But some users feel that if an app isn't free, they don't want to try it.






There are good apps in the free realm, but they've generally got one or two drawbacks like:
* G.722 only
* Not iPhone compatible
* Require registration to a SIP provider
* Not really free (require in-app purchase for wideband)

Now that ACCESS and BRIC-Link codecs support Opus, we can recommend Linphone, available for iPhone and Android, as our preferred free app. It doesn't have any of the previous drawbacks, and works great. See our new guide on how to configure Linphone.

Connect to ACCESS and BRIC-Link from any computer

With absolutely no software installation required.

Update 7/30/14: A new, easier way to do all this has now been posted, along with technotes for ACCESS/BRIC-Link and STAC-VIP.

I've been teasing Opus and WebRTC for awhile, and I'll have a lot more to say about it after NAB. But until then, let me leave you with an experiment. This will allow you to run a remote broadcast from pretty much any computer (or Android phone) to your ACCESS or BRIC-Link codec using the Opus algorithm via WebRTC. It's also a great exercise in getting familiar with WebRTC. Here's the instructions:

1) You'll need to upgrade your codec to firmware 3.0. Beware this is an unreleased beta test version, so there could be unknown bugs. ACCESS Rack firmware is here and BRIC-Link firmware is here. Instructions on how to upgrade are on our support page.

2) Go to http://ekiga.net, and apply for a free SIP address. You'll be emailed a username and password. Note we would normally recommend our favorite free SIP provider, getonsip.com, but their addresses are incompatible with this service.

3) Enable your codec to accept NACIP/SIP calls.  This is the option that lets you accept calls from other codec brands. It's found in the System Settings Tab (advanced options) under N/ACIP SIP Settings->Accept Incoming Connections. Click "enabled". (Hint--uncheck this after use if you don't want your codec to answer random incoming SIP calls)

4) Also on the web UI, enter the SIP parameters for your ekiga.net account:
* Use SIP Proxy -> enabled
* SIP Proxy address-> ekiga.net
* SIP username -> <ekiga supplied username>
*SIP Password -> <ekiga supplied password>

Once applied, you can check registration status on the  Connections tab. SIP Status should read "online (200 OK)".

5) Go to http://click2dial.org and choose "sign up". Give a valid email address, and you'll receive an email with two pieces of information:
* Your login password
* A web link. Copy that and store it somewhere. This is what you will send to anyone you want to connect to your codec.
You'll need to validate your click2dial account via the link provided.

6) Go back to click2dial.org and log in with your email address and password. Go to "My Account", and under step 1, choose "add a SIP address". Enter the ekiga address in the following format: sip:<user_name>@ekiga.net

7) The only other thing to worry about is whether the SIP RTP ports to your codec are open. If you're on the public Internet with no router or firewall, you're good to go.  If not, and your router isn't kind to SIP traffic, you may need to forward UDP 6014 and 6015 to your codec.

8) To connect, you'll need a computer with a speaker and a microphone. WebRTC won't function without a mic on the dialing computer.  A USB headset works best, but WebRTC also has a built-in echo canceller if you're using a laptop speaker/mic. Open Chrome or Firefox and go to the link provided by click2dial. You'll be prompted for permission to use the mic. When you allow that, you should establish a nice, low delay, full-duplex Opus audio link to your codec! Even works on Firefox and Chrome for Android. Sorry, no support for iPhone (ask Apple to support WebRTC!)

Let's have a little fun with this. The first user who successfully completes an Opus call from a browser, and sends us a screenshot of the codec's web UI showing a successful Opus call, gets some nifty Comrex swag. Send your screenie to techies@comrex.com. I'll make an update here when we've gotten the winner.

Update 5/5/14: The challenge has been met! Also I updated the Comrex firmware links to the latest version, which fixes a few WebRTC-related bugs.

Update 7/30/14: A new, easier way to do all this has now been posted, along with technotes for ACCESS/BRIC-Link and STAC-VIP.

Here's some of the fires I've been putting out this week

In my role as chief first-responder to technical "fires", I thought it might be interesting to share a couple of the typical glitches we hit here day-to-day. These concern our VIP-QC app, which was designed to be the world's simplest high-quality mobile streaming app. VIP-QC allows "one-button" connect to participating stations that use the STAC-VIP talkshow system.

First, all of a sudden I got word that the app was working fine on phones that are connected via Wi-fi but failed when on the Verizon Wireless network. Weird, right? The answer was in getting packet captures of what was leaving the phone and what was arriving at the STAC-VIP. Here's one of the lines in the "SDP" header, which defines a lot about the outgoing call you wish to make. This is what we sent:
o=MxSIP 85321307875255471 85321307875255472 IN IP4 74.94.151.146
and here's what got through to the other end:
 o=MxSIP43039135937389542286 3039135937389542287 IN IP4 70.192.23.167

So the working theory is that Verizon is processing SIP calls through their wireless networks through an "ALG" that alters a lot of the information sent between devices. This might not be all bad if it works, but if you look closely you'll see the network badly "munged" the line, losing a space and reducing six fields to five. Any device trying to interpret that will fail.

Beyond that, there's also a reported issue that the app now fails when the STAC-VIP you wish to call is registered with our preferred provider, OnSIP. OnSIP is great because they handle the problem of NAT translation very elegantly, and offer free accounts at getonsip.com.

This is a little deep in the weeds, but the problem appears to be with what should have been a benign change with OnSIP accounts. One of the things about our app is that it's extremely simple--no SIP registration is required on the app side to make it work. It just blindly dials any SIP URI programmed as associated with a particular station. This works fine with OnSIP, as they accept calls to SIP addresses without the user needing to be registered on their network (this is fairly gracious behavior and not all providers support this, but it makes the VIP-QC app work).

Like a piece of mail, a SIP call has a destination and return address. Because VIP-QC doesn't register, it creates a dummy "from" address by copying parts of the "to" address. So if it's calling gary@vipuser.onsip.com, the "from" field is set to <mac address of phone>@vipuser.onsip.com.

The change OnSIP appears to have made detects when a call is made from an OnSIP user, and challenges for a password. If the "from" field says it's from a non-OnSIP account, the call proceeds normally. Since VIP-QC made up the dummy OnSIP account, it aborts the call when challenged.

How do we fix these issues? We're working on hacking the app a bit to work around both. Hopefully, we'll have an update soon. In the meantime, try to avoid Verizon Wireless and OnSIP as provider for VIP-QC.

The Porcupine Hat

It's the internal working name for this:

Our thinking on LiveShot has been pretty consistent--with the advent of 4G, a pair of modems should be more than enough to get to the "sweet spot" of 1-2Mb/s for live video. But we've been up against two things:

1) Areas of the world where 4G is not yet deployed

2) Folks who simply believe more is better and will not try LiveShot without more modem support

The hat (officially called the "LiveShot Hub") clips to the top of the present LiveShot and provides a distributed row of USB ports at varying heights.

It's been a concern of ours since LiveShot early development that multiple modems have enough "spacial diversity" to prevent degradation of one modem's receiver while the other is transmitting. As you can see, the design of the hat allows for up to six modems to co-exist in a small space, while providing a maximal difference in space and orientation to allow lots of options for each modem's polarization. We'll be demonstrating it at NAB next month and shipping it this summer.