Its no secret that ISDN has been on its last legs for a few years now, at least here in the US. In Europe and other parts of the world, its alive, well and having cocktails and tanning as I write this.

In my area (Metro NYC), Hurricane Sandy so battered us that, again as I write this, and probably well into future so many people are still struggling to get to the next “normal”. Studios in particular I’m told – that are in the downtown area have had many, many problems with their copper-line infrastructure and by proxy ISDN service. I decided not to wait until Verizon (who is my ISDN Carrier) up-ended service, or decided to up charge my service as a premium making it so cost-prohibitive, that I’d be forced to find reliable ISDN alternatives – probably at a time I need this type of service most.

Enter the Codecs
As usual, I dove in head (and heart) first into the Audio IP Codec market. I did a fair amount of research prior to buying the Telos Z/IP One IP Codec. Currently, in addition to my Phone-Patches (bluetooth and ¼), and Skype, I also use Source-Connect. As many talent will affirm, Source-Connect will bit rate you (attempt to keep you connected factoring in dropout and jitters) at almost 64k max depending on your up/down ISP bit rate. While this is certainly acceptable audio-quality. We also know that 64k version is a VO talent vanilla version, and in order to push that audio-package bit rate higher we’d need the “Pro Studio Version” at about double the price of the individual. But the real problem for me is the whole “Source-Connect only plays with Source-Connect” thingy. In 2013 technology neutrality (I will be using this word – neutrality – more than I care too) is really where it’s at. If smartphones can negotiate interoperability, why can’t other technologies? Now quite frankly on my basic days, I’m just happy that the stuff works. Some days I go into my booth to record an audition, and the very same setup I used not more than 17 hours ago – no longer works. So nope. I don’t look gift horses in the mouth. Anyway, back on topic.

Software IP Codecs (Source-Connect)
I could find no way to get a Source-Elements (Source-Connect) connection with other IP audio devices. Dave Immer up at Digifone – who as all things audio connection guru – has ways to “Bridge” Source-Connect and ISDN lines together for interoperability as far as I know. But I wanted to “in the name of device neutrality” find a widely compatible solution to audio over IP. While I have spoken with Dave many times, he was not queried for this particular piece.

Now at this point I sense a good deal of the “Luci Live/Studio” force, and you would be right when it’s mentioned in the context of “Mobile” solutions for me. But I wanted to focus on two things: Hardware and In-Studio IP solutions. So, realizing that (1) I have never been supremely fond of tracking sessions on my end (via Skype or Phone-Patch direction). And (2) that I needed an In-studio solution that allowed the Production end to track the session, much as we do with ISDN. It was clear that Source-Connect did not, and as far as I can tell will probably not create viable ways to initiate sessions outside of the SC interface setup (as fas as I know). It was also clear I needed to figure this “IP device neutrality” thing out so in the end I’d have a viable ISDN alternative should it be required.

IP Audio Compatibility Quest
The plan was simple enough: reach out to all the major Audio IP Codec manufacturers to ask the (what I thought was a simple) question of:

With your device, is it possible to achieve the same or comparable broadcast audio quality that I now get via ISDN with connections to other IP Codec manufacturers? Or, in the alternative – the minimum stream from my Musicam Prima LT that sounds great pre and post production work is: MPEG L2 128k JS/Mono, and I need to achieve that same quality via IP Codec.

What I found was very interesting.
Codec device manufacturers, much like any kind of tech company hold their cards very closely to their chests. Being inherently proprietary, every manufacturer wants an advantage in the hard-fought land of R&D. That being said, there are myriad IP technologies out there, mostly proprietary and unique to the independent devices: ACT is a Telos technology, FEC is an correction error technology developed by Tieline. There are many, many others. All essentially doing the same thing more or less. They rearrange or do a simple (or most times complex) plus or minus redundant send/receive protocols (I’m an idiot, and more creative than Tech, so I’ve grossly over or under-simplified it) so that audio packets can be buffered for bad IP connections and dropouts, drop-offs, or jitters.

Every device manufacturer can guarantee QOS agreements and pristine connections when it comes to interoperability between their own peer-to-peer devices. But get individually branded devices to work together and, well… Not so easy.

EBU and N/AICP

Enter the EBU (European Broadcasting Union) the organization states it is a: “Professional association of national broadcasters that negotiates and advocates for interests of public broadcasters in Europe”. They function to do a lot more than I care to address here, but suffice it to say, most of the major players in the Audio IP Codec game and that would include Comrex, Mayah, Tieline, CCS (Musicam), APT, and AudioTX all sat down to develop standards for device manufacturer interoperability. It seems no one wanted a repeat of the original ISDN Codec fiasco whereby devices “we not playing nicely” with one another. The standards that came out of the development meetings bourne (am I using this context correctly?) the features we now take for granted when we dial out, or are dialed into on our ISDN Codecs: Auto-Negotiation.

