Building Telephony Systems with OpenSIPS 1.6

By Flavio E. Goncalves
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to SIP

About this book

SIP is the most important VoIP protocol and OpenSIPS is clearly the open source leader in VoIP platforms based on pure SIP. The whole telecommunication industry is changing to an IP environment, and telephony in the way we know today will disappear in less than ten years. SIP is the protocol leading this disruptive revolution and it is one of the main protocols on next-generation networks. While a VoIP provider is not the only kind of SIP infrastructure created using OpenSIPS, it is certainly one of the most difficult to implement.

This book will give you a competitive edge by helping you to create a SIP infrastructure capable of handling tens of thousands of subscribers. You can extend the examples given in this book easily to other applications such as a SIP router, load balancing, IP PBX, and Hosted PBX as well. This book is an update of the title Building Telephony Systems with OpenSER.

The book starts with the simplest configuration and evolves chapter by chapter teaching you how to add new features and modules. It will first teach you the basic concepts of SIP and SIP routing. Then, you will start applying the theory by installing OpenSIPS and creating the configuration file. You will learn about features such as authentication, PSTN connectivity, user portals, media server integration, billing, NAT traversal, and monitoring. The book uses a fictional VoIP provider to explain OpenSIPS. The idea is to have a simple but complete running VoIP provider by the end of the book. 

Publication date:
January 2010
Publisher
Packt
Pages
284
ISBN
9781849510745

 

Chapter 1. Introduction to SIP

The Session Initiation Protocol (SIP) was standardized by the Internet Engineering Task Force (IETF) and is described in several documents known as Request for Comment (RFC). RFC3261 is one of the most recent of the documents, and is called SIP version 2. SIP is an application layer protocol used to establish, modify, and terminate sessions or multimedia calls. These sessions can be audio and video sessions, e-learning, chatting, or screen-sharing sessions. It is based on a text protocol similar to Hypertext Transfer Protocol (HTTP) and is designed to start, keep, and close interactive communication sessions between users. These days, SIP is one of the most used protocols for VoIP and is present on almost every IP phone in the market.

By the end of this chapter, you will be able to:

  • Describe what SIP is

  • Describe what SIP is for

  • Describe the SIP architecture

  • Explain the meaning of its main components

  • Understand and compare the main SIP messages

  • Describe the header fields processing for INVITE and REGISTER requests

The SIP protocol supports the following five features for establishing and closing multimedia sessions:

  1. User location: Determines the endpoint address used for communication.

  2. User parameters negotiation: Determines the media and parameters to be used.

  3. User availability: Determines if the user is available to establish a session.

  4. Call establishment: Establishes the parameters for both the caller and callee, and informs both parties about the call progress (ringing, ringback, congestion).

  5. Call management: Session transfer and closing.

The SIP protocol was designed as part of a multimedia architecture containing other protocols such as RVSP, RTP, RTSP, SDP, and SAP. However, it does not depend on them for its operation.

 

SIP basics


SIP is very similar to HTTP in the way it works. The SIP address is just like an e-mail address. An interesting feature used in SIP proxies is alias, which enables you to have multiple SIP addresses such as:

In the SIP architecture, we have user agents and servers. SIP uses a peer-to-peer distributed model with a signaling server. The server handles just the signaling, while the user agent clients and the user agent servers handle signaling and media. This is depicted in the next image:

In the SIP model, a user agent—usually a SIP phone—will start communicating with its SIP proxy—seen here as the outgoing proxy (or its home proxy)—to send the call using a message known as INVITE.

The outgoing proxy will see that the call is directed to an outside domain. It will seek the DNS server for the address of the target domain and resolve the IP address. Then, the outgoing proxy will forward the call to the SIP proxy responsible for the DomainB.

The incoming proxy will verify, on its location table for the IP address of the agentB, if this address was inserted in the location table by a previous registration process. If the incoming proxy can locate the address, it will forward the call to the agentB.

After receiving the SIP message, the agentB will have all the information required to establish a RTP session (usually audio) with the agentA. Using a message such as BYE will terminate the session.

An example of a SIP message is shown in the next image:

Usually, VoIP providers don't implement a pure SIP trapezoid. They don't allow you to send calls to outside domains because this affects the revenue stream. They implement something that is closer to a SIP triangle.

 

SIP operation theory


You can see the main components of the SIP architecture in the following image:

