We have two office connected together with a SSTP VPN. In one of them there is a VoIP server and a SIP phone in the other,
Latency within the VPN tunnel is quite good, but while a SIP call is in progress, the latency doubles… at least. (see attached image below)
This is the ping test from “remote” office to the “local” gateway just at the moment when the SIP call ended.
At the same time, the ping outside the VPN (pinging to the public IPs of remote sites) are allways fine.
I’ve tested it using others VPN like L2TP, PPtP and IPSec (without L2TP)… exactly the same issue.
I’ve tested it in others VPN site-to-site with severals ISP involved… exactly the same issue.
I’ve seen the same issue using a Yealink VoIP server or a Avaya’s.
The first thing which comes to my mind is a slow line (tens of kbps) or weak processor handling the SSTP encryption effectively causing the same, and sending or encryption of the RTP packets causing delay of the icmp packets as the icmp request packet cannot be sent until the previous RTP packet leaves, and the icmp response packet cannot be sent from the opposite side until the previous RTP packet in that direction is sent.
What is the bandwidth on the slowest part of the path between the sites, and what does /tool profile show while the SIP call is ongoing?
Speed test on one side is arround 300Mbps and 20Mbps on the other side.
At the time of the ping test, bandwith usage was under 1Mbps. In fact, was just the SIP call and some casual browsing and normal network “noise”.
Tried many VPN types thinking that was a VPN collateral issue: seeing that SSTP uses a perfect 1500 MTU regardless real MTU, for sure there is a hiden fragmentation as one side is a PPPoE conection with de 1480 infamous Mikrotik PPPoE MTU.
Maybe could be a hiden processing related issue. But this would mean that some RB are not good for this at all. CPU ussage was always below 5-7%, even with the SIP call in progress,
RB is 3011 in central side. On remote side I tried a 750 and a 450. I could trie with a 3011 in both sides,
So, yeah. I agree with you that seems some kind of “bottleneck” where SIP takes priority over, at least, ICMP.
One test I could do is a UDP ping or even a “TCP ping” to see if the delay increases too.
Priority alone would not be sufficient given the link speeds. An RTP packet typically has some 250 bytes so 2000 bits, so at link speed of 20 Mbps, transmission of such packet takes about 0.1 ms, while the delay you observe is in tens of milliseconds. Priority just means that when the sending mechanism chooses between two packets waiting for transmission, it chooses the one with higher priority, and the other one has to wait until the one with higher priority has been sent; then, a new choice is made as another high priority packet may have arrived in the meantime. But there is a 20 ms (typically) gap betwen the RTP packets, so the icmp one should in most cases only be delayed by that 0.1 ms unless the “network noise” would interfere. But all that applies if you did implement some QoS handling, otherwise there is a single common queue so the packets are not prioritized.
It would be interesting to capture the SSTP packets and the RTP packets coming from the phone into a single capture file to see whether the SSTP optimizes transmission by packing several RTP packets into a single transport one or whether it transports each RTP packet in its own transport one. Such optimization would explain the delay.
