Interesting prioritization of voice traffic in Telegram

Probably, many people wonder how the Telegram team managed to make the voice calls function, popular for messengers, immediately after the launch of a strikingly different quality for the better in front of many other VoIP services.

While studying the work of Telegram Calls, I noticed an interesting technical detail that is used at the network level and helps to reduce delays during the passage of packets when the relay servers are used when connecting.

If you look at the traffic dump, which passes when you call using the relay server, you will notice that the traffic is determined by the RIP protocol. The IP at 91. is a Telegram server. I filmed a traffic dump on my VPN server, so the client’s address is from the local subnet.


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



Recall what we know about the RIP protocol ?
RIP - routing protocol. RIP operates at layer 3 (network) TCP / IP stack using UDP port 520. UDP, that is, delivery that does not require confirmation of reception, is known to be in itself perfectly suited for real-time traffic, which is voice.

Routing protocols are needed so that routers can quickly exchange service information about the networks connected to them and their neighbors. Updating route information is critical to quickly restoring a network to work as it changes; therefore, many network equipment manufacturers assign routing protocol traffic the maximum processing priority. That is, they pass it ahead of the rest of the 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, the routing protocols RIP / RIP2 / OSPF / EIGRP are marked with code 6. And this, for a moment , superior, Internetwork Control priority.



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

It seems that having remembered the ancient protocol and the peculiarities of its work (useful UDP, the existence of the Unicast exchange capability), Telegram architects used its port, thereby forcing many routers along the way of packets to process their traffic as very important, thereby, 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 details - so why not make these things work for the good of the final goal?