SIP trunks can be deployed over the Internet or over a dedicated private WAN connection (MPLS typically); each, with supposedly clear pros and cons. In reality, there's a bit of confusion around this topic and a decision is not necessarily straightforward.
There is great deal of public literature around the subject if you want to dive deeper into each aspect. The purpose of of the article is only to provide a quick reference table for elements and criteria that should be considered and discussed to determine which circuit is most suitable.
Feature | Internet-based SIP trunk | MPLS-based SIP trunk | ||||
---|---|---|---|---|---|---|
Pros | Cons | Mitigating factors | Pros | Cons | Mitigating factors | |
PROVISIONING | Fast delivery times. Easy to set up | Slower delivery times. More complex to set up. Likely to require a dedicated circuit to SIP trunk carrier | If core MPLS carrier is also a Telco might be able to provide SIP trunk on existing circuit | |||
COST | Relatively cheap - lower TCO | Expensive - higher TCO | ||||
NETWORK READINESS | Pratically 100% businesses already connected to internet and might potentially have capacity for SIP trunking. If not, in-place bandwidth upgrade is usually viable and requires no infrastructure upgrade | Higher investment for small businesses that don't have MPLS circuits in place | ||||
BANDWIDTH | Relatively abundant and cheap | Bandwidth is not guaranteed (best effort, no SLA). Asynchronous connections like ADSL provide limited upstream bandwidth | Ensure accurate capacity planning is carried out to ensure bandwidth is adequate for expected number of PSTN sessions. Lync CAC may also help | Bandwidth is guaranteed with SLA | Significantly more expensive than Internet bandwidth | Appropriate capacity planning and QoS adoption would make significantly more efficient use of bandwidth |
AVAILABILITY | Uptime is not guaranteed (best effort, no SLA) | Redundant internet connections to different carriers may reduce downtime | Uptime is usually guaranteed with SLA and significantly higher that internet connections | |||
NETWORK PERFORMANCE | More network hops, more subject to packet loss, latency and jitter. Unpredictable performance irrespective of bandwidth | Geographically closer SIP trunk carriers might require fewer hops to their infrastructure. | Network performance is more predictable especially if QoS is implemented. MPLS less subject to packet loss, latency and jitter | |||
CALL-CARRYING CAPACITY | Usually more abundant nominal bandwidth theorically allows for a greater call-carrying capacity | Call-carrying capacity is influenced by many other factors and network conditions, which become more likely as sessions are added on the wire. Internet-based SIP trunking is generally advisable for low call volume requirements | Call-carrying capacity is more easily predictable and voice traffic can be shaped. MPLS-based SIP trunking advisable for higher call volumes | |||
QoS | QoS cannot be implemented end-to-end. Traffic cannot be prioritised by type | Buying a dedicated additional Internet line for SIP trunk would help segregating data/web and voice traffic, yet proper QoS is not achievable | QoS can be implemented. Proper traffic prioritisation by type is viable | |||
SECURITY | Voice traffic flows through uncontrolled network and may potentially be intercepted. | Use a SIP trunk provider that supports TLS (encrypts SIP signalling and SRTP (encrypts media), or deploy SIP trunk through VPN (less recommended: adds further network overhead and may impact QoE) | Voice traffic flows through private and screened network. TLS and SRTP are still advisable for enhanced security | |||
NAT | SIP protocol not NAT-friendly, several known issues when NAT is used | Prefer avoiding NAT when deploying SIP trunk. Alternatively, ensure firewalls are SIP-aware (SIP ALG) | NAT less likely to be deployed in MPLS network, but if so, same considerations apply | prefer avoiding NAT when deploying SIP trunk. Alternatively, ensure firewalls are SIP-aware (SIP ALG) |
No comments:
Post a Comment