Once you have performed the right steps to prepare for SIP deployment (see my previous post on SIP), it’s a good time to discuss the next part of your journey: successful SIP implementation. I will be discussing this process in greater detail at the International Avaya Users Group (IAUG) next week, but here’s a sneak peek.
To start the process off, perform a “Network Readiness Assessment” or NRA. Note, however, that this concept means different things to different people. I have seen some customers perform NRAs on their own in a variety of different ways, I’ve seen third parties perform them for customers, and some IP Telephony vendors require that the NRA be performed by them in order for them to support their product.
The overarching goal is to evaluate the network that you want to add SIP traffic onto. You need to make sure the network is ready to handle the traffic from both a volume perspective but also from a capability perspective, particularly if the network is intended for both voice and data traffic (which is kind of the point). What I mean by “capability” is that you must ensure that the network switches within your environment enable “Quality of Service,” or “QoS”, to allow for the voice-related packets on the wire to be prioritized over other non-real-time traffic like data, email, web, etc.
The process for a NRA should be multi-stepped:
- Step 1: Look at the network from the topology, bandwidth, and device capability perspective to ensure the core requirements are met.
- Step 2: Include some form of synthetic voice or media traffic generation at key locations within the network RTP. This traffic must sent between points to simulate the load of the network that is similar to that of phone calls, and measure quality- and quality-related statistics like packet loss, jitter, and latency.
- Step 3: Once the results of that media traffic generation have been analyzed, recommendations for changes to the network should be made.
- Step 4: Make the changes necessary and repeat steps 2-3 if necessary.
- Step 5: Congratulate yourself – you have now validated that the core network plumbing is ready for SIP.
Another key area to think about is something that people typically don’t associate with voice and voice applications: security. With SIP taking voice over the data network in from the carrier and throughout the entire network, security is something that must be considered, like it is with other data networks.
Much like with the web, SIP can be used for DDoS attacks from inside or outside of the network, and it is the SBC or other boarder controller device’s job to handle those types of issues. Common attacks include SIP registration floods, endpoint spoofing, and ENUM attacks. SBCs should be tested to see how they handle these, in order for you to understand the expected behavior under these conditions and the impact on the overall network health and quality.
The other area you must consider related to security is whether or not to encrypt your SIP traffic, which is typically done via TLS for signaling and SRTP for media. Encrypting SIP traffic can have an impact on the overall scalability and performance of the IP telephony equipment that you choose to move forward with and it can be a significant trade-off.
Once you have made your design and vendor choices, decided how the network will be architected, and deployed the IP telephony equipment, it is important to execute a pre-deployment performance test end to end. Much like a CIO today would not take a new customer-facing web application live without performing some level of performance testing, the same should be true for your SIP deployment.
I wanted to make sure I addressed this item in the same post as the NRA as often either the two are confused or people are lead to believe that because they did an NRA, they don’t need to perform a performance test prior to go live.
As I stated above, the NRA is focused purely on the network and making sure it can carry voice, and it is exercised at some volume of simulated traffic. An end-to-end pre-deployment performance test involves real phone calls into your service provider through your core telephony infrastructure and applications and out to the end location where the call will terminate.
In this case, the network is involved, but it is not the focus like it was in the NRA. In the entire IP telephony stack I am referring to, there are SBCs, IP PBXs, voice gateways and other applications that are now involved in handling real phone calls. And these are likely provided by a few different vendors that are now required to interoperate with the network and devices to make these “simple” phone calls happen.
Now we are looking at an entire IP telephone solution to make sure it scales to meet the business needs and delivers a high level of quality to the users of the solution. I also believe this type of testing can help speed and ease multi-phase deployments and allow you to validate the core infrastructure to the end game in terms of scalability when all of your sites are deployed. Otherwise you may very well find a devastating issue in the core months into a deployment.
In addition, you can test adjunct voice applications such as centralized voicemail, conference bridging, and dial by name directories, and expand into contact center-focused applications.
I am looking forward to presenting at IAUG next week on the subject of SIP and hope to see many of you at the conference. Feel free to talk with me there and ask me any questions you have about SIP. Or, if you won’t be able to make it to the conference, feel free to provide feedback or questions in the comments below.
Be on the lookout for Part 3 of this series of posts, where I’ll be posting tips about post-deployment considerations, feedback from the attendees of IAUG and my thoughts on the conference.
For more information about SIP, learn about Getting the Most Out of Your Migration to SIP Trunking.