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.
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.
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:
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 are the IP routers located at the boundary of the service domain. In the c
ontext 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.
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.