According to popular legend, in the early days of talking movies there was a German director working in Hollywood whose pronounced accent skewed his use of English. He would call for another take of a scene, this time without recording sound. He’d yell out “Mit Out Sound!” Over the years industry professionals came to use the acronym MOS as a shorthand for recording a silent take.
Operating MOS may be occasionally useful in film, but it can be disastrous for a podcaster. When producing a podcast reliable audio is a must. Achieving this goal can be complicated when trying to connect to a distributed array of co-hosts & guests via the internet.
Using a SIP service like SIP2SIP.Info allows the use of high-performance audio codecs, like Opus, which makes for superior podcast audio. This is something that I’ve advocated for along time in my series called Making Use of HDVoice Right Now!
This week I had a Twitter exchange with veteran broadcaster and podcaster Mike Phillips about a problem with audio over a SIP connection.
Mike posed the following question:
“What sort of firewall or router problem would cause Blink not to receive an ACK from another computer also using Blink? Is there way to solve it without router access? It works fine on some SIP accounts but not others.”
His assumption that this problem is network related, specifically about the router, is not entirely off-the-mark. That’s possible, but it could easily be something else. I inquired further, asking it the SIP client was successfully registering. He responded as follows:
“It registers successfully, but the call (to TalkShoe) disconnects after 30 seconds.”
That’s great info! That tells us that the SIP client is registering successfully, and even that media is being passed correctly, at least a first. The media is being lost after the call is already up and flowing. That most often happens when something in the chain is not correctly handling a SIP re-invite.
A re-invite is a SIP signaling process that occurs routinely in the course of a SIP call. It’s the way that the media gets moved between servers, for example when a call is transferred.
Not all transfers are transfers in the classic that-button-on-the desk-phone sense. For example, when you call a conference service the call is answered by a media server that handles the process of greeting and IVR, etc. When the service has determined what meeting you wish to join the call is re-invited to the appropriate live conference.
A call can also be re-invited between different processes on the same server. For example, when a media server senses that a jitter buffer needs to be enlarged. The call is re-invited to a new connection, with a new, larger jitter buffer already in place and ready-to-go.
Andrew Prokop has published a nice overview of SIP re-invites.
Having narrowed the scope of possible issues substantially, I suggested that he try a simple test. The ZipDX wideband demo actually has a couple of re-invite tests. I advised as follows:
In Blink dial firstname.lastname@example.org. After the greeting, press # to switch to G.722. Then press 2. Does the playback continue? If so, press 3, does it still continue?
To which Mike replied:
“The audio disconnects when I press 2.”
That indicates that re-invites are not being correctly handled. There are three possible causes;
- The Dastardly ALGAn application layer gateway on a router is “helping” with the SIP signaling. Most ALG implementations are shoddy. If your consumer router has some “SIP-specific” functionality your best move is to disable that feature. Mike confirmed that the ALG in the router was disabled.
- The SIP ClientThe SIP Client: Blink, which is very reputable application. I was able to load Blink for Windows on my desktop, and prove that it passes both the ZipDX re-invite tests, at least when run from my network. That suggests that the problem is with…
- The ITSP/VoIP ServiceSome element in the ITSPs network could be mishandling the re-invite. You’d hope that this wasn’t the case, since there’s basically nothing that you can do about it. However, when one opts to rely upon free SIP services you must accept that their business model decrees that they will take shortcuts in network architecture to save costs. If the problem is at the ITSP then the only option is to choose a different ITSP.
This got me to thinking about what I mean by “a different ITSP?”
Using a traditional ITSP typically means living with SIP. That includes the requirement for an installable client, and the need to debug these kind of network issues. We’ve come a long way in recent years, and SIP is not the only approach available. Nor the easiest.
WebRTC leverages Opus to deliver superior audio quality. It doesn’t require any installable client software, which means no significant configuration. Further, it’s secure and designed to get around all sorts of network architectures transparently to the user. Many of the WebRTC-based services are free, which seemed to be important to Mike.
There are non-traditional ITSPs, like GetOnSIP, that have come to bridge the SIP and WebRTC realms. This allows you to use SIP where it’s convenient, yet connect to guests by having them use only a browser and headset.
Let’s set aside SIP and too much of a headache. A podcaster could choose a pure WebRTC service, something like Talky.io, as the means by which they connect a guest or co-host. For one-to-one conversation this works brilliantly, with none of the SIP-related network complexities.
As this is getting to be a bit lengthy, I’ll stop for now. In a follow-up post I’ll describe how to use a WebRTC-based service as a simple, high-quality, way to bring a guest or co-host into a podcast. 100% SIP-Free.