Background

In this post we would like to share with you a rare phenomenon we have seen in few sites that once it appears, it can cause a head ache to the network administrator. As opposed to the old telephony networks that was based on dedicated physical cables per call, usually twisted pair, the cables in VoIP network are virtual. As a result, when the virtual cables are not 100% isolated, the audio of two different calls might get mixed. In this post we will discuss SIP networks but the logic is the same for all other VoIP protocols.

Isolating the audio

SIP in a nutshell

SIP based networks have two main layers:

1. SIP – signaling, handshake, call initiation, call termination etc. During handshake phase, RTP port numbers (i.e. the virtual audio cables) are disclosed.
2. RTP – the audio itself. The audio is streaming in the virtual cables (RTP ports) that were disclosed in the SIP messages.

What can go wrong?

In theory, if all the vendors implement the full comprehensive SIP protocol by the book – nothing could go wrong. But, in reality, there are many implementations of the SIP stack and most of them do not fully comply with all the nuances of the SIP protocol.  As a result malfunctions can rarely happen. For example, when one party to the call decides to terminate the call, the terminating SIP message might not arrive to the other  party or might be misinterpreted. As a result, audio (RTP packtes) from the other party might continue to arrive on the same RTP port. Whenever the RTP port will be re-used for a new call the audio of the old call might get mixed with the audio of the new call.

What can be done?

Do not put your trust in a single layer and make sure you have an additional layer that can preemptively resolve such unfortunate scenarios. In other words, do not rely only on the SIP protocol but also make sure your IP network has the capability to alert the participants when such unfortunate scenario occurred. The most important built-in message that you should be familiar with is ICMP. This message is automatically generated when packets are send to a port that was closed. Taking a look at our previous example, this means that when the old call was terminated its RTP ports are marked as “closed” and therefore any attempt to send RTP packets (i.e. additional audio) to this port would result in ICMP alerting the sender that the port is closed and no more audio should be sent. Using this simple mechanism, the sender would understand that the call was terminated and will stop sending additional audio to this port.

Anything to pay attention too?

Although your IP network provides a built-in protection layer for these cases via the ICMP message, there are cases where firewalls are configured to block ICMP messages or silently dropping them. Now, once you have read this post, we are sure you understand the importance of allowing these ICMP built-in messages and you will make sure they are not blocked or dropped by your firewall.

ICMP packets on closed RTP ports should be approved