TURN In Few Words


TURN is abbreviation for Traversal Using Relays around NAT. It is a control protocol that allows the host behind a NAT to exchange packets with its peers using the relay.  It is specified in the RFC [5766]. The following are few words about this protocol:

  • TURN is part of the ICE (Interactive Connectivity Establishment) but it can be used without ICE.
  • TURN is designed to solve the communication problem when both the client and its peer are behind respective NAT where the hole punching techniques (discovering direct communication path) may fail. In other words TURN is used when a direct communication path between the client and the pair can NOT be found.
  • The public TURN server sits between the two hosts that are behind NAT and relays the packets between them.
  • TURN is client-server protocol. The client is called TURN client and the server is called TURN server.
  • The TURN client obtains (using the TURN protocol -Allocate transaction) on the TURN server what is called relayed transport address (IP address and port).
  • The client sends CreatePermissions request to the TURN server to create permissions (permissions to validate the peer-server communication).
  • The TURN server sees the messages coming from the client as it is coming from a transport address on NAT. This address is called client’s server-reflexive transport address.
  • The NAT forwards packets coming to the client’s server-reflexive transport to the client’s host transport address (private address).
  • The TURN server receives the application data from the client, make the relayed transport address as the source of the packets and relays them to the peer using UDP datagrams.
  • The peer sends the application data in UDP packets to the client’s relayed transport address on the relay server. Then the server checks the permissions and on validation it relays the data to the client.
  • A way to communicate the relayed transport address and peers addresses (server-reflexive transport addresses) is needed (out of scope of the TURN protocol).


  • In VOIP, if TURN is used with ICE, then the client puts its obtained relayed transport address as an ICE candidate (among other candidates) in the SDP carried by the rendezvous protocol like SIP. When the other peers receives the SIP request, they will know how to reach the client.
  • The TURN messages (encapsulation of the application data) contains an indication of the peer the client is communicating with so the client can use a single relayed transport address to communicate with multiple peers. This is when the the rendezvous protocol (e.g. SIP) supports forking.
  • Using TURN is expensive so when TURN is used with ICE, the ICE uses hole punching techniques first to discover the direct path. If the direct path is not found, then TURN is used.
  • Using TURN makes the communication no longer peer to peer communication.

More Information



Transferring Data Using cURL



cURL is free and open source tool used to transfer data. I will show you as an example how to use it to transfer data with the cloud.  Here i will send the commands from Linux console to Openstack. The following are the steps:

Taking An Authentication Token

You need to send an authentication request to the cloud identity web service and get a token in the response upon successful authentication:

# curl -s https://YOUR-Cloud-Identity-Service-URL -X ‘POST’ -d ‘{“auth”:{“passwordCredentials”:{“username”:”YOUR-UserName”, “password”:”YOUR-Password”}}}’  -H “Content-Type: application/json” | python -m json.tool

Upon successful authentication, you will get the response in JSON format. To make the output easy to read, you can direct the output to the “json.tool” python tool as above.

One of the important information in the response is the authentication token which will be passed in the header “X-Auth-Token” in each request you send. You need to extract the token from the JSON respone. You can use the “jsawk” tool.

“jsawk” Installation

Follow these steps to install “jsawk”:

# yum install js, js-devel

# curl -L http://github.com/micha/jsawk/raw/master/jsawk > jsawk

# chmod 755 jsawk && mv jsawk /usr/bin/

Note curl is used here also.

 How To Use “jsawk”

You direct the response to “jsawk” and ask for a specific property in the JSON response. You can also do some modifications. See the examples in “jsawk” github page.

 More Information

Linux NAT Using Conntrack and IPtables


Doing the Network Address Translation (NAT) into Linux kernel scales the performance up. This mechanism consists of two parts:

The Connection Tracking/Conntrack Modules

It is a tracking technique of the connections. It is used to know how the packets that pass through the system are related to their connections. The connection tracking does NOT manipulate the packets and It works independently of the NAT module. The conntrack entry looks like:

udp 17 170 src= dst= sport=137 dport=1025 src= dst= sport=1025 dport=137 [ASSURED] use=1

The conntrack entry is stored into two separate tuples (one for the original direction (red) and another for the reply direction (blue)). Tuples could belong to different linked lists/buckets in conntrack hash table. The connection tracking modules is responsible for creating and removing the tuples.

