Table of Contents
Centauri user manual revision level 01 /2007
71
2. How SIP works
2.1 Application Example
The above diagram shows two Centauris in a possible SIP scenario. While Centauri A is at
a well known fixed location with a fixed IP address (e.g. in a control room) Centauri B is
built into an OB van and therefore uses an IP address unknown to Centauri A. A direct
session establishment from Centauri A to B (e.g. using a direct RTP connection) is
therefore not possible.
To establish a session via SIP the first step to be taken is a registration of Centauri B with
a registration server. These servers are usually located at a SIP service provider or ISP.
In-house solutions (e.g. using an Asterisk Server) are also possible.
By registering itself with the registration server the current IP address of the mobile
Centauri is mapped to a SIP address (like sip:[email protected]).
Now Centauri A: be can use this SIP address to connect to Centauri B. To accomplish this
Centauri A first contacts a Location Server that maps the SIP address to the current IP
address of Centauri B and redirects the call to this IP address. A direct session can now
be established between Centauri A and B. (For a more detailed explanation of this process
please see 2.2.3) )
2.2 A closer look at SIP
2.2.1 Simple Session establishment
A SIP session between to clients is established using a handshake mechanism. Illustration
2 shows a simple call flow used to establish and terminate a media session. After an
invitation by user agent 1 (UA1) the callee user agent 2 (UA2) tries to find the requested
callee (2: 100/Trying) and indicates the incoming call to the user (2: 180/Ringing). If the
user at UA2 accepts the call a “200/OK” message is sent and UA1 acknowledges the
response with an “ACK” message. Now a direct media connection between the two user
agents is established. In some cases (e.g. a automatic answer mode) the messages
“Trying” and “Ringing” are not sent by the user agent.
A Session Description Protocol (SDP) file is appended and to messages 1 and 3
(sometimes also message 4). With the help of these SDP files the user agents can
negotiate the parameters (algorithm, bit rate, sample rate) to use with the media
connection. While this mechanism is suitable and well-defined for VoIP applications, where
the number and parameters of algorithms are limited, it requires some further
improvements in order to function with a larger number of professional algorithms.
To terminate a session, any user agent simply sends a “BYE” message which is
acknowledged by a “200/OK” message from the other end. Then the session will be
terminated.
2.2.3 Call Proxying
The above example of a direct SIP session between two clients is of course neither
practical nor realistic. Most of the time, as stated in the example given in 2.1 intermediate
servers are involved in a session establishment. One of the most common types of servers
is a proxy server. If connecting through public networks a SIP negotiation will most
probably involve one or more proxy servers.
The diagramm above shows what a typical call flow including a proxy server looks like. For
reasons of simplicity the picture shows only one proxy server between the clients, where in
most public networks there would be a chain of several proxy servers. The proxy server in
this example is able to provide a location service by the means of a connection to a
location server. When the proxy receives a “INVITE” message it checks with the location
server to find out the current location (IP address) of the callee (UA2) and responds to the
caller (UA1) with a “100/Trying” message. In a next step the server sends the (modified)
“INVITE” message to the callee. A “180/Ringing” message received by the proxy server
