« November 21, 2005 | Main | November 23, 2005 »
CableLabs VoIP Peering RFI
I expect the entire cable industry to adopt VoIP peering soon. Take a look at this VoIP Peering RFI from CableLabs. I imagine that I could be right on with my prediction of 2006 being the year of VoIP peering. Still, I want to be a bit cautious as I am still waiting for the year of videoconferencing to finally arrive.
Getting back to VoIP peering, it is exciting to see the major players in the market like cable companies getting into the game. I am equally excited about the world’s next VoIP Peering Summit happening in conjunction with Internet Telephony Conference & Expo East in
Here are some excerpts of the RFI worth noting:
STATEMENT OF PURPOSE
CableLabs is seeking information regarding the development of a production-grade VoIP Peering infrastructure to allow VoIP traffic exchange among MSOs, and, between MSOs and other VoIP partners.
Through this RFI, CableLabs is seeking information on the technical scope, requirements, protocols, architecture, management and operations considerations to support the CableLabs VoIP Peering architecture. Further detail on the proposed scope of the CableLabs VoIP Peering architecture can be found in section 2.4.
BACKGROUND
Initiated by CableLabs member companies, the MSO VoIP Peering project is a CableLabs-led initiative aimed at developing technical requirements, architecture and interoperable protocol specifications for delivering end-to-end VoIP and other real-time multimedia communication exchanges between service operators. The VoIP peering initiative addresses requirements for establishing a production platform to exchange VoIP traffic between operators.
PROBLEM STATEMENT
The Internet is a set of interconnected IP networks allowing IP traffic to flow between Internet hosts. To take advantage of the end-to-end connectivity nature of the Internet, a number of service providers (Internet Service Providers – ISPs, Network Service Providers also known as IP Backbone Providers) have used interconnection agreements to exchange IP traffic transparently. These bilateral agreements are commonly called peering agreements, referring to the two IP network providers as peers in IP traffic exchange (at layer 3). The main advantage for IP network providers to peer is to reduce the amount of traffic that transits between the two networks via third party backbone providers. Such an arrangement has the effect of reducing network costs and increasing quality of service. A number of MSOs have already established such IP network peering arrangements among themselves and with other Internet providers. IP Network Peering is by definition peering at the IP layer and is therefore application-agnostic. The notion of IP Service Peering (and VoIP Peering) emerges as a natural extension of IP network peering. IP Service Peering extends the relationship between network operators above the IP layer, by handling the IP-based services and applications that can be exchanged.
Unlike email which has a well-known addressing schema that only exists on the Internet (<user>@<domain>), some communication services like VoIP rely on telephone numbering schemas (as defined by the ITU-T Rec. E.164) to identify subscribers’ service addresses. These numbering schemas are attached to the Public Switched Telephone Network (PSTN). Without IP or VoIP Service Peering, VoIP calls between operators are sent over PSTN, resulting in the use of a third party network. This incurs additional service costs, potentially degrades the perceived service quality (voice is transcoded multiple times) and prevents the deployment of enhanced VoIP services. Similarly, a video over IP call between subscribers residing on two different MSO networks would likely be sent to the PSTN and be degraded to an audio-only call. One of the key benefits for peering IP-based Services is that it allows operators to “identify” Voice or Video over IP calls and exchange them end-to-end across IP networks, preserving value-added services and advanced features for the benefit of subscribers. It is worth noting that the notion of exchanging VoIP traffic between providers has been explored since the early days of IP telephony when toll bypass and international long distance arbitrage was seen as the main economic driver for the emerging service providers. A commonly used name borrowed from the financial field emerged: “VoIP Clearinghouse”, which is a third party clearing center where VoIP providers could exchange minutes at lower cost than the PSTN through the use of IP termination points. The motivations of the VoIP clearinghouse model are different than those of the MSO community. The goal of the clearinghouse was low-cost termination of VoIP calls to the PSTN, while the main goal of the MSO community is to exchange VoIP call with feature transparency and advanced value added services like end-to-end video communications between MSOs. In order to understand the various network functions involved in VoIP Service Peering, key phases in the establishment of an IP communication session were analyzed: from the session initiation (a VoIP number or service address identifier is entered by the caller) to the session establishment (the caller’s device exchanges IP media traffic with the called party’s terminal). Several questions emerged as a result of the analysis:
· How does the caller or the caller’s MSO operator know that the called party is on a peering partner’s network?
· How can the called party be reached using an E.164 addressing schema in a network based on IP addresses?
· Knowing the called party’s VoIP addressing schema, where should the VoIP call be routed? And to what network device should the VoIP signaling session be sent?
· What signaling protocol(s) should be used to initiate the session to the peering partner?
· How will QoS be preserved once the communication session reaches the “other” transport network?
Several functional components play key roles in the VoIP Service Peering architecture, including:
Border Elements
It is assumed that each service domain has deployed an IP Service architecture offering boundary components that connect the internal IP Service domain to its peering partners. Border Elements are common components in many IP Service network architectures - from email (inbound SMTP proxy servers accessible to the “outside Internet world”) to web services (HTTP proxies) and VoIP (inbound SIP proxy servers). For the application of this architecture framework to VoIP peering, the Border Element should, at a minimum, act as a VoIP signaling entity that may provide outbound or inbound SIP signaling connectivity and SIP protocol profile normalization with the other MSO peers. The Border Element should also support the IETF ENUM protocol for translating a telephone number into URIs or DNS records. The Border Element may also perform media transcoding or proxy functions (out of scope at this time).
Edge Routers
Edge routers are the IP routers located at the boundary of the service domain. In the context of VoIP Service Peering, an Edge Router acts as a Quality of Service (QoS) element for DiffServ policing and (potentially) re-marking.
IP Service Core “VoIP Directory” and ENUM Servers
The service discovery function is typically provided by a set of directory services that can map a subscriber service identifier into one or more URIs, which indicate the MSO providing service to the subscriber and potentially the service resources to contact to initiate IP communication. Examples of subscriber service identifiers include telephone numbers for VoIP service, user identifiers like username@domain for instant messaging, etc. In the case of VoIP, this service discovery function is performed by the “IP Service Core VoIP Directory”. The IP or VoIP Service Core VoIP directory utilizes various technologies (e.g. ENUM) for resolving telephone numbers to Internet style addresses. ENUM is the name of an IETF working group as well as the name of a DNS-based IETF RFC and DNS extensions to allow the mapping of telephone numbers to a set of URIs. ENUM is one protocol solution for the VoIP Directory to realize the service discovery function. An ENUM server is more or less the logical VoIP Directory function with ENUM access.
Critical Dates
Questions Regarding the RFI
Respondent should notify CableLabs in writing of its intent to submit a response to the RFI by sending a Letter of Intent to the CableLabs authorized person by 5:00 PM Mountain Time, November 30, 2005. Questions regarding the RFI must be submitted in writing via facsimile and email to the authorized Contact Person no later than 5:00 PM Mountain Time on November 30, 2005. Every reasonable attempt will be made to promptly answer all inquiries from each Respondent. Respondent understands and agrees that it has a duty to inquire and seek clarification regarding the RFI wherever Respondent does not fully understand the RFI or wherever Respondent believes the RFI may be interpreted in more than one manner.
If Respondents’ questions are material to the content of its RFI response or result from ambiguities contained in the enclosed documents, a written reply to such questions will be issued to all Respondents by December 5, 2005. CableLabs reserves the right to not answer any question(s) that CableLabs feels are not pertinent to Respondent’s submittal. However, questions that are answered will be shared with all Respondents who have indicated their intent to respond to this RFI. Questions directed to any employee of CableLabs other than the designated contact person may constitute immediate disqualification from further discussions and/or consideration.
RFI Response Due Date
Information must be delivered to the Contact Person on or before 12:00
All supporting materials and documentation must be included with each copy of the submitted information, and provided in electronic format (on a CD or via email to the Contact Person). Organized, succinct and straightforward submissions are appreciated. There is no need to submit an unnecessarily elaborate RFI response.
Link this |
Email this |
Leave comment
Trackback URL: CableLabs VoIP Peering RFI
Technorati
Del.icio.us
BoingBoing
Slashdot
Digg
Spurl
Furl
Hackers Targeting Programs
Just when you thought it was safe to compute, hackers are beginning to exploit vulnerabilities in PC-based programs instead of server based software and operating systems. Full story.
Link this |
Email this |
Leave comment
Trackback URL: Hackers Targeting Programs
Technorati
Del.icio.us
BoingBoing
Slashdot
Digg
Spurl
Furl
Pixel Ads
The cost is so low that I am sure advertisers are drawn to the concept just to see if it works. How low? Try $1 a pixel for five years. In the case of PixelBay the company touts the fact that it will drive traffic to its website in large numbers. A look at the Alexa Rankings of the site show that while traffic spiked for a while, it is on the way back down now.
Here is an article on the topic worth reading and this is where I found this quote that I agree with:
"Things that have no benefit to the consumer don't last very long. They can survive on curiosity and novelty for only so long," said Jim Nail, analyst at Forrester Research,
In short, unless the company and others can find a way to attract people to the concept will most definitely remain as a fad.
Link this |
Email this |
Leave comment
Trackback URL: Pixel Ads
Technorati
Del.icio.us
BoingBoing
Slashdot
Digg
Spurl
Furl
VoIP Santa Claus
In what is an excellent gesture of good will, Packet8 is providing children in hospitals videophones so they can call Santa Claus
According to Kitty O'Brien of the Child Life Department at Cincinnati Children's Hospital, which participated in the "8x8 / Packet8 Videophone Calls to Santa" event previously, "The program was enormously successful last year and we are looking forward to bringing Santa's cheer to our patients again this holiday season."
"It's great to see the same 21st-century communication technologies that enable distant families and friends to instantly bridge gaps brighten the experience, even briefly, of hospitalized children this holiday season," said 8x8 Chairman and CEO Bryan Martin.
"This application of our Packet8 voice and video internet-based calling is a perfect example of how technology can enhance our everyday lives," Martin said.
"All you have to do is watch the smiles and hear the laughter and joy in these children's voices while they interact with our videophone Santa and his helpers to know that we are making a tremendous impact, even in the space of a five or ten minute call. This is something that would never be possible over legacy copper wires."
While the technology was in place to perform video conferencing and has been for years, the lower cost points possible due to the transmission of video over IP makes this solution inexpensive enough to deploy in hospitals.
The gesture here is wonderful and I am proud to be associated with an industry that gives back to humanity in such unique and novel ways.
Link this |
Email this |
Leave comment
Trackback URL: VoIP Santa Claus
Technorati
Del.icio.us
BoingBoing
Slashdot
Digg
Spurl
Furl