Note: The tracking of the connections is ALSO used by iptables to do packet matching based on the connection state.

The NAT Modules

The NAT modules do the NATing itself. They use the tuples and modify them based on the NATing rules. In this way the tuples in the connection tracking table remains in consistent state.


If the packet belongs to an existing connection, this means there is already a conntrack entry (two tuples) in the conntrack table. The NAT module knows this by checking a field in the tuple created for the new arrived packet. Then the packet manipulation is done based on the conntrack entry (The manipulation is determined previously).

If the received packet represents a start of a new connection (first packet), the NAT module looks for a rule in the “NAT” table. If a rule is found, the NAT manipulation will be applied based on the rule and the tuples in the conntrack table will be changed. The tuples are created by conntrack at local outtput hook point before NAT for SNAT (Source NAT) so they need to be updated after doing the NAT for the first packet.

Assume the packets are leaving on network interface “eth1″(-o means “output”) to the internet and the interface “eth0” is connected to the local network. To change the source addresses to  and the ports 1-1023, you can add this rule:

# iptables -t nat -A POSTROUTING -p tcp -o eth1 -j SNAT –to

You can specify a range of IP addresses as well (SNAT –to

You can also use what is called MASQUERADE where the the sender’s address is replaced by the router’s address.

# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Note: Here i am doing SNAT (Source NAT). You can also do Destination NAT (DNAT) where the conntrack hooks into pre routing hook point. To write DNAT rules, use the chain  PREROUTING and the target DNAT.

NAT Settings

  • You need to load the “nf_conntrack”: # modprobe nf_conntrack
  • You need to start iptables service: # systemctl start iptables
  • You need to enable IP_Forwarding:
    • Temporarily: # echo “1” > /proc/sys/net/ipv4/ip_forward
    • Permanently:  Write net.ipv4.ip_forward = 1 in the file “/etc/sysctl.conf ” and reload (# sysctl -p).
  • Then set NATing rules as mentioned above.
  • Add Forwarding rules to forward packets from one interface to another in both direction:

From the public (interface:eth1) to private(interface eth0):

# iptables -A FORWARD -i eth1 -o eth0 -m state –state RELATED,ESTABLISHED -j ACCEPT

From private(eth0) to public(eth1):

# iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

  • Finally you need to save the IPtables rules to be persistent: # iptables-save


  • If you got this error “nf_conntrack: table full, dropping packet“ and you have enough free memory , you can expand the size of conntrack table, click here.

More Information

OpenSIPS and SIP PATH Extension



RFC 3327 (SIP Path Extension) specifies a way to discover and record the sequence of proxies between the UA and the registrar. The constructed routing path will be stored in the database of the registrar along with the corresponding contact address. Each intermediate proxy (NOT terminating routing point) that wants to stay in the routing path, inserts its URI as a new “Path” header field (or as value in the “Path” header field). This mechanism is applied only to requests that are transiting or originating in the home domain. The constructed routing path will be carried as pre-loaded Route set in the upcoming initial requests. This mechanism is similar to the operation of Record-Route mechanism in dialog-initiating requests (In-dialog/Sequential requests) and it can be combined with it (Example – Invite Transaction).

In this article i will talk about SIP Path extension in OpenSIPS context.


Assume we have this scenario:

UA1 – – – – P1 (Outbound Proxy) – – – – P2 – – – – Registrar/Home-Proxy (OpenSIPS) – – – – UA2

The outgoing proxy is the first hop after client’s NAT . The home proxy is a terminal point for SIP routing. The requested path starts by the outgoing proxy and ends at the registrar/home proxy. It is not common that the UA adds a “Path” header field in the request.

OpenSIPS As Registrar/Home-Proxy

OpenSIPS “Registrar” module has “Path” support. When OpenSIPS receives a SIP Register request, it calls the function save(..), among others. Upon calling this function, the values of the Path header(s) along with the contact address will be stored in the database (User Location Table). The contact address will be stored in the column “contact” and the values of Path header(s) will be stored in the column “path”.

In our scenario, if the proxies P1 and P2 receive a Register request and want to be in the path vector, each one adds its own SIP address as a top most value in the “Path” header field and forward the request. When the request reached the registrar, the path vector will be: Path: <sip:P2.testdomain.com;lr>,<sip:P1.testdomain.com;lr>.

The function save(…) takes some flags as a single string parameter. Among others, we have these flags that are related to the “Path” support:

  • p0‘ (OFF Mode): The path vector will be saved in the user location table but it will not be included in the reply of the Register request.
  • p1‘ (Lazy Mode): The path vector will be saved in the user location table and it will be included in the reply only if the UA indicated path support in the request (add the tag “path” as a value in the “Supported” header field of the request: “Supported: path”).
  • p2‘ (Strict Mode): The path vector will be saved in the user location table only if the the UA indicated path support in the registration request (add the tag “path” as a value in the “Supported” header field of the request). If it is not indicated, the request is rejected with “420 – Bad Extension” and the header “Unsupported: path” will be included in the reply along with the received path vector.

The flags above enable “path” support in “registrar” module and specify the mode of this support as well.

According to all above and if the path vector {p2,p1} is sent in the response, the UA can use the path (as preloaded Route set) in the future requests if that is allowed by the policy. In addition to this, any request reached the home proxy can be routed based on that path {p2,p1} which is stored in the database of the registrar.

According to RFC 3327:

The intermediate proxies (not terminating points) should not add a “Path” header field to a request unless the UA add the tag “path” as a value in the “Supported” header field in that request. Here we say the UA indicated support for PATH extension. If the UA indicated path support and the intermediate proxy requires path support in the registrar, then the proxy adds the tag “path” as a value in the “Requires” header field in that request. If the UA has not indicated support for path and the proxy requires support for it in the registrar, the proxy should reject the request with 421 response. This nearly corresponds to using the flag ‘p2’ in the “save” function: save(“location”,”p2″).

The “save(…)” function has also flag ‘v‘ (path received). If this flag is set, the “received” parameter of the first Path URI of a registration {p1} is set as received-uri and the NAT branch flag is set for this contact. This will be explained further down.

To use multiple flags in the “save(…)” function, mix them as one string. Example: save(“location”,”p2v”).

The routing script will have these lines, among others:


if (method == “REGISTER”) {

save(“location”, “p2v”);

Registrar’s Lookup Operation

When for example UA2 wants to call UA1 (Send Invite request). When the request reached OpenSIPS that operates as a registrar/home proxy, it looks up (Call the function lookup(..)) the AOR of UA1 (UA1@testdomain.com) and returns:

  • Contact = <sip:UA1@>

  • Path vector= <sip:P2.testdomain.com;lr>,<sip:P1.testdomain.com;lr>

The Request-URI is overwritten by the registered contact address and the Path vector {p2,p1} is inserted as Route set in the same order {p2,p1} in the outgoing Invite request. The topmost Route header field (proxy: p2) is used for routing decision (next hop) in conjunction with the local policy. Calling this function, also sets the destination URI to the first Path URI (outbound proxy: p1).

OpenSIPS As Outbound Proxy with NAT Detection

OpenSIPS has a module named “path” which is designed to be used at intermediate SIP proxies (e.g. outgoing proxy, load balancer,..etc.). Assume we have this scenario:

UA1 – – – NAT – – – P1 (Outbound Proxy -OpenSIPS) – – – P2 – – – Registrar/Home-Proxy

P1 is OpenSIPS that operates as outgoing proxy with NAT detection. To use “path” module, it must be configured in the routing script to be loaded at startup (loadmodule “path.so”). The module “rr” must be loaded before so it must be configured to be loaded before. To insert a path header into Register message, two functions are exported by this module:

  • The function “add_path(…)” which adds a path header in this form “Path: <sip:;lr>” .The IP address is the IP address of the proxy’s outgoing interface. A port is only added if it is not the default (5060). If it is called with username as parameter, then the username will be added to the URI “Path: <sip:username@;lr>“.
  • The function “add_path_received(…)” which adds a path header in this form:

Path: <sip:;received=sip:;lr>

In our scenario, the outbound proxy p1 will call the function “add_path_received” upon receiving a Register message. The received parameter of its Path URI contains the address where the request has been received (NAT’ed address). This is used to pass the NAT’ed address to the registrar through the next proxy if exists. If it is called with username then the username is added to the URI: “Path: <sip:username@;received=sip:;lr>“. Then the proxy will forward the message further to next hop on a way to the registrar.

If the parameter “use_received” exported from “path” module is set to 1 by the outgoing proxy (modparam(“path”, “use_received”, 1), then when the proxy receives a request, the “received” parameter of the its Route URI  (first Route URI ) is evaluated and used as destination URI(route the request to this address).

This behaviour of outbound proxy is considered as complement to registrar behaviour (SIP Path Extension-aware behaviour of Save(…) and Lookup(…)). So Keep the outbound proxy in the constructed path.

The routing script will have these lines, among others:

loadmodule “path.so”

modparam(“path”, “use_received”, 1)

if (method == “REGISTER”) {
if (!add_path_received(“Outbound”))
sl_send_reply(“503”, “Internal Path Error”);



  • SIP “Path” extension is very useful for SIP loadbalancers that are in front of registrars and proxies. As it helps in drawing SIP routing paths.
  • If you like to manipulate the “received” parameter of the Path URI by yourself in the script (not recommended), you can use the script core variables: $Ri which is the IP address of the interface where the request has been received and $Rp which is the port number. Informations like these are detected by the transport of OpenSIPS (under the SIP layer).
  • If you do not understand the structure of the SIP URI. Go Here.

 More Information

Homer as a SIP Capturing System – Part 1



homerHomer is a system designed to serve packet capturing purpose.The playing actors in this system are the capturing agent, the capturing server, and the web interface. The capturing agent is a daemon process (i.e. background process) which is running on the system of the routing node (SIP router). When a SIP message reaches the router, the capturing agent on this router takes a copy of this message, encapsulate it in HEP/IPIP packet (add an addition header to the message), and send it to the capturing server. The capturing agent will be configured with the address of the capturing server so it knows exactly where to send the packets. The capturing agent can be an external agent likeCaptagent“.

When the capturing server receives a packet, it decapsulates it (remove the added header), extracts,validate, and parses the SIP message and insert it in the database.The capturing server can also capture the SIP messages directly from the Ethernet (network monitoring connection). This is when a network switch send a copy of networks packets seen on one switch port to a network monitoring connection on another switch port.

The web interface which is connected to the database of the capturing server, loads the captured data  from the database and displays it  in a proper way. The figure below  shows how Homer system looks like:

OpenSIPS as a Homer Capturing Server

OpenSIPS can operate as a Homer capturing server. This is done with SipCapture module which is contributed to OpenSIPS in 2011. To achieve that, load and configure the SipCapture module in the routing script. In the routing script will be no routing for SIP messages but only capturing, processing and storing in the database. So another module must be loaded here which is the database module “db_mysql.so”.

Choosing OpenSIPS to operate as a capturing server is a good choice because of these:

  • Good core performance of OpenSIPS (e.g. Receive Message Handling, SIP Validator, SIP Parser).
  • By using OpenSIPS database interface, the capturing server will support many database servers (e.g. Mysql, Oracle,..).
  • Portability (Can be compiled on different systems).
  • Open source and free.

OpenSIPS as a SIP Router with Integrated Capturing Agent

Here OpenSIPS will operate as a SIP router with an integrated tracing capability (integrated capturing agent). To achieve this, the SipTrace module will be loaded to take a copy of each SIP message (or some of SIP messages) before routing it, encapsulate the message and send it to Homer capturing server. The address of Homer capturing server is configured as a parameter of SipTrace module.

modparam(“siptrace”, “duplicate_uri”, “sip:”) # The address to send a duplicate of traced message to it.

modparam(“siptrace”, “duplicate_with_hep”, 1)  # Enable HEP

modparam(“siptrace”, “trace_to_database”, 0) # Disable tracing to the local database

I will back to this later.

Note: OpenSIPS can not operate as capturing agent (siptrace module, HEP mode) and capturing server (sipcapture module) at the same time.

Homer Web Interface

The captured SIP messages are stored in the database and they should be displayed in proper way to the user who wants to analyse this data to be able to find any problem and solve it. This can be done through Homer multi-user web interface where you can see the messages displayed in table.You can search , filter, and sort the data. You can export the data as pcap files.  You can visualize the call flows. You can also get statistics. So the user login to the Homer web interface from anywhere and start working with SIP data.


The Next Part of this article will be about the compilation and installation of SipCapture Module, Setup of Homer Database, Installation of Homer Web interface.

More Information

DNS mapping of E.164 numbers to a list of URIs and IP Addresses


The Domain Name System (DNS) can be used to store the telephone numbers in E.164 format and identify the corresponding service. The domain “e164.arpa” is populated to make the DNS able to store the E.164 numbers. This domain is divided in subdomains so you should contact the corresponding zone administrator in order to list your E.164 number.

Explanation by Example

The DNS client string is “+441632910011” . It is a telephone number in E.164 format and we want to get the information about the service associated with this number (Service Type, Transport Protocol, Port number, IP Address). The DNS client which performs the look up operations, can be part of any kind of network servers .The corresponding domain name for that number will be “”. The figure below shows the steps to get the IP address of the server which provides the service and some information about the service. We will explain this below.

Step 1: Getting SIP URI as a Result of First DNS Look Up Operation

The DNS client performs the first DNS lookup on the domain name “”. The output are two NAPTR records:


NAPTR 10 100u” “E2U+sip” “!^.*$!sip:info@example.com!.             # Record Number 1

NAPTR 10 101 “u” “E2U+h323” “!^.*$!h323:info@example.com!” .       # Record Number 2

Here we have two records associated with that name. The fields in each record are: order, preference, flags, service, regular expression, and replacement.The “order” specifies the processing order of the NAPTR records. The “preference” specifies the processing order of the NAPTR records that have same order value. Here both records have an “order” value of 10 but the first one has the lowest “preference” value. So the DNS client will pickup the first record.

The “u” flag means that the output will be a URI. The service name in the selected record is “E2U+sip” and it means the record is used in Telephone Number-to-SIP URI queries.

The regular expression “!^.*$!sip:info@example.com!”  takes this form: “Delimit ERE Delimit Substitution Delimit Flag”.

Delimit = !

ERE (Extended Reqular Expression ) = ^.*$ which means everything from the beginning of the user string till the end.




and No flags.

The replacement field in the NAPTR record if not present must be indicated by dot (.). if the replacement field is present then the reqular expresion field should be an empty string (“”). The replacement field if present must be a FQDN. So when DNS Client pickup the first record, the result of the first step will be the SIP URI sip:info@example.comThe pattern provided in the regular expression filed is used. As we see here, we get SIP URI from E.164 telephone number. We can stop here if that is what we want.   Note: You can use “Dig” in linux terminal to perform a DNS  lookup: # dig -t naptr

Step 2: Getting the service’s FQDN (Include Service type + Transport Protocol)

Now the DNS client string is “sip:info@example.com” .The client performs a second  DNS lookup on the domain name “example.com. The output are two NAPTR records:

$ORIGIN example.com.
IN NAPTR 100 10 “S” “SIP+D2U” “!^.*$!sip:info@example.com!” _sip._udp.example.com.
IN NAPTR 102 10 “S” “SIP+D2T” “!^.*$!sip:info@example.com!” _sip._tcp.example.com.

Here the replacement field is present and the regular expression is also present (i.e. the regular expression should be empty but this is not mandatory). The flag “S” means the replacement field contains a FQDN which points to SRV record. The DNS client picks the first record because it has the lowest order value. The replacement is applied and the result will be ” _sip._udp.example.com“. The service is SIP  and the transport protocol is UDP.

Step 3: Getting Server’s FQDN and Listening Port Number

Now the DNS client string is “ _sip._udp.example.com“. The client performs the third look up on “_sip._udp.example.com and it gets the SRV records. This record takes this form  “_Service._Protocol.Name TTL Class SRV Priority Weight Port Target”

The record in this example:

 _sip._udp.example.com 86400 IN SRV 0 5 5060 sipserver.example.com

Service: The service name is sip,

Protocol: The transport protocol is UDP,

Name : The domain name is example.com,

TTL: Time to live is in seconds is 86400

Class: The  DNS class is IN

Priority: the priority of the Target is 0.

Weight: The relative weight of this record is 5.

Port: 5060,

Target: The hostname of machine which provides the service. sipserver.example.com

The result of this step is the FQDN “sipserver.example.com” which represents SIP server listening on port 5060.

Step 4: Getting the IP Address

The client prforms DNS look up on “sipserver.example.com . The output is A record which contains the IP Address.


Using Domain Name System (DNS) we can get the service information (Mainly the Service Type, Transport Protocol, Port number, and  IP Address) associated with a specific telephone number (E.164 number) .

More Information RFC 2916 , RFC 3761