Darren,
I've been following some of your well-informed and enlightening posts, from a technical perspective, at least, in this sector. Maybe you wouldn't mind sharing some of your views on the standards you've highlighted in your last message.
Is G.729 the default or is it G.723.1? When is the more efficient (by many accounts) G.729 called for and when will it not suffice? And how popular will arbitration be, on the fly, to provide adaptive compression capabilities? Who has these capabilities now, and will they be show stoppers for those who do not?
While we're on the subject of standards, maybe you can give me your take on the timing of these proposed standards, and which operating domains they apply to.
While the international ITU standards are paramount for the purposes of obtaining large telco buy-ins, along with NEBS compliance, and so on, there are other factors that must be taken into account as we proceed.
What follows is, in part, my own take on the topic with some notes added from a discussion I had with a colleague of mine at City College of New York, Dr. Dan Schlitt.
To set the stage for discussion, it would be useful to acknowledge that there are at least two converging universes or domains that need to be addressed. One domain is governed by the ITU and other traditional telephony establishment constructs, and the other is governed (yeah, yeah, I know, there is no such thing in an anarchistic society...) by the Internet Engineering Task Force, or IETF.
The IETF gets into the topic, enter the new proposed IETF working group, IP Telephony (iptel). The IESG is considering creating the IP Telephony (iptel) Working Group in the Transport Area of the IETF. The following description is provided for your collective information:
Before Internet telephony can become a widely deployed service, a
number of protocols must be deployed. These include signaling and
capabilities exchange, but also include a number of "peripheral"
protocols for providing related services. I don't want to seem like someone who harps a lot on a subject, but heritage signalling system number 7 (SS7) is just as crucial to the efficient adoption of any-to-any communications as any compression or gate keeping algorithm mentioned in the standards we're discussing here.
The primary purpose of this working group is to develop two such
supportive protocols and a framework document. They are:
1. Call Processing Syntax. When a call is setup between two endpoints,
the signaling will generally pass through several servers (such as an
H.323 gatekeeper) which are responsible for forwarding, redirecting,
or proxying the signaling messages. For example, a user may make a
call to j.doe@bigcompany.com. The signaling message to initiate the
call will arrive at some server at bigcompany. This server can inform
the caller that the callee is busy, forward the call initiation
request to another server closer to the user, or drop the call
completely (among other possibilities). It is very desirable to allow
the callee to provide input to this process, guiding the server in its
decision on how to act. This can enable a wide variety of advanced
personal mobility and call agent services.
Such preferences can be expressed in a call processing syntax, which
can be authored by the user (or generated automatically by some tool),
and then uploaded to the server. The group will develop this syntax,
and specify means of securely transporting and extending it. The
result will be a single standards track RFC.
2. In addition, the group will write a service model
document, which describes the services that are enabled by
the call processing syntax, and discusses how the syntax
can be used. This document will result in a single RFC.
Here's a proposed approach to the merging of the two domains:
3. Gateway Attribute Distribution Protocol. When making a
call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone
number. Since gateways outside of the hosts' administrative domain
might be used, a protocol is required to allow gateways in remote
domains to distribute their attributes (such as PSTN connectivity,
supported codecs, etc.) to entities in other domains which must make a
selection of a gateway. The protocol must allow for scalable,
bandwidth efficient, and very secure transmission of these
attributes. The group will investigate and design a protocol for this
purpose, generate an Internet Draft, and advance it to RFC
as appropriate.
Now, having said this, it would appear on the surface that we may have two schools of thought on this matter, and indeed we do, but in order for this technology to be efficiently adopted we will need orchestration between the two sets of standards are an eventual melding of the two. This is what I see taking place, and it would be foolish to think that abiding by either one alone will get us very far given the rate that convergence is taking place.
So, my point may boil down to: How long can proprietary fixes be useful to any vendor entering this segment, and when will strict adherance to yet-to-be-ratified standards be required?
Just my two cells worth, Frank |
