The IETF and VoIP IslandsThe IETF and VoIP Islands
The IETF's Verification Involving PSTN Reachability (VIPR) activities support voice calls that flow over IP networks and never pass through the PSTN.
April 29, 2011
The IETF's Verification Involving PSTN Reachability (VIPR) activities support voice calls that flow over IP networks and never pass through the PSTN.
Stefan Karapetkov, Polycom's emerging technologies director, posted a blog about the IETF 80 meeting in Prague, Czech Republic at Video Networker. One of the topics of interest in the blog was connecting VoIP islands. Islands of IP communications continue to exist. As the PSTN slowly declines in use, the connection of these islands becomes paramount.
The IETF's Verification Involving PSTN Reachability (VIPR) activities support voice calls that flow over IP networks and never pass through the PSTN. A major bottleneck in this flow is the lack of trust among the IP communications islands. The VIPR concept is to use a basic phone call to verify that the destination is what it claims to be.
According to Karapetkov's post:
On a more generic level, the mechanism can be used to extend trust established in one network (e.g. PSTN) to another network (e.g. IP) but the VIPR working group seems to be focusing on the narrow and practical application of connecting voice over IP islands without PSTN gateways. VIPR is very important to HD voice because it enables direct end-to-end HD voice connections. PSTN gateways on the other hand always take the voice quality down to "toll quality" (3.4kHz, G.711), even if handsets and conference servers support HD voice. VIPR can be used for video, and in fact is even more beneficial for video, since PSTN does not support video at all. Once PSTN is used to verify the destination, all subsequent calls between source and destination can be completed over IP. Again, the quality is not limited by any gateway, only by available bandwidth, and HD video can flow freely end-to-end.
Another issue that Karapetkov raises is the error codes defined by the standard Q.850 that are generated by PSTN switches. Trying to map Q.850 error codes to SIP error codes does not work completely. There are codes in each standard that have no equivalent meaning in the other standard. New SIP error codes could produce complications for SIP endpoints and servers. He mentions a proposal to update RFC 3326 entitled "The Reason Header Field in SIP" to transport the original Q.850 codes. This would encapsulate the Q.850 error codes rather than trying to translate the Q.850 error codes as a solution.
An additional issue is the information that will not pass through the PSTN, the Quality of Service code points (DSCP, which stands for DiffServ Code Points). There is no equivalent for QoS in the PSTN. IP service providers accept prioritized traffic from customer's LANs but translate the QoS value into something they use on their own network. When the traffic arrives at the other customer LAN, the original QoS labels no longer exist.
A proposal mentioned in the post is for the "MMUSIC (Multiparty Multimedia Session Control) working group to update RFC 4598, so that the session description (Session Description Protocol, or SDP) has more detailed description of the application...so that the destination LAN knows what priority to assign to the traffic in that session".
The last topic discussed about VoIP islands is the problem of end-to-end security for a call. There are many RFCs that cover some aspect of security. That causes problems with the Interactive Connectivity Establishment (ICE) standard implementation covered in RFC 5245. The result has been many IETF 80 presentations, primarily by the MMUSIC group about the ICE problems.
Karapetkov noted in the post that:
no one is considering changing ICE and the pretty universal response to such contributions was sorry but we cannot help you. Another security issue was discussed in the XMPP (Extensible Messaging Presence Protocol) group, where the consensus was that Transport Layer Security, or TLS, was not working at all on the interface between XMPP servers, that is, in XMPP federation scenarios.
An example is if you have Gmail with 1,000 domains and WebEx with another 1,000 domains, this would produce a million connections which would create scalability and performance issues. The XMPP group proposed that Google and WebEx implement one connection and have all the domains use the same connection.
The U.S. government is considering the implementation of XMPP federation. This move creates a time limit on resolving the issue. What troubles me about federation are the security issues, forensic analysis across multiple networks that are independently owned and problem troubleshooting. The benefits of federation are real but so are the new problems federation creates.
I was once on a standards master committee (ANSI X.9). The biggest problem I faced was all the competing proposals. How the standard would be enforced created a number of political as well as technical issues. Standards are great if delivered quickly before the vendor world comes up with one or more proprietary solutions.