SIP Auto-Negotiation
To me one of the single-most important implementations to come into existence for ISDN codecs is the Auto-Negotiation features. Think about it. Imagine not being able to connect to someone via a call on your smartphone, because your smartphone is an Android, and the party being called has an Apple device. I know, it makes noooooo sense. So, this body, the EBU along with NAICP – I’m told – refereed standards for device compliance and compatibilities – specifically SIP implementation. Telos – I’m also told through many sources – declined to participate at the EBU Meetings. This might be the reason that the Telos ZIP One may not be fully compliant with EBU or NAICP standards. Which brings us to the next point. This “standard” takes advantage of a technology referred to as SIP – Session Initiation Protocol. If you’ve ever used Skype, VoIP, Google Voice or any of the many SoftPhone devices, then you’ve used the SIP technology. SIP essentially initiates a call and “introduces” itself via various handshaking protocols: “Hello, I’m 124.11.111.2 AAC-HE, or MPEG L2 @ at 128kbps – Ya got a minute, can we talk”? There are many algorithms (code for compression models) from AAC to MPEG 2 and 3, to PCM, even down to G.711 and G.722 (Both which are essentially the equivalent resolution/quality of a regular phone-quality call). As a voice talent, my sessions need to be the same or better quality that I currently achieve with ISDN – that was the ultimate test.

Reaching out…
I reached out to Telos on several occasions. Disclaimer: I bought a Telos ZIP One Codec on the strength of its Brand name, IP interoperability with its Zephyr product line, and its supposed NAICP SIP-compliance. On first contact, I found that this device was primarily for the RADIO STATION community who do the on-off site calls “live” back at the station.
Oh, and LUCI LITE or LIVE can NOW work (several rom updates to 1.7.0 later) Very subtly I was informed that this device wasn’t really developed for the “Voiceover” community. Made sense I guess. Why on earth would they want to cannibalize their ISDN product lines? Another important trend I found disturbing was, and this was consistent among all the device manufacturers, that each company had basically its own “SIP-server”. When you bought a device, you registered the device online with a manufacturers server to effectively “see” other (place brand-name here) devices made by that specific manufacturer. In the case of Telos, it was a “little happy ZIP One Radio Station community”. Now in addition to using the SIP-Server, I was told I could setup an Asterisk PBX on a spare computer and use it as a through-line for SIP registration. All of which did not strike me as easy or necessary to have to do. There’s more: That Zephyr IP compatibility I mentioned above as one reason in deciding on as a factor for the purchase and thought of as a feature, requires a Studio (which by all accounts) currently uses that same Zephyr device as the ISDN codec they’ve come to know and love as a tethered ethernet IP Codec (which the Studio may not even be aware of) would require a Software revision BEFORE it can achieve IP viability. Can’t make it up. In a roundabout way, it was also inferred that I might mention to the current studios/producers/directors I work with, that if they too purchased a ZIP one we could end ISDN sessions almost immediately given the point-to-point SIP-server IP connection we would now enjoy. Thats sound a lot to ask of one person. Essentially, I would be saying to a producer “hey I know my ISDN line is complimentary (I don’t charge for initiated calls) but you pay a ton in per minute charges calling me from the UK. If you went and spent 1100 Euros on the ZIP One, you and I can start sessioning (like that word?) via IP – no more ISDN charges passed on to your client!” Not a burden I want to shoulder, because it means consequently all non-ZIP One IP Codec users would be up “shits creek, without a paddle” as my Mom used to so fondly put it. In the end, I found ways to register for SIP Server Registration through various companies – Iptel and Sip2Sip and but two in the realm of Registrars, and both work quite well.

I don’t mean to sound sour. Nor do I intend to. I’ve since learned how to call/integrate/initiate a call to any SIP device using whatever algorithm I need to connect. No, I’m not happy that as a creative person I’ve had to figure it all out without the help of the company that created the box, but nevertheless it was time well spent.

I will have more on the information as I hear back from Codec vendors. In the meantime:

Have you as a Producer, Voice Talent or Studio used SIP Audio reliably as an ISDN alternative? Meaning connecting via SIP on codec algorithms like AAC, AAC-LE, AAC-HE, MPEG 2, PCM, or even aptX? I don’t mean Luci Live – which I have not properly tested as yet. I’d love to hear your experiences! Better yet, I’d love to test/share an IP connection out as well!

Edit: May 9th, 2014:

I got an email from Robert Marshall of Source-Elements, the maker of Source-Connect. Robert pointed out to me that: “Source-Connect Standard does 96kbps (easily equivalent or better than ISDN’s MPEG Layer 2 @ 128kbps)” Far different from the 64kbps.

Or as I like to call it; The Promised Land. Is MPEG L2 @ 128 the best audio landscape for voiceover? Probably not. But I do know that when I get back copies of voice work that I know were created at that codec bit rate, I’m always impressed. Though shouts go out as well to the phenomenal audio engineers who edit, sweeten, and mix my voice with the work as well.

So, 96kbps is quite different from the 64kbps I talked about earlier.

I’m also in the process of demo-ing another product of Source-Elements, and will write more about that in the Audio IP Part 2 post due July 19th, 2014. Currently waiting for the Telos Z/IP Software Version 2.x. That will fix my broken Connect tab, and SIP Registration. I’m told it will be rolled out by the “summer” of 2014. Whether it “rolls” out in the summer and I can test it or not. I will weigh in on the heavyweights – pound for pound – in the IP Audio arena.

So far, and this is preliminary – the software codecs are winning by a long shot, with two at the top of their game.

See ‘ya with part two of Audio IP Codecs – July 19th, 2014 (fingers crossed)

UPDATE: Audio IP Codecs (Part 2) is Here: