30 Years of the Digest ... founded August 21, 1981
Add this Digest to your personal
or 
The Telecom Digest for January 13, 2012
Volume 31 : Issue 13 : "text" Format
====== 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
owner.
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: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.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 <redacted@invalid.telecom.csail.mit.edu> 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: pv+usenet@pobox.com (PV)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <ktadnbRuc_jFZZPSnZ2dnUVZ_qwAAAAA@supernews.com>
Telecom Digest Moderator <redacted@invalid.telecom.csail.mit.edu> 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: pv+usenet@pobox.com (PV)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <ktadnbVuc_i-ZZPSnZ2dnUVZ_qydnZ2d@supernews.com>
Telecom Digest Moderator <redacted@invalid.telecom.csail.mit.edu> 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: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: FCC Invites Comments on Recon re New iTRS Rules
Message-ID: <4F0F86A8.7030800@horne.net>
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: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Attention metal thieves: Buy BT, get 75 MILLION miles of copper
Message-ID: <4F0F9948.2030506@horne.net>
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" <gwelsh@spamcop.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
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: wollman@bimajority.org (Garrett Wollman)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <jeoe9p$2nlc$1@grapevine.csail.mit.edu>
In article <11bf6$4f0f9116$adce161b$15095@PRIMUS.CA>,
Geoffrey Welsh <gwelsh@spamcop.net> 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[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
[1] 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[2][3] 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.
[2] Well, vat didn't use RTP, but its design greatly inspired that of
RTP.
[3] 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
wollman@bimajority.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 <dcstarbox-usenet@yahoo.com.au>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.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: dplatt@radagast.org (Dave Platt)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <8vv3u8-17b.ln1@radagast.org>
In article <ktadnbVuc_i-ZZPSnZ2dnUVZ_qydnZ2d@supernews.com>,
PV <pv+usenet@pobox.com> 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 <dplatt@radagast.org> 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.
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.
End of The Telecom Digest (9 messages)
Return to Archives ** Older Issues