One of the benefits pushed by SD-WAN vendors is the ability for the SD-WAN connection to provide a fixed ‘virtual’ public IP address for a customer, mainly to support VoIP calls. This can be one of the more expensive portions of an SD-WAN setup.
The need for the fixed IP is driven by fact that some VoIP providers use the source public IP and port of the voice RTP streams that originate from the customer site to associate the RTP streams with specific calls. This is fine when there is only a single WAN connection to the customer site, with a static IP assigned by the ISP. In that case, the source public IP will never change, and the VoIP provider can use it as part of call connection tracking. However, what happens when there are two ISP links to the customer site, with failover from the primary link to the secondary link? When failover occurs, the source public IP of the RTP streams will change. (Obviously you can’t have outbound packets maintain their source IP address if you’ve just switched over from one ISP link to another!) If the VoIP provider is tracking connection state using the source public IP, then this looks like the connection was interrupted; there are no more packets from the old – failed – ISP public IP,
and there are all these unknown packets arriving from the new – secondary – ISP public IP. This will cause the voice call to drop.
The traditional solution by an SD-WAN vendor involves backhauling (i.e., tunneling) all the traffic from the customer site to a dedicated Point of Presence (PoP) somewhere, preferably very close to the customer. At the PoP, the traffic is removed from the tunnel and allowed to exit to the Internet through a router with a fixed public IP on its peer interface. NAT is used to make the VoIP traffic look like it is originating from this public IP, rather than from the customer’s actual ISP-assigned IP address. Now, when the primary link fails to the secondary link, the VoIP provider doesn’t see anything changing; this is all hidden by the SD-WAN vendor between the customer site and their router. Of course, this gets rather expensive quite fast – VoIP is heavily dependent on loss and delay, and to minimize the delay you need a PoP as close to the customer’s physical site as possible. With a lot of customers across the country, that’s a lot of PoPs! Also, while hosting these PoPs the vendors often cap the amount of throughput into and out of their servers. Want more bandwidths? It’s going to cost you! So even though you may have a 400Mbps link from your internet service provider your SD-WAN PoP could be curbing the link down to 10Mbps.
But there is another option!
The RTP protocol headers (see RFC3550) already contain identifiers such as the Synchronization Source (SSRC) field that can be used to identify the VoIP connection to which the RTP streams belong. It turns out that many VoIP vendors actually use this state information, rather than the source public IP of the packets, to determine how to map and process the VoIP streams. What this in turn means is that the VoIP call is tolerant of failover from a primary to a secondary link – without any backhauling to a PoP! Provided that the failover occurs fast enough, not only is the voice call not dropped, but there is very little perceived impact to the call quality. The user perceives a second or two of silence and then the call continues as normal. (We’ve all been trained by our cell phones to tolerate a lot of things that would have been unacceptable in the days when Ma Bell ruled the roost …)
Uplevel has verified this “fast failover” with several VoIP vendors (Freedom Voice, Jive, and others), and have certified its compatibility, completely eliminating the need for a virtual IP. You can watch and listen to the video here. With Uplevel we monitor the public IP address of the gateway and use Dynamic DNS to allow customers and outside services consistent access back into the network. And, since the gateway is physically located on the network there is no secondary hop and throttled bandwidth to provide consistent reliable VoIP calls.
You may not need an expensive fixed public IP as part of your SD-WAN setup, just an Uplevel router!
Recent Comments