Amusing prioritization of voice traffic in Telegram

Probably, many are interested in how the Telegram team managed to make the voice call function popular for messengers right after launch, strikingly different in quality for the better in front of many other VoIP services.

While studying the operation of Telegram Calls, I drew attention to an interesting technical detail, which is used at the network level and helps to reduce delays in the passage of packets when relay servers are used during the connection.

If you look at the traffic dump that occurs during a call in which the relay server was used, you will notice that the traffic is determined by the RIP protocol. IP at 91. - This is a Telegram server. I shot a traffic dump on my VPN server, so the client address is from the local subnet.



And here is a screenshot from the client debug, but at P2P. It is worth noting that the 520 port is assigned only to servers, therefore this method works when a P2P connection between clients is impossible and one of the servers from the list acts as a relay.



Recall that we know about the RIP protocol ?
RIP is a routing protocol. RIP works on the 3rd level of the (network) TCP / IP stack, using UDP port 520. UDP, that is, delivery that does not require receipt confirmation, as you know, in itself is excellent for real-time traffic, which is voice.

Routing protocols are needed so that routers can quickly exchange service information about networks connected to them and their neighbors. Route information updates are critical for quick network recovery when changes are made to it, so many network equipment manufacturers assign routing protocol traffic the highest processing priority. That is, they pass it ahead of all other traffic.

This prioritization is implemented in routers using DSCP codes (Differentiated Services Code Point), and by default, for example, in Cisco, according to RFC 791 and RFC 2474, RIP / RIP2 / OSPF / EIGRP routing protocols are marked with code 6. And this, for a minute , superior, internetwork control priority.



In addition to prioritizing DSCP, Cisco IOS also has an internal mechanism PAK_priority , which serves to provide priority for important datagrams exactly at the moment they pass through the router. PAK_priority designation was conceived by the developers of Cisco (and, we can assume, some others) equipment as critical for the correct operation of Cisco IOS, and therefore it can not be configured. This excludes the possibility for administrators to somehow influence the priority traffic pass, which has the Control characteristics for the system.

It seems that recalling the ancient protocol and the features of its work (useful UDP, the existence of the Unicast - exchange capability), Telegram architects used its port, thereby forcing many routers to process their traffic as very important on the route of packets, thereby, obviously, somewhat reducing delays.

It seems to be a small detail in the world of powerful codecs, but, as they say, the devil is in the little things - so why not make these little things work for the benefit of the ultimate goal?