The entire SIP signaling flows through the SIP proxy server. On the other hand, the media signaling, transported by the RTP protocol, flows directly from one endpoint to another. Some of the components will be briefly explained in the following sequence:

  1. UAC (User Agent Client): The client or terminal that starts the SIP signaling

  2. UAS (User Agent Server): The server that responds to the SIP signaling coming from an UAC

  3. UA (User Agent): The SIP terminal (IP phones, ATAs, softphones, and so on)

  4. Proxy server: Receives requests from a UA and transfers to another SIP proxy if this specific terminal is not under its domain

  5. Redirect server: Receives requests and responds to the caller with a message containing data about the destination ("302", Moved Temporarily")

  6. Location server: Provides the callee's contact addresses to proxy and redirect servers

OpenSIPS can be configured to provide proxy, redirect, and location services on a single platform.

 

SIP registering process


The following image depicts the SIP registering process:

The SIP protocol employs a component called registrar. It is a server which accepts REGISTER requests and saves the information received within these packets on the location server for their managed domains. The SIP protocol has a discovery capacity. In other words, if a user starts a session with another user, the SIP protocol has to discover an existing host where the user can be reached. The discovery process is done by a location server that receives the request and finds the target destination. This is stored in a location database maintained by the Location server per domain. The register server may accept other types of information, not only the client's IP addresses. It can receive other information such as Call Processing Language (CPL) scripts on the server.

Before a telephone can receive calls, it needs to be registered with the location database. In this database, we will have all of the phones associated with their respective IP addresses. In our example, you will see the SIP user [email protected] registered in the IP address 200.180.1.1.

RFC3665 defines best practices to implement a minimum set of functionality for a SIP IP communications network.

According to the RFC3665, there are five basic flows associated with the process of registering a user agent. They are as follows:

Diagram

Description

A successful New registration: After sending the REGISTER request, the User Agent will be challenged against its credentials. We will see this in detail in Chapter 5, Adding Authentication with MySQL, which is dedicated to authentication.

Update of Contact list: As it is not a new registration, the message already contains the digest and a "401" message won't be sent. To change the contact list, the User Agent just needs to send a new register message with the new contact in the CONTACT header field.

Request for current Contact list: In this case, the User Agent will send the CONTACT header field empty, indicating that the user wishes to query the server for the current contact list. In the 200 OK message, the SIP server will send the current contact list in the CONTACT header field.

Cancellation of the registration: The User Agent now sends the message with an EXPIRES header field of 0 and a CONTACT header field configured as '*' to apply to all the existing contacts.

Unsuccessful Registration: The UAC sends a REGISTER request and receives a 401 Unauthorized message in exactly the same way as successful registration. In the sequence, it produces a hash and tries to authenticate. The server, detecting an invalid password, sends a 401 Unauthorized message again. The process will be repeated for the number of retries configured in the UAC.

 

Server operating as a SIP proxy


In SIP proxy mode, all SIP signaling goes through the SIP proxy. This behavior will help in processes such as billing and is, by far, the most common choice. The drawback is the overhead caused by the server in the middle of all SIP communications during the session's establishment. Remember, RTP packets will always go directly from one endpoint to another, even if the server is working as a SIP proxy. This is shown in the following screenshot:

 

Server operating as a SIP redirect


The SIP proxy can operate in SIP redirect mode. In this mode, the SIP server is very scalable because it doesn't keep the state of transactions. Just after the initial INVITE, it replies to the UAC with a "302 moved temporarily" message and is removed from the SIP dialog. In this mode, a SIP proxy—even with very few resources—can forward millions of calls per hour. It is normally used when you need high scalability, but don't need to bill the calls.

 

Basic messages


The basic messages sent in a SIP environment are:

Message

Description

RFC

ACK

Acknowledge an INVITE

RFC3261

BYE

Terminate an existing session

RFC3261

CANCEL

Cancel a pending registration

RFC3261

INFO

Mid-call signaling information

RFC2976

INVITE

Session establishment

RFC3261

MESSAGE

Instant message transport

RFC3428

NOTIFY

Send information after subscribe

RFC3265

PRACK

Acknowledge a provisional response

RFC3262

PUBLISH

Upload status information to the server

RFC3903

REFER

Ask another UA to act upon URI

RFC3515

REGISTER

Register the user and update the location table

RFC3261

SUBSCRIBE

Establish a session to receive future updates

RFC3265

UPDATE

Update a session's state information

RFC3311

Most of the time, you will use REGISTER, INVITE, BYE, and CANCEL. Some messages are used for other features. As an example, INFO is used for DTMF relay and mid-call signaling information. PUBLISH, NOTIFY, and SUBSCRIBE give support to presence systems. REFER is used for call transfer and MESSAGE for chat applications. Newer messages can appear depending on the protocol standardization process. Responses to these messages are in text format, as in the HTTP protocol. Some of the most important responses are shown in the following image:

 

SIP dialog flow


This section introduces some basic SIP operations using a simple example. Let's examine this message sequence between two user agents in the next image. You can see several other flows associated with session establishment in the RFC3665.

The messages are labeled in sequence. In this example, userA uses an IP phone to call another IP phone over the network. To complete the call, two SIP proxies are used.

userA calls userB using its SIP identity, called the SIP URI. The URI is similar to an e-mail address such as sip:[email protected]. A secure SIP URI can be used too, such as sips:[email protected]. A call made using sips: (secure SIP) will use a secure transport (TLS-Transport Layer Security) between the caller and the callee.

The transaction starts with userA sending an INVITE request addressed to userB. The INVITE request contains a certain number of header fields. Header fields are named attributes that provide additional information about the message. They include a unique identifier, the destination, and information about the session as shown here:

The first line of the message contains the method name. The following lines contain a list of header fields. This example contains the minimum set required. We will briefly describe these header fields as follows:

  • VIA: This header field contains the address which will be used to send the responses back for this request. It also contains a parameter called branch that identifies this transaction. The Via header defines the last SIP hop as IP, transport, and transaction-specific parameters. Via is used exclusively for routing back the replies. Each proxy adds an additional Via header. It is a lot easier for replies to find their route back using the Via header than to refer back to the location server or DNS.

  • TO: This contains the name (display name) and the SIP URI (sip:[email protected]) to the destination originally selected. The TO header field is not used to route the packets.

  • FROM: This contains the name and SIP URI (sip:[email protected]) that indicates the caller ID. This header field has a tag parameter containing a random string that was added to the URI by the IP phone. It is used for purposes of identification. The tag parameter is used in the TO and FROM fields. It serves as a general mechanism to identify the dialog, which is a combination of the Call-ID along with the two tags—one from each participant in the dialog. Tags can be useful in parallel forking.

  • CALL-ID: This contains a globally unique identifier for this call generated by the combination of a random string and the hostname or IP address from the IP phone. A combination of the TO, FROM, and CALL-ID tags fully defines an end-to-end SIP relation known as a SIP dialog.

  • CSEQ: The CSEQ or command sequence contains an integer and a method name. The CSEQ number is incremented with each new request inside a SIP dialog and is a traditional sequence number.

  • CONTACT: This contains a SIP URI, which represents a direct route to contact userA, usually composed by a username and a FQDN (fully qualified domain name). Sometimes, the domains are not registered and thus IP addresses are permitted too. While the VIA header field tells the other elements where to send a response, the CONTACT field tells the other elements where to send future requests.

  • MAX-FORWARDS: This is used to limit the number of allowed hops a request can make in the path to its final destination. It consists of an integer which is decremented by one each hop.

  • CONTENT-TYPE: This contains a body message description.

  • CONTENT-LENGTH: This contains a byte count of the body message.

Session details, such as the media type and codec, are not described using SIP. Instead, SIP uses a session description protocol called SDP (RFC2327). This SDP message is carried by the SIP message, similar to an e-mail attachment.

The phone does not know the location of userB or the server responsible for domainB. Thus, it sends the INVITE request to the server responsible for the domain sipA. This address is configured in the phone of userA or can be discovered by DHCP. The server sipA.com is also known as the SIP proxy for the domain sipA.com. The sequence is as follows:

  1. In this example, the proxy receives the INVITE request and sends a message "100 trying" back to userA, signaling that the proxy receives the INVITE and is working to forward the request. The SIP responses use a three-digit code followed by a descriptive phrase. This response contains the same TO, FROM, CALL-ID, and CSEQ header fields and a parameter "branch" in the Via header field such as the INVITE request. This allows userA's phone to correlate to the INVITE request sent.

  2. ProxyA locates proxyB consulting a DNS server (SRV records) to find out what server is responsible for the SIP domain sipB and forwards the INVITE request. Before sending the request to proxyA, it adds a VIA header field that contains their own address. The INVITE request already had the address of userA in the first VIA header field.

  3. ProxyB receives the INVITE request and responds with a "100 Trying" message back to the proxyA indicating that it is processing the request.

  4. ProxyB consults their own location database for userB's address, and then adds another VIA header field with their own address to the INVITE request and forwards it to userB's IP address.

  5. userB's phone receives the INVITE request and starts ringing. The phone indicates back this condition by sending a message of "180 Ringing".

  6. This message is routed back through both proxies in the reverse direction. Each proxy uses the VIA header field to determine where to send the response and removes their own VIA header from the top. As a result, the message "180 Ringing" can return back to the user without any lookups to DNS or Location Service and without the need for stateful processing. Thus, each proxy sees all messages resulting from the INVITE request.

  7. When userA's phone receives the "180 ringing" message, it starts to ring back, signaling the user that the call is ringing on the other side. Some phones show this in the display.

    In this example, userB decides to attend the call. When he or she picks up the handset, the phone sends a response of "200 Ok" to indicate that the call was taken. The "200 Ok" message contains a session description in its body, specifying codecs, ports, and everything pertaining to the session. It uses the SDP protocol for this duty. As a result, an exchange occurs in two phases of messages from A to B (INVITE) and B to A (200 OK), negotiating the resources and capabilities used on the call in a simple "offer/response" model. If userB does not want to receive the call or is busy, the message "200 Ok" won't be sent and a message signaling the condition (that is, "487 busy here") will be sent instead.

The first line contains the response code and description (OK). The following lines contain the header fields. The VIA, TO, FROM, CALL-ID, and CSEQ fields are copied from the INVITE request. There are three Via fields—one added by userA, another by the proxyA, and finally by the proxyB. The SIP phone of userB added a parameter tag on both endpoints inside the dialog and will be included in all future requests and responses for this call.

The CONTACT header field contains the URI with which userB can be contacted directly in their own IP phone.

The CONTENT-TYPE and CONTENT-LENGTH header fields give some information about the SDP header ahead. The SDP header contains media-related parameters used to establish the RTP session.

  1. In this case, the message "200 Ok" is sent back through both proxies and is received by userA, and then the phone stops ringing back indicating that the call was accepted.

  2. Finally, userA sends an ACK message to userB's phone confirming the reception of the "200 Ok" message. In this example, the ACK is sent directly from phoneA to phoneB, avoiding both proxies. ACK is the only SIP method which has no reply. The endpoints learned each other's addresses from the CONTACT header fields during the INVITE process. This ends the INVITE/200 OK/ACK cycle, also known as the SIP three-way handshake.

  3. At this moment, the session between both users starts and they send media packets to each other using a mutually agreed format established by the SDP protocol. Usually, these packets are end-to-end. During the session, the parties can change the session's characteristics by issuing a new INVITE request. This is called a re-invite. If the re-invite is not acceptable, a message "488 Not Acceptable Here" will be sent, but the session will not fail.

  4. At the session's end, userB disconnects the phone and generates a BYE message. This message is routed directly to userA's softphone, bypassing both proxies.

  5. userA confirms the reception of the BYE message with a "200 OK" message ending the session. No ACK is sent. An ACK is sent only for INVITE requests.

In some cases, it can be important for proxies to stay in the middle of the signaling to see all messages between endpoints during the whole session. If the proxy wants to stay in the path after the initial INVITE request, it has to add the RECORD-ROUTE header field to the request. This information will be received by userB's phone and it will send back the message through the proxies with the RECORD-ROUTE header field included too. Record routing is used in most scenarios.

The REGISTER request is the way that proxyB learns the location of userB. When the phone initializes, or at regular time intervals, the softphone B sends a REGISTER request to a server on domain sipB known as "SIP REGISTRAR". The REGISTER messages associate a URI ([email protected]) to an IP address. This binding is stored in a database in the Location server. Usually, the Registrar, Location, and proxy servers are in the same computer and use the same software. OpenSIPS is capable of playing all three roles. A URI can only be registered by a single device at a time.

 

SIP transactions and dialogs


It is important to understand the difference between a transaction and a dialog. A transaction occurs between a user agent client and a user agent server, and comprises all messages from the initial request to the final response (including all interim responses). The responses can be provisional, starting with 1 followed by two digits (for example, "180 Ringing") or final starting with 2 followed by two digits (for example, "200 Ok"). The scope of a transaction is defined by the stack of the Via headers of the SIP messages. So, after the initial invite, the user agents don't need to rely on DNS or location tables to route the messages.

According to RFC3261:

A dialog represents a peer-to-peer SIP relationship between two user agents, which persists for some time. A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag, and a remote tag.

A dialog is a succession of transactions which control the creation, existence, and termination of the dialog. All dialogs have a transaction to create them and may or may not have a transaction to change them (mid-transaction). Also, the end dialog transaction may be missing (some dialogs end based on timeouts rather than by explicit termination).

According to RFC 3665, there are 11 basic session establishment flows. The list is not meant to be complete, but covers the best practices. The first two, "Successful Session Establishment" and "Session Establishment Through Two Proxies", are already covered in this chapter. Some of the others will be seen in the chapter dedicated to call forwarding such as "Unsuccessful with no Answer" and "Unsuccessful Busy".

 

The RTP protocol


The Real Time Protocol (RTP) is responsible for the real-time transport of data such as audio and video. It was standardized on RFC 3550. It uses UDP as the transport protocol. To be transported, the audio or video has to be packetized by a codec. Basically, the protocol allows the specification of timing and content requirements of the media transmission for the incoming and outgoing packets using:

  • Sequence number

  • Timestamps

  • Packet forward without retransmission

  • Source identification

  • Content identification

  • Synchronism

The RTP has a companion protocol called Real Time Control Protocol (RTCP) used to monitor the RTP packets. It can measure the delay and jitter.

Codecs

The content described in the RTP protocol is usually encoded by a codec. Each codec has a specific use. Some have compression, while others don't. G.711 is the most popular codec and it does not use compression. With 64Kbps of bandwidth for a single channel, it needs a high-speed network, commonly found in Local Area Networks (LANs). However, in Wide Area Networks (WANs), 64 Kbps can be too expensive to buy for a single channel. Codecs such as G.729 and GSM can compress the voice packets to as low as 8 Kbps, saving a lot of bandwidth. Some codecs such as the iLBC from Global IP sound can conceal packet loss. The iLBC can sustain a good voice quality even with 7% packet loss. So, you have to choose the codecs you will support in your VoIP provider wisely.

DTMF relay

In some cases, the RTP protocol is used to carry signaling information such as DTMF. The RFC2833 describes a method to transmit DTMF as named events in the RTP protocol. It is very important that you use the same method between user agent servers and user agent clients.

Real Time Control Protocol (RTCP)

RTCP can provide feedback on the quality of reception. It provides out-of-band control information for a RTP media flow. Statistics such as jitter, round trip time (RTT), latency, and packet loss can be gathered using RTCP. RTCP is usually used for voice quality reporting.

 

Session Description Protocol (SDP)


The SDP protocol is described in the RFC4566. It is used to negotiate session parameters between the user agents. Media details, transport addresses, and other media-related information are exchanged between the user agents using the SDP protocol. Normally, the INVITE message contains the SDP offer message, while "200 Ok" contains the answer message. These messages are shown in the next screenshot. You can observe that the GSM codec is offered, but the other phone does not support it. Then it answers with the supported codecs; in this case, G.711 ulaw (PCMU) and G.729. The session rtpmap:101 is the DTMF relay described in the RFC2833.

Here is the INVITE (SDP offer) message:

The following screenshot shows the "200 Ok" (SDP answer) reply:

 

The SIP protocol and the OSI model


It is always important to understand the voice protocols against the OSI model to situate where each protocol fits.

 

VoIP provider, the big picture


Before we start digging into the SIP proxy, it is important to understand all the components for a VoIP provider solution. They are shown in the following image:

A VoIP provider usually consists of several servers and services. The services described here could be installed in a single server or multiple servers depending on the dimensioning.

In this book, we will cover each one of these components from left to right in the chapters ahead. We are going to use this picture in all the chapters to help you realize where you are.

SIP proxy

The SIP proxy is the central component of our solution. It is responsible for registering the users and keeping the location database (maps IP to SIP addresses). The entire SIP routing and signaling is handled by the SIP proxy, and it is also responsible for end-user services such as call forwarding, white/blacklist, speed dialing, and others. This component never handles the media (RTP packets); all media-related packets are routed directly from the user agent clients, servers, and PSTN gateways.

User administration and provisioning portal

One important component is the user administration and provisioning portal. In the portal, the user may subscribe to the service and should also be capable of buying credits, changing passwords, and verifying his or her account. On the other hand, administrators should be able to remove users, change user credits, and grant and remove privileges. Provisioning is the process used to make it easier for administrators to provide automatic installation of user agents such as IP phones, analog telephony adapters, and soft-phones.

PSTN gateway

To communicate with the public switched telephone network, a PSTN gateway is required. Usually, this gateway will interface the PSTN using E1 or T1 trunks. The most common products in this arena are gateways from CiscoTM, AudioCodesTM, and QuintumTM. Asterisk is gaining market in this area because of their price per port cost, which is sometimes 75% less than the competitors. To evaluate a good gateway, check the support of SIP extensions such as RFC3515 (Refer), RFC3891 (Replaces), and RFC 3892(Referred-By). These protocols will allow unattended transfers behind the SIP proxy; without them in the gateway, it might be impossible to transfer calls.

Media server

The SIP proxy never handles the media. Services such as IVRs, voicemail, conference, or anything related to media should be implemented in a media server. SIP Express Media Server (SEMS) developed by iptel has some nice features such as conference, voicemail, and announcements. Once again, Asterisk can be used as a wildcard to provide these services.

Media Proxy or RTP Proxy for Nat traversal

Any SIP provider will have to handle NAT traversal for their customers. The Media Proxy is an RTP bridge that helps the users behind symmetric firewalls to access the SIP provider. Without them, it won't be possible to service a large share of the user base. You can implement a universal NAT traversal technique using these components. The Media Proxy can also help you in the accounting correction for unfinished SIP dialogs which, for some reason, didn't receive the BYE message.

Accounting and CDR generation

An AAA (Authentication, Authorization and Accounting) server can be used along with OpenSIPS. Freeradius is a common choice. In several implementations, you can skip radius and use SQL accounting. Some VoIP providers will leverage an existing AAA server, while some others will prefer the low-overhead MySQL accounting. SerMyAdmin can now be used for accounting purposes. The CDR generation is beyond accounting, where the duration of the calls is calculated.

Monitoring tools

Finally, we will need monitoring, troubleshooting, and testing tools to help debug any problems occurring in the SIP server. The first tool is the protocol analyzer and we will see how to use ngrep, ethereal, and tethereal. The OpenSIPS has a module called SIPTRACE. We will use that too.

 

Where you can find more information


The best reference for the SIP protocol is RFC3261. Reading the RFCs is a little bit boring and sleep inducing (It is very good when you have insomnia.). You can find the RFC at http://www.ietf.org/rfc/rfc3261.txt.

A good SIP tutorial can be found at Columbia University: http://www.cs.columbia.edu/~coms6181/slides/11/sip_long.pdf. Together, you can find a lot of information about SIP at http://www.cs.columbia.edu/sip/.

A very good tutorial can be found at the iptel website: http://www.iptel.org/files/sip_tutorial.pdf.

There is a mailing list where you can post questions about SIP, called SIP implementers: https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

 

Summary


In this chapter, you have learnt what the SIP protocol and its functionality is. You had the opportunity to learn about the SIP components such as the SIP proxy, SIP REGISTRAR, user agent client, user agent server, and PSTN gateway. You saw the SIP architecture, and its main messages and processes. You can explore some sources to find further information listed too.

About the Author

  • Flavio E. Goncalves

    Flavio E. Goncalves was born in 1966 in Brazil. Having a strong interest in computers, he got his first personal computer in 1983, and since then, it has been almost an addiction. He received his degree in engineering in 1989 with a focus on computer-aided designing and manufacturing.

    He is also the CTO of SipPulse Routing and Billing Solutions in Brazil—a company dedicated to the implementing of small-to-medium telephone companies, VoIP providers, and large-scale new generation telephony systems. Since 1993, he has participated in a series of certification programs and been certificated as Novell MCNE/MCNI, Microsoft MCSE/MCT, Cisco CCSP/CCNP/CCDP, Asterisk dCAP, and some others.

    He started writing about open source software because he thinks that the way certification programs have worked is very good for learners. Some books are written by strictly technical people who sometimes do not have a clear idea on how people learn. He tried to use his 15 years of experience as an instructor to help people learn about the open source telephony software. Together with Bogdan, he created the OpenSIPS boot camp followed by the e-learning program, OpenSIPS eBootcamp.

    His experience with networks, protocol analyzers, and IP telephony combined with his teaching experience gave him an edge to write this book. This is the fourth book written by him. The first one was Configuration Guide for Asterisk PBX, by BookSurge Publishing, the second was Building Telephony Systems with OpenSER, by Packt Publishing, and the third was Building Telepopny Systems With OpenSIPS 1.6, by Packt Publishing.

    As the CTO of SipPulse, Flavio balances his time between family, work, and fun. He is the father of two children and lives in Florianopolis, Brazil—one of the most beautiful places in the world. He dedicates his free time to water sports such as surfing and sailing.

    Browse publications by this author