Introduction

A SIP client or server has generally a huge number of parameters, in order to provide the maximum flexibility to adapt to various use-cases. In the context of a classic deployment, with mobiles or desktop apps, to work on public internet, what would be the best practices, the most recommended settings ? This article will expose the Linphone team advice.

Use SIP/TLS

No matter whether security is important for you, SIP/TLS is definitely the best option. Others have painful drawbacks:

  • SIP/UDP and SIP/TCP are unsafe because of SIP-aware NAT routers. Indeed, many wifi routers, home routers, DSL routers, have a built-in NAT logic to handle SIP specifically. While it was originally designed to workaround some usual address translation issues (in Via, Contact headers, in SDP message etc), this logic has proven to be mostly broken. We have seen routers rebooting because they were crashing while handling a SIP message. The only solution is then to encrypt the SIP message, so that such routers don't do anything specific with it, just basic IP packet routing. Linphone and Flexisip have their own built-in nat aware algorithms, they don't need any router assistance at all. SIP/TLS is also the best solution to encrypt SIP in Linphone and Flexisip.
  • SIP/UDP suffers from the network MTU. Though a UDP fragmentation protocol exists for big packets, it is very often not supported or rejected by internet routers. As a result, there is a high risk that any SIP packet above 1440 bytes will never reach its destination. Having an INVITE or 200OK bigger than MTU is extremely frequent. If you enable more codecs, enable ICE, add a video stream, the SDP part of the INVITE grows very significantly.

Forget about keep-alives for mobile apps, use push notifications

SIP keepalive packets (\r\n\r\n), whose goal is primilary to keep the connection between client and server alive across NAT routers, are a bad practice for mobiles. They drain the battery by forcing the phone to wakeup to let the app handle this traffic. Fortunately phone manufacturers and mobile OS have solved the problem by killing apps in background automatically, or at least cut their access to the network. Push notifications must be used to wake-up apps each time they need to receive a message or INVITE.

Use ICE

Unless your SIP server is a PSTN gateway, or a back to back user agent that needs to read the media streams established between clients, ICE coupled with media relay service such as TURN, is the only way to guarantee that RTP packets are delivered in an efficient way between clients. Don't try to use STUN solely, don't expect clients to know at once what their IP address/port used for media will be. This is not possible.

Enable AVPF if you use video

AVPF adds some very interesting RTCP message called PLI (Packet Loss Indication), SLI (Slice Loss Indication), RPSI (Reference Picture Indication), that allow fast error recovery of video when packet transmission errors occur. Their alternative is the legacy SIP INFO packet containing a VFU request (Video Fast Update), which is horribly slow because it is carried over all the SIP infrastructure on TCP or TLS, while RTP/RTCP is often directly exchanged over UDP between clients. Don't expect to have reliable video quality without AVPF.

AVPF is enabled by default in Liblinphone, visible in the "a=rtcp-fb" attributes in the SDP messages. To be effectively used, both caller and callee must support it, and if the server is a back to back user agent, it shall also support it.

 

Tags:
Created by Simon Morlat on 2019/05/24 15:56