Many No Jitter readers continue to express interest in information exchanged during sessions held at this spring’s VoiceCon tradeshow. In this series of Questions and Answers, we’ll address some of the questions raised by the audience during the SIP Trunking Services panel I chaired at VoiceCon on March 22. I say "we" because many of the panelists provided useful input to these questions, so a significant amount of the information contained in this brief is a compendium of the best information provided by multiple panelists.
Nine panelists participated in the SIP Trunking services session--four service providers and five vendors. They included: AT&T Business Services--Rupesh Chokshi; Verizon Business--Thomas Dalrymple; Sprint Business--Daniel Jacobson; Global Crossing - Christopher Smith; Acme Packet - Seamus Hourihan; Empirix--Gordon Eddy; Network Equipment Technologies--Kevin Issacs; Audiocodes--Alan Percy; and Sonus- Gregory Zweig. The questions we'll address in this brief concern Fax over IP, Security, Intercarrier SIP interoperability, and SIP Calling Flexibility.
Fax over IP
We received numerous questions on this topic during the panel, and at multiple webinars. Here, I've combined similar questions/answers. They were:
Q: Do you see many issues running fax over SIP? Can you discuss how SIP Trunks support fax? I've heard mixed results--is it prudent to retain some TDM trunks for fax?
A: Sonus, Acme Packet, Audiocodes, and Network Equipment Technologies provided the following: Using SIP trunks for fax traffic is a very viable option but it does require some due diligence and preparation. Fax was designed for the challenges of sending data over an analog line. It is inherently sensitive to data sequence issues and reacts to errors by reducing transmission speeds and requesting resends. It assumes that errors are the result of poor quality analog signal. This is problematic in an IP environment where packet delivery is inherently inconsistent as a result of occasional bandwidth deprivation and latency (vs. MPLS with voice QoS). If appropriate steps are not taken to assure QoS, the fax transmissions speeds can degrade substantially. Many of the field issues we have seen with fax are related to fax transmissions using nothing but standard G.711 and limited QoS parameters; in these instances delayed packet transmission creates a cycle of resends and speed reductions by the fax machine. This is frustrating for end users as fax transmissions appear slow or may fail.
There are two different options for supporting fax over SIP trunks. The first option is through the use of the T.38 (real-time faxing over IP), which the SIP Trunk Service provider must support. The second option is to transcode the fax traffic into a voice codec (i.e. G.711) and carry the media across the SIP trunk as G.711. G.711 (fax over clear voice) works on perfect lines. The T.38 option is generally preferred due to the fact that each fax/voice transcoding instance increases the likelihood of media impairment. High quality gateways are required in order to ensure reliable fax. With T.38 and a quality gateway, retaining TDM trunks are not required for fax.
Here's my bottom line: use of T.38 is strongly preferred and recommended, but all your ducks must be lined up and tested--this is where proven vendor expertise can make all the difference. This clearly is worthwhile for medium-high volume fax requirements. If your company is dealing with a handful of faxes/month, look at maintaining a POTS line or using T.37 (store and forward fax over IP using email protocols like MIME or SMTP.
Q: What T.38 Fax over SIP Trunk capabilities (fax local home number porting to SIP Trunks) are available from each vendor and service provider? Who has successfully centralized a high volume of analog fax machines (many different models) on SIP Trunks?
A: Information provided by the above four vendors indicates they all support T.38. As for service providers, AT&T supports T.38 today (SIP Trunks to AVPN), as does Sprint. Verizon plans to support T.38 by 3Q 2010. Global Crossing provided this information:
...Global Crossing supports both T.38 for fax, as well as G.711 fallback. When customers send faxes to our network over SIP, the network core will convert it to regular inband G.711. Customers will experience the best results related to fax over IP when connecting via MPLS with voice quality of service transport. Companies using Global Crossing for fax termination include enterprise corporations sending fax as part of normal business practice, as well as large hosted IP fax application providers that send nothing other than fax traffic to enterprises as a core service...
Global Crossing's last point is interesting, because another member of the audience asked about vendor/carrier expertise with "...a high volume of analog fax machines (many different models) on SIP Trunks." Apart from that, no panelist supplied concrete examples. If faxes are a particularly significant part of your company’s life going forward, my recommendation is to use a fax over IP application provider, or invest in a good analog T.38 gateway, but it won't be free.
Q: Do you see customers combining voice and fax traffic on SIP Trunks or do you see splitting of traffic on dedicated voice vs. fax trunks?
A: The response is virtually unanimous: with some limited exception, the most common and recommended case is to combine voice and fax.
Security
Two security-related questions were raised during the VoiceCon panel. They were:
Q: Do you support Network Address Translation (NAT) on SIP Trunks?
A: Sonus and Acme Packet supplied the following information: Most service providers have deployed session border elements that support "keep alive" messages to maintain a pinhole in the premise firewall as well as the registration relay support required for NAT. In addition, the service provider has to have a registrar deployed in their network as well as management tools to create and maintain a customer's authorization credentials.
On the premise side, the IP-PBX or gateway has to support registration. In many cases, some but not all of these elements are in-place, as a result the number of SIP trunks deployed with registration is still a small percentage. NAT must be employed to hide the topology of IP PBX/UC servers and internal endpoints, thereby defending against directed attacks and protecting user privacy.
An SBC on the enterprise premise plays a critical security role. The SBC must perform a number of functions to defend IP PBX and UC servers (as well as itself) against DoS/DDoS attacks and non-malicious overloads. It should enforce access control policies by limiting incoming sessions to the IP addresses of service provider peer SBCs. The SBC must provide intrusion monitoring and reporting capabilities to validate service provider security compliance.
Other panelists provided the following information: Sprint, Verizon and Global Crossing support NAT on SIP Trunks, as does AT&T via its managed router service (which can connect to SIP Trunks). Audiocodes' media gateways and Multi Service Business Gateways (MSBG) support NAT on SIP Trunks. NET supports connected media traversal and ICE.
Q: What security options are available for SIP Trunks?
A: Sonus and Empirix supplied the following response: SIP trunks can be deployed with SRTP (secure RTP audio) and TLS (secure call control)--this requires support from both the premises vendor and SIP Trunk service provider. Ideally on an IP-PBX, these are deployed right from the phone so that the entire call is encrypted and secure from end to end (assuming you close your door...). SRTP and TLS are also available from leading gateway vendors. IPSec may also be available but this is typically deployed on gateways and not from IP phones. But due diligence is required, because there are a number of performance challenges and potential issues including authentication and cryptography overhead which can lead to latency or delays or can limit the ability to maximize call rates and capacity.
Another potential issue is if security settings are implemented improperly, then call success rates and quality, voice application functionality as well as scalability can also be adversely affected. We recommend verifying security and vulnerability protection implementations prior to deployment to ensure the quality, reliability and scalability of the SIP-based voice applications by emulating secure endpoints, emulating DDoS attacks and fully testing network-edge security devices, such as session border controllers and firewalls.
Both NET and Audiocodes support SIP/TLS and SRTP. In addition, Audiocodes offers a "transcrypting" feature, which allows MSBGs to terminate an encrypted SIP trunk and pass it un-encrypted into an IP-PBX or other application that does not support security.
AT&T, Verizon Business, Sprint and Global Crossing’s SIP Trunks support MPLS and IPSec. All four connect to SBCs in network nodes, and at least two (Sprint and Global Crossing) discussed using VLAN segregation in their nodes. Each Global Crossing customer interconnection has a dedicated SIP user agent defined within the SBC. The SBC is implemented as a Back-to-Back User Agent for both signaling and bearer traffic, and therefore presents a SIP demarcation point in the call flow. Global Crossing also plans to make SIP TLS/sRTP encryption available in Q3 2010. Based on the information supplied, this makes it unique among the SIP Trunk service providers who participated in this panel.
Intercarrier SIP Interoperability
We received two questions on this:
Q: What is the status of intercarrier SIP interoperability?
A: As a working interoperable standard, there is nothing concrete yet, but there are standards-bodies like the SIP Forum which are trying to address this. The i3 Forum has specified peering functionality for wholesale VOIP providers to use (to enable basic VOIP calls). Service providers typically employ SBCs to interconnect on a private basis. Many of the service providers who offer some ability to interconnect over SIP use the public Internet as their SIP peering interconnect method, but relatively few currently use private SIP interconnects. Of the carriers who responded to this question, only Global Crossing stated that it does this now.
Q: In a decentralized environment using multiple SIP carriers, what level of interoperability exists?
A: For many reasons I think decentralized computing and telephony environments are, more often than not, suboptimal. But sometimes they are essential (for instance, to support different entities that are currently part of a holding company).
Based on the response to the prior question, obtaining and maintaining a multi-carrier SIP environment requires a high degree of expertise and patience, and a good amount of tools on hand. Each provider has defined a SIP implementation that the enterprise must use. It specifies SIP signaling functionality, encryption and transport protocols, IP address types, codecs, fax methodology, telephone number formats, response codes, etc. that the service supports. So it's essential that the enterprise gateway or SBC adapt the enterprise SIP or H.323 environment to the SIP profile of a particular service provider(s). Some carriers, like Sprint, offer a "try and buy" program for SIP Trunk services. This type of program can help customers who are working through tough issues, including interoperability.
Calling Flexibility
Two questions from the audience were:
Q: How difficult is it to increase the number of concurrent call paths on demand?
A: Many of the challenges supporting these types of features aren't as much technically challenging as they are challenging from an OSS/billing perspective. Obviously, there also has to be sufficient bandwidth to support the additional traffic, and the premises equipment must support these features exactly the way the service provider does.
Of the service providers who participated in this panel, two can increase the number of concurrent call paths "on demand" across SIP Trunks (Verizon and Sprint). The two other provider panelists require a MACD/service order request.
Q: Do you offer the ability to increase the number of DIDs as needed (such as to support an emergency event or EOC--Emergency Operations Center--activation)?
A: None of the four providers indicated this can be done now via a customer portal. AT&T currently requires that all information concerning DIDs be correctly provisioned when initially configuring its SIP Trunking service. Verizon Business, Global Crossing and Sprint customers can increase/decrease the number of DIDs via MACD order. Depending on the carrier, once a MACD order is received, it can be turned around as quickly as one day.
Lisa Pierce is president of Strategic Networks Group.
