Some unanswered questions from January 2011 [telecom]

I came across this post from January 1st of 2011, and I'm republishing it, since I'd like to see more discussion on this topic. John Levine answered Sam with some detail, and I'll add some more questions to John's original post, but VoIP remains a "Black Box" to me and so I'm seeking some more info.

I'd add a couple of questions to Sam's original:

1. Why is Comcast's "VoIP" offering _so_ bad? It's got reserved bandwidth, a fatter pipe, and the advantage of a closed system that has known, well-documented interfaces at both ends. What went wrong?

1. What did the "1995 Caller ID decision" involve? Was it ever resolved?

Bill Horne Moderator

----- Forwarded message from Sam Spade -----

To: snipped-for-privacy@> Thank you all for your support and help in 2010. I appreciate your

Happy New Year, Bill.

I would be especially eager to learn how Vonage really works. It's all a mystery to me. Sure, I undersand the transmission method, but I don't have a clue about how they "switch" calls and how they interface into the PSTN. I recall the suits where Verizon (I believe) seriously challenged Vonage for a time, based on Vonage's violation of Verizon patents, or something like that.

Clearing the air on Vonage and VoIP would be great.

Another interesting subject would be the history of how strong the FCC was in the 1995 Caller ID decision, then in subsequent years have seem to lost interest in maintaining the integrity of Caller ID delivery and they never did address the reserved PBX component of the original decision.

----- End forwarded message -----

It depends on what you mean by 'converted to speech'. If you mean 'to an analog voice-grade "POTS" signal', the answer is "no." If you mean 'to a digital encoding supported by the PSTN', the answer is "yes."

Regardless of that issue, 'yes' there is a 'central office' involved.

The 'handoff' between Vonage and the PSTN is a 'pure digital' interconnect, Data to/from a DS-0, or an ISDN 'bearer channel, is transcoded from/to the compressed digital form that Vonage uses. In 'DS-0', or ISDN 'B' format, it can be handled by the rest of the PSTN "just like any other PSTN" call.

There is no concept of switching or voice path in a VOIP call, other than what's inherent in the internet of course. The VOIP device converts the voice signal into IP packets, sent over the RDP protocol. RDP is connectionless, i.e. you just throw the packets at the destination and it's the application's job to assemble them into some semblance of order and deal with missing packets. A VOIP conversation is not telephony in any literal sense - it's internet traffic.

A VOIP provider' servers have two jobs: 1) to maintain the directory; what users are logged into their accounts, and what IP they are hanging out on, and 2) handling the handshaking necessary to traverse NAT on new calls. Part of the directory service may include storing and forwarding voicemail messages if the person being called has dead internet, didn't respond to the call request, or doesn't have their VOIP device running. But that's all optional, and likely extra cost.

#2 can be optional - on Skype for example, you can manually open ports such that you can, once you know the other end's IP (if they have also opened ports) establish a direct connection to the other end without a central handshake. I can't speak for whether Vonage's or Comcast's VOIP offering allows this. I'm guessing not, in fact I would expect that almost everything in the call passes through a central point for CALEA compliance.

VOIP is an internet protocol service and isn't regulated as such. The provider, on the other hand, may inherit some regulatory requirements if they say "we're a phone company". This is one of the reasons Skype and Vonage are very different from each other.

No communications protocol is perfect of course, but SIP is a very, very good one. To sound good though, you need a low-latency, low-jitter internet connection. In years past, this wasn't as common as it is now. *

You probably mean this:

For example: recently (prior to 2011 I think) the FCC declared that VoIP providers which interface with the PSTN are subject to the same "number portability" rules that the ILEC and CLEC providers are. In most cases, a consumer has the right to port a phone number from a traditional telephony provider to a VoIP provider of their choice, and vice versa.

