 The project a bit, tell you something about the project goals, the project history and the current status. The second part of the talk will be a basic search overview where we will take a look at search features, we will take a look at what search can do, what search cannot do. We will describe the architecture a little bit. And in the last part, I will try to describe a typical SIP server setup based on SIR, where we will focus on scalability, on high availability and issues connected to such, connected to large setups mainly. So some notes about IPTEL.org, IPTEL.org is a non-profit organization originally initiated by FAAG Focus, which is a German research institute for open communication system. We started in 1999, the first outcome of IPTEL.org work was SIP tutorial by Johan Cislam and Yuri Gudhan. At this time, there was almost no documentation regarding SIP and related protocols, so this was a big success. We are also running a free available SIP service where anyone can take a SIP user agent and register to play with the SIP server and test it. Originally, we were running this SIP service based on third-party software, namely Cisco and Movida, but it turned out that it was not flexible enough, so we started to write our own hacks to make it work, and this is basically how SIR was born. We started working on SIR in 2001, and the result of this work is nowadays known as the SIP Express router. Later on, we also started to work on additional applications for management, the SIR web, which is the web interface for SIR. There is the RTP proxy, which is very often needed when dealing with SIP user agents behind nuts. There is SAMS, SIP Express media server, which is extension to SIR, and MySTAN. Last, later when the software was in a really usable state, FIG focus decided to create a SIP pin-off, which would sell commercial systems based on SIR. This is how YPTEL ERC company was born. That company was last year acquired by TechElect, and now is focusing on developing SIP infrastructure for 3GPP networks and for IMS. YPTEL ERC continues as a non-profit site, still sponsored by FAG Focus. The purpose of this site is to promote voice-over IP based on open standards, namely SIP, decision initiation protocol, development in the IETF and RTP. We also tried to promote the use of open source or free voice-over IP software. There is the free SIP service, which is often used by developers of SIP and devices to make sure that they are interoperable. We also maintained a documentation side with standards and internet drafts related to SIP. And as you probably already know, we have been developing a set of tools to implement open service solution for SIP-based setups for internet telephony service providers. A bit of history. First, server version was born in September 2001, originally as a hack to make Cisco PSDN gateways work. Two weeks later, we had a flexible configuration language, as it is still in SirNow. First modules were developed in early 2002. These modules were implemented mainly functionally needed to create SIP registrar, to create digest authentication, to implement record routing. In 2002, we were attending the first SIP-it event with Serenagon and PDA. Later on, SIP-Sack was created, which is often used for monitoring purposes. This is a command line tool for monitoring and for sending SIP messages. And in the end of 2002, there was the first major external contribution, which was support for Inam protocol. In 2003, Rafa Al-Qafid began working on SEMs. As of today, there are estimated tens of thousands of Ser installations worldwide. Some of them are biggest SIP installation today. Last year, the development group of SirForked, and there is now one server called OpenSR, which has the developers of OpenSR try to aim for short release cycles. So there are basically two projects, which do approximately the same. As I already said, Sir is being used by many developers of SIP and devices as a reference implementation and as a test implementation for their phone. So we receive a lot of questions regarding this. Sir is currently powering some of the largest SIP setups, those that are well-known are FWD, Free World Dialog by Pulver, SIPGate, and SIPfo, for example. Some of the biggest setups currently are known to handle about 80,000 subscribers on a single host, so there are such setups and we know it works. Sir is also part of SIP.edu initiative, which is a working group initiated by Internet 2. They are trying to promote voice-over IP to universities. There are several universities running really big setups, for example, Columbia University, University of California in Los Angeles, and so on. SIP.edu was also contributing to Sir. They developed a simple module implementing simple support, which is SIP extensions for presence and instant messaging. There are even some embedded setups. People are trying to run Sir in wireless routers or in DSR routers. One port is on Siemens Gigaset, another one there is a milkfish project, which is sort of embedded device running Sir inside. As most of you are probably familiar with it, there is some level of confusion about what is Sir and what is Sir not. So, Sir is a SIP access server, which means it can receive SIP messages, it can forward SIP messages, it can forward SIP replies. Sir can be configured as a registrar, which means it can receive register messages from SIP forms. SIP forms are using register messages to announce that they are online and that they are able to receive calls. It can be configured as a registrar server, as a redirect server, which means Sir will receive a request and redirect it to another host. It can be used as a simple, present server. In terms of the specification of SIP, Sir is transaction-safeful, which means it keeps state in memory for a short period of time during call creation and during call termination, but it doesn't keep any state in memory for the duration of the call. What is Sir not? Sir is not a back-to-back user agent. Back-to-back user agent is basically a connection of two user agents, one of them can receive a call, the other one will initiate a call, and then they will relay SIP messages. This kind of network entity has some useful features, but Sir cannot be configured as a back-to-back user agent. Sir is not dialogue stateful, that means Sir has no idea of calls in progress. Sir is not a PBX, it's not a packet branch exchange. It does not deal with media. It means no RTP streams go through Sir. Sir just deals with signaling, that means SIP messages. For RTP or for media streams, there are other applications which can be used in conjunction with Sir, and it's not a PSTN gateway. It has no support for PSTN gateway cards or PSTN interfaces. So, Sir itself is not enough to run a fully-featured SIP network. It can be used in the core, it can take care of all the SIP signaling, but you'll also need some additional applications if you like to implement things like PSTN interconnection, PBX functions and so on. Some features. Sir is written in C, and primarily it has been optimized for speed. At the time when we were trying, when we started working on Sir, most of the SIP applications were pretty big and slow. We decided to take a different approach and try to implement something which is really efficient and small. This approach has some drawbacks. Sir cannot be easily reused in other applications. There are no well-defined APIs except for internal APIs. There is no easy way of writing applications on top of Sir, but it's really fast. If you optimize your setup, it can really handle a lot of SIP traffic. It can even saturate a fast Ethernet interface. Sir is designed in a module way, and that means we try to keep a relatively small Sir core, which contains only functionality needed by most modules or functionality shared across several parts of Sir. There is a really flexible configuration language which is similar to C or Perl. This configuration language tells Sir how to route SIP requests, how to change them, how to send replies, and so on. When it comes to support for databases, there is support for MySQL, there is support for Postgres. We have an LDOP interface which can be used to query an external LDOP server for subscriber's profile. We have RAGEOS support which can be used for RAGEOS-based authentication and accounting. Sir is strictly 32.621-RFC-compliant and we try to make it as compliant as possible. We have a web-based administration interface written in PHP which can be used for administration purposes. There is an admin interface where you can control the domain supported by Sir. There you can control configuration options. There is also administration interface for users where user can see, for example, the list of missed calls, the list of received calls, they can change the settings and so on. Sir is not traversal capable. We have quite many extensions to make SIP user agents who are behind networks, so there are several functions which can help you to build such a setup. It's fairly portable. It runs on almost any POSIX compliant system. There have been reports from FreeBSD and BSD, OpenBSD and Mac, I think, from Darwin as well. Almost anything that is POSIX compliant can run, sir, but because there are some optimized operations written in assembler, sometimes some work is needed to probe it to new architectures. Sir is licensed under the terms of GPL. There are currently about 20 developers developing new features for the core and the core modules like Registrar and User Lock. FAAG Focus is trying to stay an exclusive copyright owner, but anyone can freely contribute to the project, write a new module, write a new extension, but changes to existing modules are subject to approval by corresponding maintainers. OpenServe, for example, has less strict rules, so people can modify even existing modules more easily. There is a very simple diagram that shows structure of sir. So there is the sir core which takes care of the transport layer, which also exposes the module interface to modules, and then there are several modules implementing, for example, digest authentication, access to databases, record routing, and so on. Features provided by sir core are only limited, so you can still run just sir core without any modules, but it will not be very useful. It contains, it can just simply forward a request and that's it. Most of the functions or functionalities that are needed are provided by modules. Each module can expose one or more script functions. Script functions can be then executed from the configuration language. Each module can provide a set of parameters which are used to control the behavior of the module, and there are also special variables. The special variables can be used to access various parts of a SIP message or can provide some additional information. For example, there is a TLS module which can expose a lot of information about the TLS level, TLS is transport layer security, and each of the modules can also provide management functions like reload of data stored in memory cache, changes to module parameters, and so on. In recent versions, we have pretty flexible management interface based on XML RPC, so that it's very easy to access all the functions, all the functions inside sir, for example, reloading some information from database is a matter of three lines of code in Python, so this is very easy. Here is a very short configuration file so that you can see how does it look like. The configuration file consists of four parts. The first one, now highlighted in red, are some generic settings for the server, things like debugging level, whether sir should fork and create additional processes or not, if debugging messages should be standard output or not. The second part is a set of load module commands which are used to load additional modules in the server. The modules are stored on local file system in the form of libraries. The next part is the configuration of modules. Each module can export a set of configuration parameters, they can be changed using modparam commands, and the most important one is the routing part. This is the part which describes the routing logic implemented in the server. The server without this configuration interface wouldn't know what to do with the SIP messages, it doesn't know how to change them, how to forward them. All this logic is described in this section, and when sir receives a SIP message, it starts executing this section and it will execute one command after another until it hits the end of the section or it hits break, and then it will stop. You can do pretty much everything from this section, you can change the content of the messages, you can change headers, you can send a reply, you can forward the request, you can maintain some internal state and so on. This configuration example shows only one route section but there are more types. So on this picture, this picture shows gives an overview of operation of sir. As I already said, sir is a very simple message forwarder. It can receive a SIP request, forward it, it can generate a reply, and this is all it can do. It doesn't know about existing calls or anything like that. So when sir receives a request in this example, it's invite for example, then it will start executing the route section described in the previous configuration file. So once an invite comes, the main route section will be executed and the commands listed in that route section can modify it, they can forward the request or generate a reply. Once one of the commands decides to forward the request, sir will execute another type of the route section which is called branch route. Because SIP has a feature called forking, that means if sir receives a single invite request, it can fork it to multiple destinations at the same time. But there might be functions that you would like to do on a particular branch only. This is exactly what branch route blocks are for. Branch route block is executed for every branch. In this picture, we have two of them. So just before sending the invite request, branch route block will be executed for the top branch. In the next step, when sir generates another invite request, it will execute the same branch route block again. So there is the main route block which is executed for incoming request and there can be branch route blocks which are executed for outgoing requests. Can try to turn it on a little bit. Is it better now? Yes. Okay. So there are two types of blocks for request and there are also two types of blocks for processing replies. When the downstream element generates a reply, in this example it's 486 and this reply hits sir. It will execute another type of route block which is called unreply route block. And in this block, sir can again do whatever it lies it can change the reply, it can change the status code, it can change the reason phrase, it can forward the reply. Unreplyed route blocks are executed again for each branch. So later when, for example, 200 okay arise from the other user agent, it will execute unreplyed route block again. Finally, the last routing block is fail route which is executed only if the reply forwarded upstream is a negative reply. That means 300 something, 400 something, 500 something. In this fail route block, sir can do things like serial for example, if it receives negative reply, then it can decide, okay, that user agent is not reachable, I can try to forward it to voicemail or to some other application. This is exactly the type of functionality which can be implemented in fail route blocks. Fail route blocks are executed only for negative replies. In this example, when 200 okay will be forwarded upstream, no fail route block will be executed. So this is all that sir does. It's a very simple application, very simple message for a vendor driven by a couple of routing blocks. No more complexity, no more, no notion of course or anything like this. Sir is transaction stateful in SIP requests and all responses associated with this that request are arranged in transactions. So transaction basically is a request and all the responses for that request. Sir is transaction stateful that means when it receives a request it will create a data structure in memory and that data structure will be released once the final reply in this example it will be 200 okay is forwarded upstream. The big advantage of this approach is that we don't have to keep any session state for the duration of the call which makes a really big performance difference and that's also the reason why sir can be so fast. So once we forward, once someone picks up the call and we forward the 200 okay, sir forgets everything. Later when one of the parties decides to hang up the call the user agent sends a bye and when sir receives the bye it will create the transaction contest again and again forget it after a short while. So there is no possibility to find out how many active calls are there in sir. There is no possibility to terminate a call in sir because sir is only transaction stateful. It's not dialogue stateful. Here is overview of a typical sir based setup. Sir itself is not enough to implement something like this. So there are some additional applications which are needed. One of them is sir web highlighted in green. That's the administration interface where users can administer their profile. The communication between sir web and sir is now based on XMLRPC. This setup has been designed for the most hostile environment which is the public internet. In the public internet we have absolutely no control over the network. We have no control over the devices that users will be using. We have no control over the net. So we have to assume that most of the phones are behind net that we cannot change the configuration of the phones and so on. So we try to change as little as possible in the user agent when something needs to be reconfigured it should be done on the server. To make phones behind network we also need a server called RTP proxy because there are situations where two user agents cannot talk directly to each other. There is no possibility to establish direct and communication. So for this purpose we need RTP proxy which will relay all the RTP traffic through a third party host usually located in the public internet. There is some communication between sir and between RTP proxy. This communication is implemented using a proprietary protocol which is very simple and text based. Just not documented anywhere. In this case sir needs to tell the RTP proxy there is a new call setup, reserve some parts, reserve some resources and make sure that you can relay media stream. At the end of the call it will again tell the RTP proxy okay the call is now finished. You can release all the resources. There can be also some additional applications like SAM or asterisk which can be used to implement additional functionality like voicemail, PSTN gateways and so on. And there is also the database server can be MySQL, Postgres or anything like that. Sir stores all the information about subscribers, their user names, passwords and so on in the database. This is a very simple setup where we have only one sir instance. This kind of setup can run, can serve about 60 to 80 thousand of subscribers. So if you have less than that then a single machine for sir, single machine for RTP proxy is enough. When there is a need to handle more subscribers then we need to scale it somehow. Which means we will need more sir boxes, we will need more RTP proxy boxes and split the traffic, the signaling traffic and the media traffic among those boxes. RTP proxy for example has a different requirement than the SIP server because in the worst case RTP proxy needs 64 kilobits per second of data traffic to relay a call. So it's very likely that you will first run out of network connectivity on the RTP proxy and it's not so likely that you will run into performance issues in the SIP server but it will eventually happen. So what we typically do in such situations is we set up multiple SIP server boxes, RTP proxy boxes and then we put a load balancer in front of them. The load balancer can again be implemented using sir. There is a special sir module called dispatcher. This module can implement hashing based on the content of from or request URI header field. So it knows the home proxy of every subscriber provisioning application and like sir web can implement the same algorithm to find the corresponding proxy directly or they can run all the traffic through load balancer as well because for example sir web is not based on XMLRPC which is very similar to SIP. In fact, XMLRPC is using HTTP so we can run it through the load balancer as well. There is no difference for sir between HTTP or between SIP. One difficult issue is high availability. Operators of PSTN networks often claim that they can reach five nines availability so internet telephony service providers are forced to implement the same and claim that they can reach five nines as well. However in the public internet this is not really easy especially because of not perfect implementations that are available. Most of the SIP phones which are on the market right now cannot handle DNS SRV failure for example. They cannot, they will not try to reach another server when the master server fails and you couldn't really rely on such advanced feature in SIP user agents so we need to take care of this on the server because nowadays most of the SIP phones are behind a net. There is only one server which can reach the phones and that is the server to which the SIP phones send a register request. If you have a SIP user agent behind a net, you can only communicate with the server to which you initiate the communications which is typically the registrar or the proxy server. No other server can reach the phone because the net would drop the packet. For this reason if we want to implement high availability and if we would like to have a backup server we need to migrate the IP address. So we need to have two servers, both of them configured using the same IP address and they are using VRRP. VRRP stands for virtual redundant router protocol. It's a sort of it's a hard beat protocol where the master server in the group sends hard beat packets to all the servers in the group and when one of the backup servers stops receiving the hard beat packets or for some reason they lose communication it will send an ARP response to switch and take over the IP address and continue the processing. So switch over from master to backup in this situation takes approximately four seconds so there is a first second delay where the user agents will be unreachable. When it comes to RTP proxy high availability there is the possibility to use exactly the same scenario as here in this case the RTP proxy would need to share, would need to communicate the information about the user agents but we typically do not implement this because if one of the service fail existing calls will be gone but the user agents can try to make a new call. One more thing here the two circumstances and the two databases on the pictures are separated. There is no central database in the background. We also typically replicate all SIP register messages to the backup instance and this way the master and the backup SIP server instance can stay synchronized. When the master instance fails the backup server instance will immediately have exactly the same data as the master and can start taking over the load immediately. Here is a picture showing what happens when the master instance backup server will send an RTP response which will make the switch on the picture to update the RTP table and all the future SIP traffic will be sent to the backup instance. The transaction is lost. This is not a really big issue because if transaction is lost then SIR can still relay the SIP messages statelessly. Some things will not be working for example accounting will not be working, not triggers will not be working as well but for example for by request when you try to when you hang up a user agent and send the user agent will send a by request such request would make it to the other party even if it is forwarded statelessly. So there is a short window at the beginning of each call which is sensitive to server failures but during the call there are no problems. The server can fail, there is no communication besides RTP between the user agents so it will still work. So this the pictures that I showed here this is how for example the public SIP service which we run on niptal.org is operating. It has been designed for the public internet where we have no control over the network and over the user agent. Everything else is simpler if you have an internet telephone service provider company and you know what kind of user agents your user are using then it can be done easier. You don't need VRP for example if you have only user agents that support SRI failure. There is no need to have a central backend database although it can be done now. We have tested this recent MySQL cluster installations it seems to work reasonably well and it seems to scale well. This kind of infrastructure can handle millions of subscribers that means you can scale it to millions of phones simply by adding boxes. Load balancing is based on server side because load balancing is done by the load balancer. There is no need to change the configuration of the user agent if you need to migrate a user agent from one server to another and it doesn't require any proprietary extensions and a 3261 compliant user agent would work or should work. If you have any questions go ahead. VRP is a separate package. There is free implementation of VRP daemon. Super application is implemented in SER. There is a special command which you can use to forward all the traffic from a master server to backup. What do you mean by call account? Right. Right. So the question was if there is any possibility to use RTP perks to answer for accounting purposes. Well, to some extent yes. There is an alternative RTP proxy called media proxy which can display a list of existing calls could be used for accounting but this is not reliable. So it wouldn't work reliable. If you use this information for billing purposes then probably the only place where you can generate reliable billing data would be the PST and gateway. There are situations where it can happen that you do not receive a buy for example then you wouldn't know what was the duration of the call so it's not using it. So accounting in radios, so for each call the server would generate two records. It would generate the start record at the beginning of the call and then it would generate the stop record. So you have two records and you have to correlate them. They can be correlated using the value of call ID from tech and to tech. All this information is sent to the radio server by server. So you can then in the processing application use this to correlate start and stop requests. Yes. You need a dialogue stateful element for this because to be able to generate a buy on the server side which is what you need to terminate the call you need the value of several header fields. You need the call ID value you need from header to header and you have to make sure that you form the request properly otherwise the user agent would refuse it. So unless you can extract this information, store it somewhere and use this when generating buy then no. You would need to implement a back to back user agent which or dialogue stateful element to make this possible. Non-helper? Yes. It's sufficiently reliable for any it was working finding any setup I have seen. In fact we have issues in deploying session border controllers because they introduce additional latency. They often screw up signaling. So non-helper and RTP proxy implemented on the server can do the same. It's just a different place where you can do it. If you deploy non-helper and RTP proxy you implement non-travels on the server. If you install a session border controller then you can do it in the customer network on user agent premises but it works fine. In fact we are not recommending people to use session border controllers because of problems we had in the past. Yes. There is a commercial licensing program done by the commercial spin-off.