In order to understand the subsequent sections, you must understand a few things about SIP and RTP. First of all, SIP is a signalling protocol handling the call control like inviting to a call, cancel (hang up while ringing), hanging up after ended call and so on. SIP messaging can be done directly from user agent to user agent, but often a SIP server is needed for one user agent to find another.

When a SIP server like SER receives a message, it can decide that it wants to stay in the loop or not. If not, SER will provide the user agents with the information they need to contact each other and then SIP messages will go directly between the two user agents.

If SER wants to stay in the loop, for example to make sure that a BYE message is received for accounting, SER must insert a Route header in the SIP message (using the record_route() function) to tell everybody that it wants to participate. In order for this to work, SER and potentially other SIP servers who participate must do what is called loose routing. A bit simplified, it means that SIP messages should not be sent directly to the user agent, but rather indirectly via all who have put a Route header in the SIP message (to check for such a recorded route, the loose_route() function is used).

SIP can also include additional information, for example related to how to set up a call with an audio or video stream (called SDP, Session Description Protocol). The SDP information will result in one or more RTP streams (or sessions) to be set up, normally directly between the two user agents. SER will NEVER participate in the RTP stream. RTP streams are by nature bandwidth and processing intensive. However, as we will describe later, SER can make sure that a third party application like a B2BUA or RTP Proxy can become the middle man.

Finally, the Real-Time Control Protocol (RTCP) communicates information about the RTP streams between the user agents (RTCP will either use the specified RTP port + 1 or the port indicated in the SDP message).