In India, I gather that it takes a specific government license to bridge a VoIP network to their PSTN (even if you aren't providing local phone numbers in that area).

Neither of these apply if you keep the VoIP traffic entirely on the Internet and don't bridge over into the PSTN world.

One of the quirks of SIP which makes it less-than-wonderful to deal with, in practice, is the fact that the SIP protocol specifically includes the IP addresses and TCP or UDP port numbers of the various parties as part of the SIP conversation. This results in all sorts of havoc if the SIP conversation goes through any sort of NAT (network address translation) firewall, because the SIP packet that one party receives may refer to a private IP network number that is not actually reachable from the Internet. As a result, the actual audio/video packet stream (the RTP data) may be sent to an IP address which cannot be reached, or which is ambiguous.

The commonest symptom of this is "I made a SIP phone call, and it appeared to go through but there was no audio (or audio in only one direction)".

Working around this requires some significant flailing and gnashing of teeth, of which several varieties exist:

- STUN - a technique for a SIP client to try to figure out what its external "outside the firewall" IP address and port range actually is, so that it can place the correct information in the SIP packets it sends.

- SIP-aware NAT gateways, which rewrite the contents of the SIP packets "on the fly" to include the correct (translated) IP addresses.

- SIP proxy servers, located in the firewall... the SIP client voluntarily sends all SIP traffic through the proxy process, which does the address substitution and forwards all of the RTP traffic.

- SIP servers (e.g. Asterisk) which can be configured to deliberately ignore the IP address and port information contained in the SIP protocol, and instead substitute the IP address and port number from which the server actually receives the traffic.

- Virtual Private Networks - keep all of the SIP traffic bound to VPN-specific addresses, and let the VPN software stack deal with all of the NAT and firewall issues. None of these is perfect.

There are other protocols (e.g. IAX2) which try to avoid these problems by using a different protocol design.

In my experience, the root problem with SIP is firewall traversal or perhaps more correctly NAT traversal. I am not familiar with the packet level of SIP and the other protocols used to implement the actual 'connections' (e.g. RTP) but it looks rather like the problems encountered with ftp and early NAT devices: the IP address of the client behind a NAT device is not unique and routable over the internet, interfering with the ability to make a connection from the server to the client.

(I have seen it written in various places that this is why some network engineers consider NAT evil, and why they hope that IPv6 will eventually result in the elimination of NAT. However, for now, the vast majority of the internet is IPv4 and some IPv6 is being implemented via translations and proxies, so I don't think that this problem is going to disappear any time soon.)

In the case of ftp, firewall/NAT devices eavesdrop on the command connection in order to substitute the externally accessible IP address of the client in place if its actual internal address and/or to open/forward ports as required for the data connection. This is referred to as an application layer gateway ("ALG.") Alternatively, proxy servers can be used to accomplish the same goals.

You have to forgive ftp: it predates NAT deployment by a couple of decades. Although it may have been close, ISTR that SIP was designed after NAT became common yet failed to address the fact that it neither works seamlessly with NAT nor was supported by any of the NAT devices in use at the time. Of course, devices later added SIP ALGs like they did for ftp.

But, wait! It's not over: some VoIP service providers work around the NAT problem by providing a proxy for the client to connect to, essentially establishing a single connection through NAT and avoiding the interactions between NAT, SIP, and any other required protocols... but it seems that they generally use the same TCP port (5060, IIRC) for the proxy connection as is standard for SIP itself, causing a whole new problem: if your firewall/NAT device has a SIP ALG you can use a native SIP client but, if your VoIP client uses a proxy (as many soft clients seem to do) then you must disable the SIP ALG. In other words, most devices can support native SIP clients or proxied SIP clients, but not both at once.

And it gets worse: some providers are avoiding *that* problem by deploying dedicated data circuits to support VoIP traffic and insisting on connecting directly to the customer's LAN, bypassing their firewall. While this might be implemented securely, it might not. Customers who require security audits may have a problem with this. Customers who aren't security-conscious may not be aware that their VoIP line could be a back door into their network.

Not all of this is due to the design if the SIP protocol, but that's where it started.

Other way around. The people who designed SIP considered NAT both inherently evil and also unlikely to gain broad market acceptance. (This was fifteen years ago now, when IPv4 exhaustion looked comfortably far away and IPv6 deployment was right around the corner.) So there was obviously no need to provide kluges to work around NAT boxes; if people wanted an integrated-services Internet[1], they would have to implement proper networks. (If you wanted security, you would use IPsec AH and ESP, so the evil middleboxes couldn't touch your packets anyway.)

-GAWollman

I was intrigued by that statement. [Garrett] mentions discarding list UDP packets, which might be fine in an uncompressed media stream, but aren't errors/omissions likely to cause disruption to a compressed media stream (for comparison, consider that data compression was only commonly implemented in dialup modems on top of error correction)? Or is the 'compression' implemented in the codecs themselves (lower D/A resolution and/or sample rate) so that no data compression per se is required and thus missing samples are not a serious problem?

For multimedia, the compression (e.g. MPEG-2 or H.264) is typically performed offline or in specialized media processors. The data is already compressed before it's handed over to the IP stack for transmission and delivery. Attempts to do on-the-fly compression (e.g. like V.42bis in a modem) are usually futile.

Yes, there's some disruption in an A/V stream when data in the stream is lost in transmission. With UDP (or any other best-efforts delivery mechanism) this results in a visible or audible "glitch". Delivery protocols which use UDP or a similar packet mechanism, are usually designed with a data format which tries to limit the damage to the portion of the stream actually lost (e.g. a short segment of audio, or a macroblock or a few of them in a video image). The compression and coding algorithms are designed to support this... e.g. each macroblock is largely self-contained, so that loss of data to the previous macroblock doesn't garble the whole remainder of the screen. When the next part of the stream arrives, the decoder "resynchronizes" quickly, and the error does not propagate elsewhere on the screen.

If you use TCP, the protocol is trying to guarantee that all the data gets through, correctly... but it can't guarantee *when* it gets through. If you're lucky, the TCP retransmissions of lost packets will occur rapidly, and you'll see and hear everything correctly.

Often, that won't happen. TCP has an "exponential backoff" behavior, and packet retransmissions may end up being delayed for quite a while under some circumstances. When this happens, delivery of the WHOLE STREAM will stop... you won't be able to decode *anything* beyond the point of the first lost/delayed packet, until the retransmission occurs. This can lead to your A/V decoder "starving" - it runs out of data in its buffers; the audio stops and the screen freezes.

This is often much more distracting than a little bit of sparkly macro-block tearing on the screen, or a momentary blip of silence in the audio.

Another possibility, if you're using UDP, is to encode the compressed data with a level of redundency and cross-interleaved forward error correction (e.g. Reed-Solomon) before you break it up into UDP packets. This costs you bandwidth, but it means that you can reconstruct the whole set of compressed data, correctly, even if a few packets are lost in transmission.

When you packetize multimedia streams, you normally do so on boundaries that align usefully with the codec's idea of what an indivisible unit of data is. (You often want to do this even for "reliable" transfers, because the same mechanism also allows fine-grained seeks, which you usually want for user-interface reasons.) The terminology differs from codec to codec; for telephony-type codecs there's usually a concept of a "frame" which makes a natural boundary -- between 10 and 50 ms is the range I recall.

Codecs that couldn't do this were rejected as unsuitable. Generally people were interested in real-time applications like conferencing and telephony, so only low-latency codecs were in the running anyway.

-GAWollman

Depends on the multimedia. For faux-streaming video, which as far as I can tell is much more popular than real streaming video, TCP works great. That's what Youtube uses.

You only need real streaming when latency is a problem, which is largely limited to telephony and videoconferences.

R's, John

Well, really neither one of these protocols are appropriate for realtime applications. But IP connectivity is so damn cheap.

If we had serious ATM to the home, it might be different, but the network of the 21st century isn't really how I'd hoped it would be in the 20th...

--scott

... which kind of brings me back to the original question: if codecs that don't handle dropped datagrams gracefully were discarded as unsuitable as streaming evolved, why the heck wasn't SIP discarded as unsuitable for VoIP when it became apparent that it was not going to play well with NAT? It would have saved me and many other networking types many headaches.

Thanks to Garrett and Dave for their explanations.

Your question works just as well the other way around, and NAT has the additional disadvantage that it's Clearly, Deeply, Architecturally Wrong, And Besides It Can't Possibly Work Once Everyone Uses IPsec.

-GAWollman

NAT may be "wrong" in theory, but it accomplished some important goals:

1. NAT extended the usable life of IPv4 long enough for IPv6-capable software to become widely available.
2. It saved untold millions of PC's from Internet worms, just by being in use, since it effectively provides a firewall.
3. By extending the life of IPv4, NAT allows for a gradual transition to IPv6, which has avoided economic hardships to millions of end users and small companies that can't buy new equipment in the current economy.

More to the point of your email: everyone isn't going to use IPsec with IPv6, and those that do are actually /less/ secure than those who use NAT-T, since the NAT traversal makes it more difficult for external attackers to do traffic-based security analysis.

Bill

He's being a wee bit ironic. IPsec is a technology that seens great until you try to use it, at which point you discover that it's impossibly difficult to deploy, so people use other tunnel technologies like ssh and VPN that work fine over NAT.

There was a theory in the IETF that if they pretended there were no ways to use kludges to extend the life of IPv4, that would force people to switch to IPv6, even though until a few years ago, it wasn't ready to deploy at large scale either.

R's, John

I'm announcing a new subject-line option for posts to the Telecom Digest: the "[Irony]" tag. If you post contains irony, please use the "[Irony]" tag in addition to the customary ones.

Bill Horne Moderator

If you are dealing with a single continuous stream of compressed data, then any lost/scrambled data renders everything after that point 'unrecoverable', because you "don't know" _where_ you are in the decoding process.

On the other hand, it is practical to get 'not quite as good' compression by 'restarting' the compressor at regular intervals. *IF* you do that, you can resume decoding from any 'restart' point -- this is the way HDTV works, and why it takes several seconds after you change channels for the new channel to start displaying..

On Mon, 23 Jan 2012 20:08:57, Garrett Wollman wrote, ...

Longer term, RINA. It will become available (sorry, no date yet) and will be simpler to use than TCP/IP, and adopting it will be simpler than the misbegotten transition to IPv6.

Short term, learn from the basic research that John Day did, that went into RINA. See his book "Patterns in Network Architecture". It helps you deal with TCP/IP too. The basic lesson is that multiple layers do the same thing (the pattern that recurses). But the original 1970s designers of TCP/IP and the OSIRM (Day was its Rapporteur some years after it was first designed) had the idea, in error, that the purpose of the protocol stack was to do everything only once. So the TCP/IP layers were groups of functions, not true layers, which are black boxes.

So treat TCP and IP together (they started out as one protocol and should be seen as one layer, with no boundary between them) as a sort of DIF. Treat the IP address as a private matter to it. Then you can converge another instance of TCP+IP atop it (or use UDP; it only exists because the port number was erroneously put in TCP, when it belonged in IP) if you need to -- hmmm, that's sort of what IPSec does. Now view NAT as a simple function of the TCP+IP layer. Now make the application use only names, no IP addresses inside the application protocol. *Because* DNS is done by the application, servers need non-NAT addresses for now, since their IP address forms part of the actual name, but bear in mind that it's an error in the stack design, a huge layering violation. And try to use applications that pass along actual names, as HTTP does.

When you embrace or accept NAT as a local matter to one layer, you become liberated from the need to use IPv6. That's worth the price of admission, to carry you over until RINA (which passes the actual name down the stack via its API, and has no other global addresses since they're always local to a layer) is ready.

This is quite realistic. That IPv6 will actually replace IPv4 is the fantasy. They've been trying for close to 20 years.

-- Fred Goldstein k1io fgoldstein "at" ionary.com ionary Consulting

I allowed Mr. Wollman's criticism of Fred's OP, so Fred has a right to respond.

But, this has gotten beyond telecom (i.e., the impact of NAT on SIP), so I'm closing the thread and setting followups to comp.protocols.tcp-ip.

Bill Horne Moderator