SIP connections

Top  Previous  Next

Since codec_name_arial12_001 system version 3.2.0.78 SIP is supported.

 

1. General

The Session Initiation Protocol (SIP) has been developed by the IETF (= Internet Engineering Task Force) and is described in rfc 3261 (www.ietf.org/rfc/rfc3261.txt).
This protocol can be used to establish, modify and terminate multimedia sessions and is currently used in most Voice over IP (VoIP) and Internet telephony applications.

As a client-server protocol, SIP is similar to HTTP and SMTP (e-mail). Its requests and responses are text strings containing information about the session that is to be established. SIP addresses are composed using a syntax similar to e-mail addresses e.g. sip:centauri3000@mayah.com.

 

The complete separation of signalling and transport layer (i.e. of connection data and media data), as implemented in SIP allows the user to establish a connection in a unified way without prior knowledge of the exact location of other participants and not depending on the nature of the transferred data. The SIP protocol can furthermore be used to let two devices auto-negotiate the parameters (e.g. algorithm, sample rate,...) of the multimedia session.

 

The constantly growing acceptance of SIP - due to recent developments in fields like Internet telephony and UMTS - guarantees for a steady growth and expansion of infrastructure. Since SIP supports the negotiation of bandwidth reservation and reservation is needed for good quality Internet telephony, network providers will need to deploy mechanisms for bandwidth reservation in their networks – a critical need for all professional Audio-Over-IP applications.

In addition SIP is also part of the “Next Generation Network (NGN)” as defined by the European Telecommunications Standards Institute (ETSI) and is thought to be a replacement for ISDN. Since ISDN will eventually disappear in most countries the designated successor has been appointed: SIP.

 

2. How SIP works

 

2.1 Application Example

 

sip005

 

The above diagram shows two CENTAURI's II 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 an 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:centauriB@mayah.com).

Now Centauri A 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. Now a direct session can 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

An SIP session between two 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. an automatic answer mode) the messages “Trying” and “Ringing” are not sent by the user agent.

 

sip006

 

A Session Description Protocol (SDP) file is appended to messages 1 and 3 (sometimes also to message 4). With the help of these SDP files the user agents can negotiate the parameters (algorithm, bit rate, sample rate) to be used 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.2 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.

 

sip007

 

The diagram 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 an “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 from the callee is then forwarded to the caller. The same happens to a “200/OK” message. The “ACK” message may then be sent directly to the callee, since the caller may have learned the current address of the callee.

Please note that from the point of view of any of the involved user agents the session establishment is not differing from the simple call flow in 2.2.2). The proxy server (or servers) are completely transparent to the user agents.

 

3. Configuration steps on codec_name_arial12bold_001 side
 

3.1 Codec settings

Configure the codec settings via menu item Settings/Codec:

Interface: IP/RTP
Encoder dependency: Remote
Encoder algorithm: Algorithm supported by the other side codec
Decoder dependency: Remote

3.2 Establish Connection

Click the CONNECT button to open the Connect-dialog:

Select interface to IP
Select SIP
Type in the SIP address
Click the OK-button to establish connection

 

sip004

 

4. Recommendable settings for miscellaneous SIP providers

4.1 T-Online

Registrar: tel.t-online.de
Stun Server: stun.t-online.de
Packet size: 156 Bytes (Configuration via  menu item Settings/Network)