- Geographic and Regulatory Considerations
- IP Connectivity Options
- Dial Plans and Call Routing
- Supplementary Services
- Network Demarcation
- Security Considerations
- Session Management, Call Traffic Capacity, Bandwidth Control, and QoS
- Trunk Provisioning
- Scalability and High Availability
- SIP Trunk Monitoring
- Further Reading
Cisco Unified Communications deployments offer a rich set of supplementary services. With the use of SIP trunks, how these services operate might change, and you need to evaluate how they can be maintained when a SIP trunk brings external calls into your enterprise.
Following are different areas of supplementary services to evaluate:
- Voice calls
- Voice mail
Telephony features such as call hold/resume, call transfer, call waiting, three-way conferencing, distinctive alerting, calling line identification (CLID), calling name, and call toggle can be provided by CUCM Express and CUCM for IP phones and by a voice gateway for analog phones. IP Centrex or Class 5 type features (for example, call forwarding, call screening, call park, call return, and so on) can be provided by central SIP servers resident in the service provider's network. An analog phone in the enterprise can trigger these features with access codes (typically starting with an asterisk) provided by the service provider. Cisco Unified Voice Gateways send the access codes in the SIP INVITE message over the SIP trunk to the service provider to trigger these features.
You can provide voice mail within the enterprise network in a distributed design using Cisco Unity Express or with a centralized design using Cisco Unity or Cisco Unity Connection. You can also choose to get voice mail services from the service provider using a hosted solution (a cloud-based service).
Message Waiting Indicator (MWI) is a visual light on IP phones; it is indicated by a stutter dial tone on analog phones. MWI for enterprise-provided voice mail systems is not impacted by SIP trunking, but if a service provider hosted solution is chosen, MWI indications are provided via SIP indications (as per RFC-3842) from the service provider system and are relayed to the enterprise endpoints. Be sure to test these scenarios for SIP trunking if this is your deployment model.
Dual-tone multi-frequency (DTMF) interworking is often needed for voice mail as well. Even if all the communicating systems use SIP, there are various ways of relaying DTMF in SIP. DTMF interworking is discussed in more detail in Chapter 9, "Questions to Ask of a Service Provider Offering and an SBC Vendor."
When offnet access was provided by TDM access to the PSTN, codec choices were entirely within the control of the enterprise. Codecs were configured on IP endpoints, enterprise applications, and TDM PSTN gateways. Codec choices did not affect offnet calls in any way.
With SIP trunking entering your network, this is no longer the case. Codec choices are now end-to-end on the IP segments and enterprise endpoint negotiated codecs with external endpoints and application controlled by other networks. Codecs offered by external endpoint might be against the bandwidth (call admission control) policies of your enterprise network, or your older endpoints might be incapable of supporting some of the newer codec choices, resulting in failed calls or inappropriate bandwidth use on your network.
Sometimes SIP trunking is a cost-effective choice only when G.729 is the codec chosen (for bandwidth delivery reasons), especially for high volume contact centers operations.
For all these reasons, it might be necessary to do transcoding at the border of your enterprise network to change the codec to the appropriate one before these calls enter your network. Local Digital Signal Processing (DSP) can provide transcoding for a call that uses a high-bandwidth codec such as G.711 on one side and a low-bandwidth codec such as G.729 or Internet Low-Bitrate Codec (iLBC) on the other side. Transcoding is discussed in more detail in Chapter 9.
Mobility of users in the enterprise is often aided by various call forwarding features. Calls between internal numbers can end up being forwarded externally due to a call forwarding mobility feature.
Another call flow to consider is an external call that arrived via the SIP trunk into your enterprise, which, in turn, is forwarded from the internal endpoint to a second external destination via the same site's SIP trunk, or if you have distributed SIP trunking deployed, perhaps a different site's SIP trunk. This call flow consumes the bandwidth equivalent to two individual calls.
Single-number reach call flows, where a single phone number is set up to ring a user's desk phone and an alternate mobile device such as a cell phone (which is often physically resident on an external network), should also be considered and tested. These call types have unique requirements for transfer, forwarding, voice mail.