30 Years of the Digest ... founded August 21, 1981
The Telecom Digest for January 13, 2012
====== 30 years of TELECOM Digest -- Founded August 21, 1981 ======
Telecom and VOIP (Voice over Internet Protocol) Digest for the
Internet. All contents here are copyrighted by Bill Horne and
the individual writers/correspondents. Articles may be used in other
journals or newsgroups, provided the writer's name and the Digest are
included in the fair use quote. By using any name or email address
included herein for any reason other than responding to an article
herein, you agree to pay a hundred dollars to that person, or email address
Addresses herein are not to be added to any mailing list, nor to be sold or given away without the explicit written consent of the owner of that address. Chain letters, viruses, porn, spam, and miscellaneous junk are definitely unwelcome.
We must fight spam for the same reason we fight crime: not because we are naive enough to believe that we will ever stamp it out, but because we do not want the kind of world that results when no one stands against crime. - Geoffrey Welsh
See the bottom of this issue for subscription and archive details and the name of our lawyer, and other stuff of interest.
Date: Thu, 12 Jan 2012 08:50:54 -0600 From: email@example.com (Robert Bonomi) To: firstname.lastname@example.org. Subject: Re: Some unanswered questions from January 2011 Message-ID: <HdOdndPzO7nTbpPSnZ2dnUVZ_gqdnZ2d@posted.nuvoxcommunications> In article <20120112075953.GC7371@telecom.csail.mit.edu>, Telecom Digest Moderator <email@example.com> wrote: >Here's a republished version of John Levine's answer to Sam Spade's >questions from January 1st of 2011. I have a couple of added >questions: > >1. For calls from and to Vonage customers, is there a Central Office > "switch" involved? In other words, does the voice path from the > originating Vonage customer to the called party "To" number have to > be converted to speech and switched in a central office? It depends on what you mean by 'converted to speech'. <grin> 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.
Date: Thu, 12 Jan 2012 09:12:24 -0600 From: firstname.lastname@example.org (PV) To: email@example.com. Subject: Re: Some unanswered questions from January 2011 Message-ID: <ktadnbRuc_jFZZPSnZ2dnUVZ_qwAAAAA@supernews.com> Telecom Digest Moderator <firstname.lastname@example.org> writes: >2. What did the "1995 Caller ID decision" involve? Was it ever resolved? You probably mean this: https://epic.org/privacy/caller_id/fcc_final.html * -- * PV Something like badgers, something like lizards, and something like corkscrews.
Date: Thu, 12 Jan 2012 09:11:31 -0600 From: email@example.com (PV) To: firstname.lastname@example.org. Subject: Re: Some unanswered questions from January 2011 Message-ID: <ktadnbVuc_i-ZZPSnZ2dnUVZ_qydnZ2d@supernews.com> Telecom Digest Moderator <email@example.com> writes: >1. For calls from and to Vonage customers, is there a Central Office > "switch" involved? In other words, does the voice path from the > originating Vonage customer to the called party "To" number have to > be converted to speech and switched in a central office? 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. >2. What regulatory changes have occured in the VoIP world during 2011? 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. >3. I've heard many comments about "SIP" being a less-than-perfect > protocol. Why is that? Is there any driver to improve it? 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. * -- * PV Something like badgers, something like lizards, and something like corkscrews.
Date: Thu, 12 Jan 2012 20:19:36 -0500 From: Bill Horne <bill@horneQRM.net> To: firstname.lastname@example.org. Subject: FCC Invites Comments on Recon re New iTRS Rules Message-ID: <4F0F86A8.email@example.com> This is from CommonLawBlog via the Cybertelecom-L list: Last August we reported on new rules imposing a number of restrictions on providers of Internet Telecommunications Relay Service (iTRS). Those rules took effect in October, but if you have an interest in iTRS, heads up. A petition for reconsideration of the new rules was filed, and the deadline for commenting on, or opposing, the petition has just been announced. Among other things, the new rules put an end to the previous practice of some iTRS providers of assigning free "800" numbers to iTRS users. While iTRS users may still have toll-free numbers, they now have to obtain those numbers like everyone else - from the same companies that provide them to the public at large, subject to whatever fees may be involved (unless a hardship waiver is granted). Each toll-free number must be mapped to a regular "plain old telephone service" (POTS) number and be portable from one carrier to another; numbers that aren't so mapped must be removed from directories. http://tinyurl.com/7mk5vey -- Bill Horne (Remove QRM from my address to write to me directly)
Date: Thu, 12 Jan 2012 21:39:04 -0500 From: Bill Horne <bill@horneQRM.net> To: firstname.lastname@example.org. Subject: Attention metal thieves: Buy BT, get 75 MILLION miles of copper Message-ID: <4F0F9948.email@example.com> From The Register, via the Cybertelecom-L list: Telco is worth less than its expensive assets By Tim Worstall Analysis British Telecom is, as a telecoms company, worth minus ~30bn. Yes, that's a negative number there. And yet it is literally sitting on top of billions in assets. It all starts with this point made in relation to cable theft: BT's network relies on more than 75 million miles of copper cable http://tinyurl.com/3d2h5c7 -- Bill Horne (Remove QRM from my address to email me directly)
Date: Thu, 12 Jan 2012 21:04:12 -0500 From: "Geoffrey Welsh" <firstname.lastname@example.org> To: email@example.com. Subject: Re: Some unanswered questions from January 2011 Message-ID: <11bf6$4f0f9116$adce161b$15095@PRIMUS.CA> Telecom Digest Moderator wrote: > 3. I've heard many comments about "SIP" being a less-than-perfect > protocol. Why is that? Is there any driver to improve it? 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.
Date: Fri, 13 Jan 2012 05:09:13 +0000 (UTC) From: firstname.lastname@example.org (Garrett Wollman) To: email@example.com. Subject: Re: Some unanswered questions from January 2011 Message-ID: <firstname.lastname@example.org> In article <11bf6$4f0f9116$adce161b$15095@PRIMUS.CA>, Geoffrey Welsh <email@example.com> wrote: >(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. 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, 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  That's what we called it, back then. SIP was designed to be application-agnostic, because we were already using the underlying RTP/UDP stack with IP multicast for videoconferencing. SIP was just the mechanism to send the same sort of session announcements that were already being broadcasted by the conferencing applications, and provide the minimum amount of PSTN-style signalling necessary to initiate private conversations.  Well, vat didn't use RTP, but its design greatly inspired that of RTP.  It was obviously stupid to use TCP for multimedia applications. (Still is, for that matter, but one of the other parts of the integrated-services Internet -- network resource reservation -- never panned out, mainly due to economic rather than technical issues. As a result, the benefit that was derived from using UDP when links are congested -- discarding packets that can't be delivered in time, rather than wasting bandwidth trying to deliver them -- cannot be effectively realized. VoIP over the public Internet has mostly Just Worked because we are still in a bandwidth glut.) -- Garrett A. Wollman | What intellectual phenomenon can be older, or more oft firstname.lastname@example.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993
Date: Fri, 13 Jan 2012 08:44:43 +1100 From: David Clayton <email@example.com> To: firstname.lastname@example.org. Subject: Digital bonanza for telecoms historians Message-ID: <ZE3heD.A.zxD.ZC7DPB@telecom> http://www.itwire.com/it-industry-news/development/52118-digital-bonanza-for-telecoms-historians Digital bonanza for telecoms historians Stuart Corner Thursday, 12 January 2012 12:06 IT Industry - Development The UK's National Archive is to digitise 165 years worth of British Telecom's and its predecessors' historical documents. The project is a collaboration between Coventry University, BT Heritage and The National Archive and aims to catalogue, digitise and develop a searchable online archive of almost half a million photographs, images, documents and correspondence. It is being funded with a grant from JISC (formerly the UK's Joint Information Systems Committee). According to JISC: "The BT Archive is held, with some limited public access, in central London and is by any standard a collection of national and international importance, recognised by UNESCO~?~ "The digitisation of a significant proportion of the Archive will allow teachers, students, researchers and the general public in the UK and overseas to gain easier access to our scientific and cultural telecommunications heritage; enabling them to utilise the archive for studies and leisure from anywhere in the world. Digitisation of the Archives will also ensure the continued preservation of the collections in digital as well as analogue format." The project includes research work around product and graphic design, language development and problem-based learning. Using innovative, immersive techniques the project will develop mobile and web access to the collection for scholars, teachers and learners as well as the general public.
Date: Thu, 12 Jan 2012 13:29:44 -0800 From: email@example.com (Dave Platt) To: firstname.lastname@example.org. Subject: Re: Some unanswered questions from January 2011 Message-ID: <email@example.com> In article <ktadnbVuc_i-ZZPSnZ2dnUVZ_qydnZ2d@supernews.com>, PV <firstname.lastname@example.org> wrote: >>2. What regulatory changes have occured in the VoIP world during 2011? > >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. 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. >>3. I've heard many comments about "SIP" being a less-than-perfect >> protocol. Why is that? Is there any driver to improve it? > >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. * 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. -- Dave Platt <email@example.com> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do not wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads!
TELECOM Digest is an electronic journal devoted mostly to telecom- munications topics. It is circulated anywhere there is email, in addition to Usenet, where it appears as the moderated newsgroup 'comp.dcom.telecom'. TELECOM Digest is a not-for-profit, mostly non-commercial educational service offered to the Internet by Bill Horne. All the contents of the Digest are compilation-copyrighted. You may reprint articles in some other media on an occasional basis, but please attribute my work and that of the original author. The Telecom Digest is moderated by Bill Horne.
43 Deerfield Road
Sharon MA 02067-2301
bill at horne dot net
This Digest is the oldest continuing e-journal about telecomm- unications on the Internet, having been founded in August, 1981 and published continuously since then. Our archives are available for your review/research. We believe we are the oldest e-zine/mailing list on the internet in any category! URL information: http://telecom-digest.org Copyright (C) 2012 TELECOM Digest. All rights reserved. Our attorney is Bill Levant, of Blue Bell, PA.
Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of fifty dollars per year per reader is considered appropriate. See our address above. Please make at least a single donation to cover the cost of processing your name to the mailing list. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization.