A PROJECT REPORT

ON

Development Of VoIP Platform For Embedded System

Submitted in partial fulfillment of the requirements for the award

of the degree of

MASTER OF TECHNOLOGY
in
SOFWARE ENGINEERING
By

SURESH KUMAR N

Under the Esteemed Guidance of

Mr. Kiran Nair Chandrasekhar Mr.G.Santhosh Kumar

Technical Lead Lecturer
Honeywell Technology Solutions Dept. of Computer Science
Bangalore CUSAT

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITY OF SCIENCE &TECHNOLOGY
KOCHI–682022
JUNE 2008
 CERTIFICATE

This is to certify that the thesis entitled “Development of VOIP Platform For
Embedded Systems” is a bonafide record of the work done by Mr. Suresh Kumar N
at Honeywell Technology Solutions Lab, Bangalore. This thesis is being submitted
to the Department Of Computer Science, (CUSAT), Cochin towards partial
fulfillment of the requirements for the award of the degree of MASTER OF
TECHNOLOLGY in SOFTWARE ENGINEERING.

Date: 05/05/08 Signature of Project Supervisor

Place: Honeywell TSL, Bangalore Name: Kiran Nair
Designation: Tech lead
 DEPARTMENT OF COMPUTER SCIENCE COCHIN
UNIVERSITY OF SCIENCE TECHNOLOGY,
KOCHI-682022

CERTIFICAE

Certified that project work entitled “Development Of VoIP

Platform for embedded Systems” is a bonafide work carried out by
Suresh Kumar N at Honeywell Technology Solutions Lab, Bangalore
in partial fulfillment for the award of master of technology in
Software Engineering from Cochin University of Science
&Technology during the academic year 2006-2007

Dr.K.Poulose Jacob G.Santhoshkumar

Professor & Internal Project Guide
Head Of The Department Lecturer
Dept.of Computer Science Dept.of Computer Science
CUSAT CUSAT
 ACKNOWLEDGEMENT

I am greatly indebted to Mr.Kiran Nair, Tech Lead, Honeywell Technology

Solution Lab for his technical support, constant encouragement, consistent guidance and
inspiration throughout the course of this investigation.

I express my sincere thanks to our H.O.D, Prof. Dr. Paulose Jacob for being a
great pillar to all our achievements.

I feel immense pleasure in thanking my guide Mr. G. Santhosh Kumar, Lecturer,

Department of Computer Science for his valuable suggestions and support during the
course of the project work.

I am extremely happy to thank Dr.Sumam Mary Idicula and Dr David Peter S,

Professors, Department of Computer Science for their excellent guidance and invaluable
help rendered throughout this project in a versatile manner.

I express my sincere thanks to all the staff members of Department of Computer

Science, Cochin University of Science and Technology for their help throughout the
course of the project.
 ABSTRACT

Voice over Internet Protocol is a protocol VOiP optimized for the transmission of voice
through the internet or other packet switched networks. The main objective of the project
is to develop an integrated VOIP Platform consisting of RTOS along with a VOIP
Module.
The development of VOIP platform involves the following stages

• Development of Audio drivers for TMS3200M6446 board which involves

include capturing of raw audio data from microphone and playing it on sound
device

• Development of Ethernet driver for TMS3200M6446 board which involves

capturing and sending of raw data from the sender and receiver from the network

• Development of Audio codec which involves compression/decompression of raw

audio/compressed data

• Development of SIP (Session Initiation Protocol) which is meant for initiation of

session between two users in a network before communication

• Development of RTP(Real Time Protocol) meant for streaming packets to the

network

• Integration of all these modules with RTOS and port it to TMS3200M6446 board
• Integration involves attaching the respective modules to RTOS threads, RTOS
file system, and RTOS time stamps and develop an integrated built for Davanci
processor containing all these modules
Table Of Contents
Chapter 1 Introduction ............................................................................................ 1
1.1VoIP ............................................................................................................... 1
Chapter 2 VoIP Protocol Stack ........................................................................... 3
2.1 Data Plane protocols ..................................................................................... 3
2.1.1 RTP Protocol(Real Time Protocol)........................................................ 3
2.1.2 RTCP Protocol(Real Time Control Protocol)........................................ 6
2.1.3 RTCP XR ............................................................................................... 6
2.1.4 CODECs ................................................................................................ 7
2.2 Voice Quality Metrics................................................................................... 8
Chapter 3 Control Plane Protocols.................................................................... 11
3.1SIP(Session Initiation Protocol)................................................................... 11
3.1.1Introduction to SIP................................................................................ 11
3.2 Components OF SIP ................................................................................... 12
3.2.1 SIP Clients ........................................................................................... 13
3.2.2 SIP Servers........................................................................................... 14
3.3 SIP Working................................................................................................ 14
3.3.1 Working Of SIP Using Proxy server ................................................... 15
3.3.2 Working Of SIP Using Redirect Server............................................... 17
3.4 SIP Protocol .................................................................................................... 19
Chapter 4 PJSIP .................................................................................................... 25
4.1 Architecture Of PJSIP................................................................................. 25
4.2 Uniform Resource Indicator(URI ............................................................... 31
4.2.1 URI Class Diagram .............................................................................. 31
4.3 PJSIP Header Fields.................................................................................... 31
4.4 Transport Layer Design .............................................................................. 32
4.4.1 Transport Manager............................................................................... 33
4.4.2 Transport Operation ............................................................................. 34
4.5 Sending Messages....................................................................................... 34
4.6 PJSIP Transaction ...................................................................................... 35
12 Chapter 2

4.7 PJSIP Authentication Frame work............................................................. 36

4.8 Basic User Agent Layer .............................................................................. 37
4.9 SDP Offer/Answer Framework.................................................................. 39
4.10 Dialog Invite Session ................................................................................ 41
Chapter 5 PJSIP Library Architecture ................................................................. 45
5.1 PJLIB .......................................................................................................... 45
5.2 PJLIB-UTIL................................................................................................ 46
5.3.1 STUN Protocol Library........................................................................ 47
5.3.2 ICE Protocol Library............................................................................ 49
5.4 PJMEDIA.................................................................................................... 50
Chapter 6 VoIP Platform Development................................................................ 53
Appendix A: Sample Screen shots of SIP............................................................ 55
References............................................................................................................. 59
LIST OF TABLES

Table No Description Page no

3.4.1 Informational responses 21
3.4.2 Server Error Responses 22
3.4.3 Success Responses 22
3.4.4 Global Failure Responses 23
3.4.5 Client Error Responses 23
4.10.1 Invite Session State Description 42
 List Of Figures
Figure 2. 1 Protocol stack for VoIP Network ......................................................... 3
Figure 2.1.1. 1 RTP Protocol Stack ........................................................................ 3
Figure 2.1.1. 2 RTP Header Structure..................................................................... 4
Figure 3.2. 1 SIP Architecture .............................................................................. 13
Figure 3.3.1. 1 SIP Request Through Proxy Server............................................. 15
Figure 3.3.1. 2 SIP Response through Proxy Server............................................. 16
Figure 3.3.1. 3 SIP Session Through A Proxy Server ......................................... 17
Figure 3.3.2. 1 SIP Request Through A Redirect Server...................................... 18
Figure 3.3.2. 2 SIP Session Through A Redirect Server ...................................... 19
Figure 3.4. 1 SIP Message Headerss..................................................................... 20
Figure 4.1. 1 Architecture of PJSIP ...................................................................... 25
Figure 4.1. 2 Class Diagram Of PJSIP................................................................ 26
Figure 4.1. 3 Module State Diagram..................................................................... 28
Figure 4.1. 4 Cascade module Call back.............................................................. 28
Figure 4.2.1. 1 Class Diagram Showing URI Components ................................. 31
Figure 4.3. 1 Header Class Diagram.................................................................... 32
Figure 4.4. 1 Transport Layer Class Diagram....................................................... 33
Figure 4.7. 1 Authentication Frame work Class Diagram .................................... 36
Figure 4.8. 1 Basic User Agent Class Diagram .................................................... 38
Figure 4.9. 1 SDP Negotiator Class Diagram ....................................................... 39
Figure 4.9. 2 SDP Offer/Answer Session State Diagram ..................................... 39
Figure 4.10. 1 ........................................................................................................ 42
Figure 5. 1 Architecture Model of PJSIP Library................................................. 45
Figure 5.3.1. 1 Organization of Stun Library........................................................ 48
Figure 5.3.2. 1 Organization of ICE Library ........................................................ 49
List of Symbols, Abbreviations and Nomenclature

Symbols/Abbreviations/ Description
VoIP Voice Over Internet Protocol
ADC Analog To Digital Converter
DAC Digital To Analog Converter
TCP Transmission Control Protocol
IP Internet Protocol

UDP User Datagram Protocol

HDLC High Level Data Link Control
RTP Real Time Protocol
CODEC Coder-Decoder
SSRC Synchronization Source
CSRC Contributing Source
RTCP Real Time Control Protocol
RTCPXR Real Time Control Protocol Extended Report
WAN Wide Area Network
LAN Local Area Network
UAC User Agent Client
UAS User Agent Server
PSTN Public Switched Telephone Network
RTOS Real Time Operating System
SIP Session Initiation Protocol
HTTP Hyper Text Transfer Protocol
RFC Request For Comments
CRC Cyclic Redundancy Check
 Chapter 1 Introduction
1.1VoIP
VoIP stands for 'V'oice 'o'ver 'I'nternet 'P'rotocol. As the term says VoIP tries to
let go voice (mainly human) through IP packets and, in definitive through Internet. VoIP
can use accelerating hardware to achieve this purpose and can also be used in a PC
environment. The analog voice signal is digitalized by using an ADC(analog to digital
converter), transmit it, and at the end transform it again in analog format with DAC
(digital to analog converter) to use it. We can compress the digital data , route it, convert
it to a new better format, and soon; also we saw that digital signal is more noise tolerant
than the analog one .TCP/IP networks are made of IP packets containing a header (to
control communication) and a payload to transport data: VoIP use it to go across the
network and come to destination. The voice over IP (VoIP) protocol suite is generically
broken into two categories, control plane protocols and data plane protocols. The control
plane portion of the VoIP protocol is the traffic required to connect and maintain the
actual user traffic. It is also responsible for maintaining overall network operation (router
to router communications). The data plane (voice) portion of the VoIP protocol is the
actual traffic that needs to get from one end to another. Within the VoIP suite of
protocols, voice packets are commonly referred to as the data plane. Likewise, signaling
packets are commonly referred to as the control plane.
 Chapter 2 VoIP Protocol Stack
The following figure shows the protocol stack for a VoIP Network

Figure 2. 1 Protocol stack for VoIP Network

2.1 Data Plane protocols

2.1.1 RTP Protocol(Real Time Protocol)
RTP is the protocol that supports user voice. Each RTP packet contains a small sample of
the voice conversation. The size of the packet and the size of the voice sample inside the
packet will depend on the
CODEC used. The following diagram shows the RTP protocol stack

Figure 2.1.1. 1 RTP Protocol Stack

RTP information is encapsulated in a UDP packet. If an RTP packet is lost or dropped by
the network, it will not be retransmitted (as is standard for the UDP protocol). This is
4 Chapter 2
__________________________________________________________________

because a user would not want a long pause or delay in the conversation due to the
network or the phones requesting lost packets. The network should be designed, though,
so that few packets are lost in transmission. The RTP frame contains several pieces of
information to identify and manage each individual call from endpoint to endpoint. This
information includes a timestamp, a sequence number, and conversation synchronization
source information. The structure of an RTP Header is as shown below

Figure 2.1.1. 2 RTP Header Structure

Version – This is the RTP version number. It is currently set to 2.

Padding – This gives the number of bytes at the end of the payload that are considered
padding (not voice) and should be ignored. Padding is often used when encryption is
enabled to keep the packets at a fixed length.
Extension (X) – If set, the header is extended.
VoIP Protocol Stack 5
_________________________________________________________________

CSRC Count – This provides the number of CSRC headers that follow the fixed header.
Marker – The interpretation of the marker is defined by a profile. It is intended to allow
for the marking of significant events, such as frame boundaries, in the packet stream.
Payload Type – This field identifies the format of the RTP payload and determines its
interpretation by the application. The following list contains the possible payload types,
as defined by RFC3351.
Sequence Number – This number increments by one for each RTP data packet sent. In
addition, it may be used by the receiver to detect packet loss and to restore packet
sequence. The initial value of the sequence number is chosen randomly
Timestamp – This reflects the sampling instant of the first octet in the RTP data packet.
The sampling instant must be derived from a clock that increments monotonically and
linearly in time to allow synchronization and jitter calculations. The resolution of the
clock must be sufficient for the desired synchronization accuracy and for measuring
packet arrival jitter. The clock frequency is dependent on the format of the data carried as
payload. It is specified statically in the profile, or payload format specification, that
defines the format. It may also be specified dynamically for payload formats defined
through non-RTP means. If RTP packets are generated periodically, the nominal
sampling instant, as determined from the sampling clock, is used. A reading of the system
clock is not used. The initial value of the timestamp is random, as is the sequence
number.
SSRC – This identifies the synchronization source. The value is chosen randomly, with
the intent that no two synchronization sources within the same RTP session will have the
same SSRC. Although the probability of multiple sources choosing the same identifier is
low, all RTP implementations must be prepared to detect and resolve collisions. If a
source changes its source transport address, it must also choose a new SSRC to avoid
being interpreted as a looped source.
6 Chapter 2
__________________________________________________________________

CSRC – This is a list identifying the contributing sources for the payload contained in
the packet. The number of identifiers is given by the CC field. CSRC identifiers are
inserted by mixers, using the SSRC identifiers of contributing sources.
2.1.2 RTCP Protocol(Real Time Control Protocol)
Real-Time Control Protocol (RTCP) is a data plane protocol that is not always used. This
protocol allows the endpoints to communicate directly regarding the quality of the call.
RTCP affords the endpoints the ability to adjust the call in real time to increase the
quality of the call. RTCP also aids significantly in the troubleshooting of a voice stream.
Traditional VoIP analyzers sit at specific locations on a circuit and base their derived
results from only the packets that they capture. With RTCP enabled, the analyzer can see
the end-to-end quality as well as the quality at the point at which the analyzer is inserted.
This capability allows the user to sectionalize problems much more quickly
2.1.3 RTCP XR
RTP Control Protocol Extended Reports (RTCP XR) is a newer extension of the RTCP
concept. It defines a set of metrics that can be inexpensively added to call managers, call
gateways, and IP phones for call quality analysis. RTCP XR messages are exchanged
periodically between IP phones and gateways.With RTCP XR messages enabled, an
analyzer sitting midstream on a voice call can see and decode the messages. These
messages can also be retrieved via SNMP requests and can be fed into a larger network
performance management system. RTCP XR provides information on the following call
quality metrics.
Packet Loss/Discard – The endpoints of a phone call examine each RTP packet and
identify lost packets using the sequence numbers. The endpoints also identify those
packets that arrive too late and are discarded by the endpoint. These RTP packets are
referred to as discarded packets.
VoIP Protocol Stack 7
_________________________________________________________________

Delay – RTCP XR reports on the round trip delay detected using RTCP and adds
reporting information on the full envelope delay. The envelope delay includes the
CODEC and jitter buffer.
SNR and Echo – RTCP XR reports on the signal-to-noise ratio (SNR) at each endpoint.
If the endpoint is equipped with an echo canceller, RTPC XR reports on the un-canceled
echo level.
Overall Call Quality – Using simple embedded algorithms, RTCP XR can report MOS
ratings or Rfactor values for the call.
Configuration Information – RTCP XR can report on the overall configuration of an
endpoint, including jitter buffer size.
2.1.4 CODECs
There is a wide range of voice CODECs (coder/decoder or compression/decompression)
protocols
available for VoIP phone implementation. The most common voice Codec’s include
G.711, G.723, G.726, G.728, and G.729. A brief description of each CODEC follows.
G.711 – Converts voice into a 64 kbps voice stream. This is the same CODEC used in
traditional TDM T1 voice. It is considered the highest quality.
G.723.1 – There are two different types of G.723.1 compression. One type uses a CELP
compression algorithm and has a bit rate 5.3 kbps. The other type uses an MP-MLQ
algorithm and provides better quality sound. This type has a bit rate of 6.3 kbps.
G.726 – This CODEC allows for several different bit rates, including 40 kbps, 32 kbps,
24 kbps, and 16 kbps. It works well with packet to PBX interconnections. It is most
commonly deployed at 32 kbps.
G.728 – This CODEC provides good voice quality and is specifically designed for low
latency applications.
It compresses voice into a 16 kbps stream.
8 Chapter 2
__________________________________________________________________

G.729 – This is one of the better voice quality CODECs. It converts voice into an 8 kbps
stream. There are two versions of this CODEC, G.729 and G.729a. G.729a has a more
simplified algorithm over G.729, allowing the end phones to have less processing power
for the same level of quality.
2.2 Voice Quality Metrics.
The following are the factors that affect the quality of VoIP call.
CODEC
The choice of CODEC is the first factor in determining the quality of a call. Generally,
the higher the bit rate used for the CODEC, the better the voice quality. Higher bit rate
CODECs, however, take up more space on the network and also allow for fewer total
calls on the network.
Network
The biggest factor in call quality is the design, implementation, and use of the network
that the voice calls are riding on. A typical VoIP call will start on a LAN at a CPE, go
through a WAN connection to a provider cloud, and then go back out the other end. The
CPE LAN and WAN links are most vulnerable to over utilization and errors. Most VoIP
quality issues are typically caused at these links. There are several ways a network can
affect a VoIP call, including packet jitter, packet loss, and delay.
Packet jitter This is caused by changes in the inter-arrival gap between packets at the
endpoint. The packets should arrive evenly spaced to allow for a seamless conversion
into analog voice. If the packet gap changes, the user could experience degradation in
quality. If the packet gap gets sufficiently large, the phone’s packet jitter buffer will not
be able to wait for the late packet, and the phone will drop the late packet. There are three
different types of packet jitter – RFC jitter, instantaneous jitter, and absolute jitter.
RFC jitter, or “smoothed jitter” :, is defined by an ITU standard and essentially assigns
a standardized value to the packet jitter of a call. The advantages of this metric are that it
is defined by a standard organization and the equipment measuring this type of jitter
VoIP Protocol Stack 9
_________________________________________________________________

should generate the same results. The disadvantages of RFC jitter are that it is a
fluctuating average, and it eliminates spikes in the jitter that can cause packets to be
dropped by the phone’s jitter buffer. For these reasons, RFC jitter is not a very useful
statistic.
Instantaneous jitter : is the actual inter-packet jitter measurement, measuring the arrival
time of each packet. There is no smoothing algorithm to eliminate spikes. Instantaneous
jitter is the most realistic jitter measurement. The jitter buffer uses the instantaneous jitter
measurement to determine which packets it will keep and which packets it will drop.
Absolute jitter: is very different from RFC jitter or instantaneous jitter. Both RFC and
instantaneous jitter rely on the current packet gap to determine their values. Absolute
jitter represents the changes in inter-packet arrival times as compared to the previous
packet gap.
Packet loss – This is the actual loss of voice packets through a network. Packet loss is
often caused by congestion at one or more points along the path of the voice call or by a
poor quality link (one that experiences physical layer errors).
Delay – Delay, sometimes referred to as envelope delay, is the time it takes for the voice
to travel from the handset of one phone to the ear piece of the other phone. Envelope
delay is the sum of the delay caused by the CODEC of choice, jitter buffer in the phone,
and the path time it takes for the packets to get through the network. A large delay can
make conversation difficult.
Echo
Echo is a common problem for VoIP networks. It is important to note that, unlike packet
jitter, packet loss, and delay, echo is not caused by the IP network. Echo is an analog
impairment. It is extremely difficult to passively monitor for echo. The best way to detect
echo is by placing a call onto the network with a known “good” device or capturing the
voice packets of a call and playing them back for analysis. There are two types of echo on
10 Chapter 2
__________________________________________________________________

analog voice networks – hybrid echo and acoustic echo. Hybrid echo is generated by
impedance mismatches at various analog or digital points on the network. The most
common location for the generation of hybrid echo is at a 2-wire to a 4-wire conversion
point. Acoustic echo is generated at the phone. It occurs when the voice leaving the
speaker is picked up by the microphone.
 Chapter 3 Control Plane Protocols
The control plane is used for the various signaling protocols, allowing users of VoIP to
connect their phone calls. There are several different types of VoIP signaling available
today, including H.323, SIP, SCCP, MGCP, MEGACO, and SIGTRAN
3.1SIP(Session Initiation Protocol)
3.1.1Introduction to SIP
Session Initiation Protocol (SIP) is the Internet Engineering Task Force’s (IETF’s)
standard for multimedia conferencing over IP. SIP is an ASCII-based, application-layer
control protocol (defined in RFC 2543) that can be used to establish, maintain, and
terminate calls between two or more end points. SIP is designed to address the functions
of signaling and session management within a packet telephony network. Signaling
allows call information to be carried across network boundaries. Session management
provides the ability to control the attributes of an end-to-end call. SIP provides the
capabilities to
• Determine the location of the target end point—SIP supports address resolution, name
mapping, and call redirection.
• Determine the media capabilities of the target end point—Via Session Description
Protocol (SDP), SIP determines the “lowest level” of common services between the end
points. Conferences are established using only the media capabilities that can be
supported by all end points.
• Determine the availability of the target end point—If a call cannot be completed
because the target end point is unavailable, SIP determines whether the called party is
already on the phone or did not answer in the allotted number of rings. It then returns a
message indicating why the target end point was unavailable.
• Establish a session between the originating and target end point—If the call can be
completed, SIP establishes a session between the end points. SIP also supports mid-call
12 Chapter 3
__________________________________________________________________

changes, such as the addition of another end point to the conference or the changing of a
media characteristic or codec.
• Handle the transfer and termination of calls—SIP supports the transfer of calls from one
end point to another. During a call transfer, SIP simply establishes a session between the
transferee and a new end point (specified by the transferring party) and terminates the
session between the transferee and the transferring party. At the end of a call, SIP
terminates the sessions between all parties.
3.2 Components OF SIP
SIP is a peer-to-peer protocol. The peers in a session are called User Agents (UAs). A
user agent can function in one of the following roles:
• User agent client (UAC)—A client application that initiates the SIP request.
• User agent server (UAS)—A server application that contacts the user when a SIP
request is received and that returns a response on behalf of the user. Typically, a SIP end
point is capable of functioning as both a UAC and a UAS, but functions only as one or
the other per transaction. Whether the endpoint functions as a UAC or a UAS depends on
the UA that initiated the request. From an architecture standpoint, the physical
components of a SIP network can be grouped into clients and servers. The following
figure illustrates the architecture of SIP
Control Plane Protocols 13
__________________________________________________________________

Figure 3.2. 1 SIP Architecture

SIP servers can interact with other application services, such as Lightweight Directory
Access Protocol (LDAP) servers, location servers, a database application, or an
extensible markup language (XML) application. These application services provide back-
end services such as directory, authentication, and billing services.
3.2.1 SIP Clients
SIP clients include:
14 Chapter 3
__________________________________________________________________

• Phones—Can act as either a UAS or UAC. Soft phones (PCs that have phone
capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to
requests.
• Gateways—Provide call control. Gateways provide many services, the most common
being a translation function between SIP conferencing endpoints and other terminal
types. This function includes translation between transmission formats and between
communications procedures. In addition, the gateway translates between audio and video
codec’s and performs call setup and clearing on both the LAN side and the switched-
circuit network side.
3.2.2 SIP Servers
SIP servers include:
• Proxy server—The proxy server is an intermediate device that receives SIP requests
from a client and then forwards the requests on the client’s behalf. Basically, proxy
servers receive SIP messages and forward them to the next SIP server in the network.
Proxy servers can provide functions such as authentication, authorization, network access
control, routing, reliable request retransmission, and security.
• Redirect server—Provides the client with information about the next hop or hops that a
message should take and then the client contacts the next hop server or UAS directly.
• Registrar server—Processes requests from UACs for registration of their current
location. Registrar servers are often co-located with a redirect or proxy server.
3.3 SIP Working
SIP is a simple, ASCII-based protocol that uses requests and responses to establish
communication among the various components in the network and to ultimately establish
a conference between two or more end points. Users in a SIP network are identified by
unique SIP addresses. A SIP address is similar to an e-mail address and is in the format of
sip:userID@gateway.com. The user ID can be either a user name or an E.164 address.
Users register with a registrar server using their assigned SIP addresses. The registrar
Control Plane Protocols 15
__________________________________________________________________

server provides this information to the location server upon request. When a user initiates
a call, a SIP request is sent to a SIP server (either a proxy or a redirect server). The
request includes the address of the caller (in the From header field) and the address of the
intended callee (in the To header field).
3.3.1 Working Of SIP Using Proxy server
If a proxy server is used, the caller UA sends an INVITE request to the proxy server, the
proxy server determines the path, and then forwards the request to the callee. It is as
shown in the figure given below

Figure 3.3.1. 1 SIP Request Through Proxy Server

16 Chapter 3
__________________________________________________________________

The callee responds to the proxy server, which in turn, forwards the response to the
caller. It is shown in the figure given below

Figure 3.3.1. 2 SIP Response through Proxy Server

The proxy server forwards the acknowledgments of both parties. A session is then
established between the caller and callee. Real-time Transfer Protocol (RTP) is used for
the communication between the caller and the callee. It is shown in the figure given
below
Control Plane Protocols 17
__________________________________________________________________

Figure 3.3.1. 3 SIP Session Through A Proxy Server

3.3.2 Working Of SIP Using Redirect Server

If a redirect server is used, the caller UA sends an INVITE request to the redirect server,
the redirect server contacts the location server to determine the path to the callee, and
then the redirect server sends that information back to the caller. The caller then
acknowledges receipt of the information. It is shown in the figure given below
18 Chapter 3
__________________________________________________________________

Figure 3.3.2. 1 SIP Request Through A Redirect Server

The caller then sends a request to the device indicated in the redirection information
(which could be the callee or another server that will forward the request). Once the
request reaches the callee, it sends back a response and the caller acknowledges the
response. RTP is used for the communication between the caller and the callee.It is
shown in the figure given below.
Control Plane Protocols 19
__________________________________________________________________

Figure 3.3.2. 2 SIP Session Through A Redirect Server

3.4 SIP Protocol

SIP messages can be broken into two major categories, including messages from clients
to servers and messages from servers back to clients.
Message Headers
Each message has a message header. The message header identifies the message type,
calling party, and called party. There are four basic message types.
General Headers – This message header applies to request and response messages.
Entity Headers – This message header provides information about the message body
type and the length.
20 Chapter 3
__________________________________________________________________

Request Headers – This message header enables clients to include additional request
information.
Response Headers – This message header enables the server to include additional
response information.
The following figure contains the specific message headers in each SIP message header
type

Figure 3.4. 1 SIP Message Headerss

Request Messages/Methods
Request messages are initiated by a client to a server. SIP, a “light” protocol, has only a
few request messages that it uses to connect calls. The following section defines the SIP
request messages
Control Plane Protocols 21
__________________________________________________________________

Invite – An invite message, as the name implies, is a request from a client to speak to
another client. It contains the media type and other capabilities of the client.
Acknowledgement – This message is a response to an invite message. It represents the
final message in the invite process and the beginning of the media exchange (voice).
Bye – This message is sent by either client to end a call. The server is the first to receive
the bye message followed by the opposite client.
Options – This message allows the client to collect information on other clients and the
servers.
Cancel – This message cancels any message exchanges that are in progress but not yet
completed.
Registration – This message registers a client with a server and allows the client to use
the services on the network.
Response Messages
There are two categories of response messages, provisional and final. Provisional
messages are sent during a request/response process as details are worked out. Final
messages, as the name implies, are the final response messages to a series of
request/response messages. There are five classes of response messages, including
success, client error, server error, global failure, and informational. Each message class
has several message types
Informational responses
Status Code Message
100 Trying
180 Ringing
181 Call Being Forwarded
182 Queued
183 Session Progress
22 Chapter 3
__________________________________________________________________

200 OK

Table.3.4.1 Informational responses

Server Error responses

Status Code Message

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 Version Not Supported

Table .3.4.2 Server Error Responses

Success responses

Status Code Message

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See other
305 Use Proxy
380 Alternative Service
Control Plane Protocols 23
__________________________________________________________________

Table.3.4.3 Success Responses

Global Failure Responses

Status Code Message
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See other
305 Use Proxy
380 Alternative Service

Table.3.4.4 Global Failure Responses

Client Error Responses

Status Code Message
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timed Out
409 Conflict
410 Gone
24 Chapter 3
__________________________________________________________________

411 Length Required

413 Request Entity Too Large
414 Request URL Too Large
415 Unsupported Media Type
420 Bad Extension
480 Temporarily Not Available
481 Transaction Does Not Exist
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

Table 3.4.5. Client Error Responses

 Chapter 4 PJSIP
4.1 Architecture Of PJSIP

Figure 4.1. 1 Architecture of PJSIP

The class diagram of PJSIP is shown in the figure below

26 Chapter 4
__________________________________________________________________

Figure 4.1. 2 Class Diagram Of PJSIP

The heart of the SIP stack is the SIP endpoint. The endpoint does the following functions.

¾ It has pool factory, and allocates pools for all SIP components.

¾ It has timer heap instance, and schedules timers for all SIP components.

¾ It has the transport manager instance. The transport manager has SIP
transports and controls message parsing and printing.

¾ It owns a single instance of PJLIB’s ioqueue. The ioqueue is a proactor

pattern to dispatch network events.
pjsip 27
__________________________________________________________________

¾ It provides a thread safe polling function, to which application’s threads

can poll for timer and socket events (PJSIP does not create any threads by
itself).

¾ It manages PJSIP modules. PJSIP module is the primary means for

extending the stack beyond message parsing and transport.

¾ It receives incoming SIP messages from transport manager and distributes

the message to modules.

The structure of a module interface is as shown below

struct pjsip_module
{
PJ_DECL_LIST_MEMBER(struct pjsip_module); // For internal list mgmt.
pj_str_t name; // Module name.
int id; // Module ID, set by endpt
int priority; // Priority
pj_status_t (*load) (pjsip_endpoint *endpt); // Called to load the mod.
pj_status_t (*start) (void); // Called to start.
pj_status_t (*stop) (void); // Called top stop.
pj_status_t (*unload) (void); // Called before unload
pj_bool_t (*on_rx_request) (pjsip_rx_data *rdata); // Called on rx request
pj_bool_t (*on_rx_response)(pjsip_rx_data *rdata); // Called on rx response
pj_status_t (*on_tx_request) (pjsip_tx_data *tdata); // Called on tx request
pj_status_t (*on_tx_response)(pjsip_tx_data *tdata); // Called on tx request
void (*on_tsx_state) (pjsip_transaction *tsx, // Called on transaction
pjsip_event *event); // state changed
};
The four function pointers load, start, stop, and unload are called by endpoint to
control the module state. The module state’s life time is as shown in the figure below
28 Chapter 4
__________________________________________________________________

Figure 4.1. 3 Module State Diagram

The priority of the modules are as shown below

¾ Transport Layer (Highest Priority)

¾ Transaction Layer
¾ User Agent or Proxy Layer
¾ Dialog Layer(invite usage, event subscription, frame work)
¾ Application Layer

The on_rx_request() and on_rx_response() function pointers are the primary

means for the module to receive SIP messages from endpoint (pjsip_endpt) or
from other modules. The return value of these callbacks is important. If a callback
has returned non-zero (i.e. true condition), it semantically means that the module
has taken care the message; in this case, the endpoint will stop distributing the
message to other modules. The incoming message processing by the modules are as
shown in the figure given below.

Figure 4.1. 4 Cascade module Call back

When incoming message arrives, it is represented as receive message buffer (struct

pjsip_rx_data, see section 5.1 “Receive Data Buffer”). Transport manager parses the
pjsip 29
__________________________________________________________________

message, put the parsed data structures in the receive message buffer, and passes the
message to the endpoint.The endpoint distributes the receive message buffer to each
registered module by calling on_rx_request() or on_rx_response() callback, starting
from module with highest priority (i.e. lowest priority number) until one of them returns
non-zero. When one of the module has returned non-zero, endpoint stops distributing the
message to the remaining of the modules, because it assumes that the module
has taken care about the processing of the message. The module which returns non-zero
on the callback itself may further distribute the message to other modules. For example,
the transaction module, upon receiving matching message, will process the message then
distributes the message to its transaction user, which in itself must be a module too. The
transaction passes the message to the transaction user (i.e. a module) by calling
on_rx_request() or on_rx_response() callback of that module, after setting the
transaction field in the receive message buffer so that the transaction user module can
distinguish between messages that are outside transactions and messages that are inside a
transaction.
The on_tx_request() and on_tx_response() function pointers are
called by transport manager before a message is transmitted. This gives an opportunity
for some types of modules (e.g. sigcomp, message signing) chance to make last
modification to the message. All modules MUST return PJ_SUCCESS (i.e. zero status),
or otherwise the transmission will be cancelled.
An outgoing request or response message is represented by a
transmit data buffer (pjsip_tx_data), which among other things, contains the message
structure itself, memory pool, contiguous buffer, and transport info. When
pjsip_transport_send() is called to send a message, transport manager calls
on_tx_request() or on_tx_response() for all modules, starting with modules with lowest
priority (i.e. highest priority number). When these callbacks are called, the message may
30 Chapter 4
__________________________________________________________________

have or have not been processed by the transport layer. The transport layer is responsible
for managing these information inside a transmit buffer:
¾ transport info, and
¾ printing the message structure to contiguous buffer.
Modules with priority lower than PJSIP_MOD_PRIORITY_TRANSPORT_LAYER (i.e.
has higher priority number) will receive the message before these information are
obtained. That means the destination address has not been calculated, and message has
not been printed to contiguous buffer. If modules want to modify the message structure
before it is printed to buffer, then it must set its priority number higher than transport
layer priority. If modules want to see the actual packet bytes as they are transmitted to the
wire (e.g. for logging purpose), then it should set its priority number to lower than
transport layer.
pjsip 31
__________________________________________________________________

4.2 Uniform Resource Indicator(URI)

4.2.1 URI Class Diagram

Figure 4.2.1. 1 Class Diagram Showing URI Components

pjsip_uri structure contains uri that is shared by all types of URI. pjsip_sip_uri structure
represents SIP and SIPS URI scheme. The structure pjsip_tel_uri represents tel: URL. A
name address (pjsip_name_addr) does not really define a new type of URI, but rather
encapsulates existing URI (e.g. SIP URI) and adds display name.
4.3 PJSIP Header Fields
The following figure shows the PJSIP header class diagram
32 Chapter 4
__________________________________________________________________

Figure 4.3. 1 Header Class Diagram

4.4 Transport Layer Design

The class diagram showing the relationships between the instances in the Transport
Layer is as shown below
pjsip 33
__________________________________________________________________

Figure 4.4. 1 Transport Layer Class Diagram

4.4.1 Transport Manager

The transport manager do the following functions

¾ Manages transports life-time by using transport’s reference counter and

idle timer.

¾ Manages transport factories. The transport is used to create dynamic connection

to remote endpoint.

¾ Receives packet from transport, parse the packet, and deliver the SIP
message to endpoint.

¾ Find matching transport to send SIP message to particular destination

34 Chapter 4
__________________________________________________________________

based on the transport type and remote address.

¾ Create new transports dynamically when no existing transport is available

to send SIP message to a new destination.
4.4.2 Transport Operation
The transport objects receive packets from the network and deliver the packets to
transport manager for further processing. The transport object receive packets by
registering the transport’s socket handle to the end point I/O queue so that when the end
point polls the I/O queue ,packets from the network is received by the transport object.
Once a packet is received by a transport object it must deliver the packet to the transport
manager. The transport manager parse the packet and distribute it to the rest of the stack
Each transport object has a pointer to function to send messages to the network (i.e.
send_msg() attribute of the transport object). Application (or the stack) sends messages
to the network by calling pjsip_transport_send() function, which eventually will reach
the transport object, and send_msg() will be called. The sending of packet may complete
asynchronously; if so, transport must return PJ_EPENDING status in send_msg() and call
the callback that is specified in argument when the message has been sent to destination.
4.5 Sending Messages
The core operations in SIP applications are of course sending and receiving message.
Receiving incoming message is handled in on_rx_request() and on_rx_response()
callback of each module. The core API’s for sending messages are
pjsip_endpt_send_request_stateless() and pjsip_endpt_send_response() functions.
The pjsip_endpt_send_request_stateless () function performs the following procedures:
¾ Determine which destination to contact based on the Request-URI and
parameters in Route headers
¾ Resolve the destination server using procedures in RFC 3263 (Locating SIP
Servers),
¾ Select and establish transport to be used to contact the server
pjsip 35
__________________________________________________________________

¾ Modify sent-by in Via header to reflect current transport being used

¾ Send the message using current transport
¾ Fail-over to next server/transport if server can not be contacted using
current transport

The pjsip_endpt_send_response () function are for sending response messages,

and it performs the following procedures:

¾ Follow the procedures in Section 18.2.2 of RFC 3261 to select which transport
to use and which address to send response to,
¾ Additionally conform to RFC 3581 about rport parameter
¾ Send the response using the selected transport
¾ Fail-over to next address when response failed to be sent using the selected
transport, resolving the server according to RFC 3263 when necessary.
4.6 PJSIP Transaction
Transaction in PJSIP is represented with pjsip_transaction structure in header
Transaction’s lifetime normally follows these steps:
¾ Created by pjsip_tsx_endpt_create_uac () / pjsip_tsx_create_uas().
¾ After initializing UAS transaction, application needs to call
pjsip_tsx_recv_msg() to pass in the initial request message so that transaction
state can move from NULL to TRYING. Subsequent request retransmissions will
be absorbed by the transaction.
¾ When application wants to send request or response message using the
transaction, it will call pjsip_tsx_send_msg().
36 Chapter 4
__________________________________________________________________

¾ Transaction state automatically changes as messages are passed to it (either by

endpoint for incoming message or by transaction user for outgoing message) or
timer elapses, and transaction user is notified via on_tsx_state() callback.
¾ Transaction will be automatically destroyed once it the state has reached
PJSIP_TSX_STATE_TERMINATED. Application can also forcibly terminate
the transaction by calling pjsip_tsx_terminate().

4.7 PJSIP Authentication Frame work

PJSIP provides frame work for performing both client and server authentication. The
authentication framework supports HTTP digest authentication by default, but other
authentication schemes may be added to the framework. The class diagram for the
authentication frame work is as shown below.

Figure 4.7. 1 Authentication Frame work Class Diagram

pjsip 37
__________________________________________________________________

It consists of a client authentication frame work and server authentication framework The
client authentication framework manages authentication process by client to all
downstream servers. It can respond to server’s challenge with the correct credential
(when such credential is supplied), cache the authorization info, and initialize subsequent
requests with the cached authorization info. The server authorization framework provides
session-less server authorization, which provides general API for authenticating clients.
This API provides global server authorization mechanism on request-per-request basis,
and is normally used for proxy application when it doesn’t do call state full.It also
provides server authorization session, which provides API for authenticating requests
inside a particular dialog or registration session. One server authorization session instance
needs to be created for each server side dialog or registration session. A server auth
session will have exactly one credential which is setup initially, and this credential must
be used by client throughout the duration of the dialog/registration session.

4.8 Basic User Agent Layer

The basic UA dialog provides basic facilities for managing SIP dialogs and dialog
usages , such as basic dialog state, session counter, Call-ID, From, To, and
Contact headers, sequencing of CSeq in transactions, and route-set. The class diagram for
User agent layer and basic dialog frame work is as shown below
38 Chapter 4
__________________________________________________________________

Figure 4.8. 1 Basic User Agent Class Diagram

The diagram shows the relationship between dialog and its usages. In the most basic/low-
level scenario, the application module is the only usage of the dialog. more high-level
scenario, some high-level modules (e.g. pjsip_invite_usage and pjsip_subscribe_usage)
can be registered to a dialog as dialog’s usages, and the application will receive events
from these usages instead of directly from the dialog. The diagram also shows PJSIP
user agent module (pjsip_user_agent). The user agent module is the “owner” of all
dialogs; the user agent module maintains a hash table of all dialog sets currently active.
pjsip 39
__________________________________________________________________

4.9 SDP Offer/Answer Framework

The main function of the framework is to facilitate the negotiating of media capabilities
between local and remote parties, and to get agreement on which set of media to be used
in one invite session. The SDP negotiator class diagram is as shown below

Figure 4.9. 1 SDP Negotiator Class Diagram

The general state transition of SDP offer/answer session is shown in the following
diagram.

Figure 4.9. 2 SDP Offer/Answer Session State Diagram

40 Chapter 4
__________________________________________________________________

The negotiation session starts with NULL. If the dialog has a local media description
ready and want to offer the media to remote (normally this is the case when the dialog is
acting as UAC), it creates the SDP negotiator by passing the local SDP to the function
pjmedia_sdp_neg_create_w_local_offer(). This function will set the initial capability of
local endpoint, and set the negotiation session state to LOCAL_OFFER. The initial SDP
then can be sent to remote party in the outgoing INVITE request. Once dialog has
received remote’s SDP, it must call pjmedia_sdp_neg_rx_remote_answer() with
providing the remote’s SDP. The negotiation function can then be called. If the dialog
already has remote media description in hand (normally this is the case when dialog is
acting as UAS), it can create the SDP negotiator session by passing both local and remote
SDP to pjmedia_sdp_neg_create_w_remote_offer().After this, the negotiation function
can be called. After the session has been established, both local and remote party may
modify the session. The negotiator can handle one of these two situations:
¾ The dialog has received SDP from remote. In this case, the dialog will call
pjmedia_sdp_neg_rx_remote_offer() and passing the remote’s SDP to this
function. After this the negotiation function can be called. The negotiation
function’s return value determines whether there is modification needed in
the local media.
¾ The local party wants to send SDP to remote. Dialog can further choose
one of the following actions:
• If it just wants to send currently active local SDP without modification, it
should call pjmedia_sdp_neg_tx_local_offer() to get the active local
SDP,send the SDP, then wait for the
remote’s answer.
pjsip 41
__________________________________________________________________

• If it wants to modify currently active local media (e.g. changing stream

direction, change active codec, etc), it should get the active local media
with pjmedia_sdp_neg_get_local(), modify it, call
pjmedia_sdp_neg_modify_local_offer() to update the offer, send the
local SDP, then wait for the remote’s answer.
• The dialog may want to completely change the local media (e.g.
changing IP address, changing codec set, adding new media line). This is
different than updating current media described above because it will
change initial_sdp, so that future negotiation will be based on this new
SDP. If the dialog wants to do this, it calls
pjmedia_sdp_neg_reinit_local_offer() with the new local SDP, send the
SDP, then wait for remote’s answer.
After the dialog has sent offer to remote party, it should receive answer back from the
remote party. The dialog must provide the remote’s SDP to the negotiator so that the
negotiation function can be called. The dialog provides the remote’s answer by calling
pjsip_sdp_neg_rx_remote_answer(). If remote has rejected local’s offer (e.g. returning
488/”Not Acceptable Here” response), dialog MUST still call
pjsip_sdp_neg_rx_remote_answer() with providing NULL in remote’s SDP argument,
and call the negotiation function so that the negotiator session can revert back to
previously active session descriptions, if any.
4.10 Dialog Invite Session
The dialog invite session is a high level invite session management, which can be used by
application to manage invite session (including SDP management). The invite session is
designed to completely abstract the basic dialog, so application should not need to use
basic dialog API when it is using the invite session API. A dialog invite session can be
created by application on per dialog basis. The dialog invite session is managed by dialog
invite usage, which is a PJSIP module. The dialog invite usage performs dispatching of
42 Chapter 4
__________________________________________________________________

events from the dialog to the corresponding invite session, and also handles forked
dialog. The dialog invite session and usage is implemented in a separate static library, i.e.
pjsip-ua library. The dialog invite session provides Session progress reporting (e.g.
session progressing, connected, confirmed, disconnected), Automatic authentication
handling (e.g. retry the request on receipt of 401/407 response), SDP offer and answer
handling, High-level forking handler, Session timeout, Session extensions, such as
session timer, and reliable provisional response. The state diagram for the invite session
is shown below.

Figure 4.10. 1

Figure.4.10.1 Invite Session State Diagram

The description of each state is as follows

State Description
NULL This is the state of the session when it was first created. No
messages have been sent/received t this point.

CALLING The session state after the first INVITE message is sent, but
before any provisional response is received.
pjsip 43
__________________________________________________________________

INCOMING The session state after the first INVITE message is received,
but before any provisional response is sent.
EARLY The session state after dialog has sent or received provisional
response messages for the INVITE request, only when To tag
is present.
CONNECTING The session state after a final 2xx response has been sent or
received.
CONFIRMED The session state after ACK request has been sent or received.
DISCONNECTED The session state when the session has been disconnected,
either because of non-successful final response to INVITE or
BYE request.

Table.4.10.1 Invite Session State Description

 Chapter 5 PJSIP Library Architecture

The architecture Library for PJSIP is as shown below

Figure 5. 1 Architecture Model of PJSIP Library

5.1 PJLIB
PJLIB is a small footprint framework library written in C for making scalable
applications. PJLIB provides operating system abstractions which includes.
• Threads
• Thread Local storage
• Mutexes
• Semaphores
• Atomic Variables
• Critical Sections
• Lock Objects
46 Chapter 5
__________________________________________________________________

• Event Object
• Time Data type And Manipulation
• High Resolution Time Stamp

These features are written for platforms like Unix, Windows, MacOS etc.
PJLIB also provides low level network I/O which includes

• Socket Abstraction
A highly portable socket abstraction, runs on all kind of network APIs such as
standard BSD socket, Windows socket, Linux kernel socket, PalmOS
networking API, etc.

• Network Address Resolution

Portable address resolution, which implements pj_gethostbyname.()

• Socket select() API.

A portable select() like API (pj_sock_select()) which can be implemented with
various back-end.

PJLIB provides data structures that fo string operations, Array helper, hash table, linked
list, balanced tree etc

5.2 PJLIB-UTIL
The PJLIB-UTIL contains the following modules

• Encryption Algorithms
o Base64 Encoding/Decoding
o CRC32 (Cyclic Redundancy Check)
o HMAC MD5 Message Authentication
o HMAC SHA1 Message Authentication
o MD5
Pjsip library Architecture 47
__________________________________________________________________

o SHA1
• Simple STUN Helper
• PJLIB-UTIL Library
o PJLIB-UTIL Configuration
o DNS and Asynchronous DNS Resolver
ƒ Low-level DNS Message Parsing and Packetization
ƒ DNS Asynchronous/Caching Resolution Engine
ƒ DNS SRV Resolution Helper
o PJLIB-UTIL Error Codes
o GetOpt
o Fast Text Scanning
o String Escaping Utilities
o Mini/Tiny XML Parser/Helper

5.3 PJNATH
PJNATH contains ICE,STUN and TURN libraries.
5.3.1 STUN Protocol Library
Session Traversal Utilities (STUN, or previously known as Simple Traversal of User
Datagram Protocol (UDP) Through Network Address Translators (NAT)s), is a
lightweight protocol that serves as a tool for application protocols in dealing with NAT
traversal. It allows a client to determine the IP address and port allocated to them by a
NAT and to keep NAT bindings open..The organization of a STUN Library is as shown
below
48 Chapter 5
__________________________________________________________________

Figure 5.3.1. 1 Organization of Stun Library

• For both client and server, the highest abstraction is STUN Client/Server
Session, which provides management of incoming and outgoing messages and
association of STUN credential to a STUN session.
• For client, the next layer below is STUN Client Transaction, which manages
retransmissions of STUN request. Server side STUN transaction is handled in
STUN Client/Server Session layer above.
• STUN Authentication provides mechanism to verify STUN credential in
incoming STUN messages.
• The lowest layer of the library is STUN Message Representation and Parsing.
This layer provides STUN message representation, validation, parsing, encoding
Pjsip library Architecture 49
__________________________________________________________________

MESSAGE-INTEGRITY for outgoing messages, and debugging (dump to log)

of STUN messages.
All STUN library components are independent of any transports. Application gives
incoming packet to the STUN components for processing, and it must supply the
STUN components with callback to send outgoing messages.
5.3.2 ICE Protocol Library
Interactive Connectivity Establishment (ICE) is a standard based methodology for
traversing Network Address Translator (NAT).Organization of ICE Library is as shown
in the figure below

Figure 5.3.2. 1 Organization of ICE Library

The ICE library is organized as follows:
50 Chapter 5
__________________________________________________________________

• The highest abstraction is ICE media transport, which maintains ICE stream
transport and provides SDP translations to be used for SIP offer/answer
exchanges. ICE media transport is part of PJMEDIA library.

• Higher in the hierarchy is ICE Stream Transport, which binds ICE with UDP
sockets, and provides STUN binding and relay/TURN allocation for the sockets.
This component can be directly used by application, although normally
application should use the next higher abstraction since it provides SDP
translations and better integration with other PJ libraries such as PJSIP and
PJMEDIA.

• The lowest layer is ICE Session, which provides ICE management and
negotiation in a transport-independent way. This layer contains the state
machines to perform ICE negotiation, and provides the most flexibility to control
all aspects of ICE session. This layer normally is only usable for ICE
implementers.

5.4 PJMEDIA
PJMEDIA is a rather complete media stack, distributed under ,featuring small footprint
and good extensibility and portability. The pjmedia Library contains the following
modules

• PJMEDIA Library
o Codec Framework
ƒ G711
ƒ GSM 06.10 Codec
ƒ iLBC Codec
ƒ L16 Codec Family
Pjsip library Architecture 51
__________________________________________________________________

ƒ Speex Codec Family

o Base Types and Configurations
ƒ Compile time configuration
ƒ Error Codes
ƒ Basic Types
o The Endpoint
o Media Ports Framework
ƒ Media Port Interface
o Sessions
ƒ SDP Parsing and Data Structure
ƒ SDP Negotiation State Machine (Offer/Answer Model, RFC
3264)
ƒ Media session
o Media Transports
ƒ RTCP Session and Encapsulation (RFC 3550)
ƒ RTP Session and Encapsulation (RFC 3550)
ƒ Media Network Transport Interface
ƒ ICE Capable media transport
ƒ Secure RTP (SRTP) Transport Adapter
ƒ UDP Socket Transport
o Frame Operations
ƒ Delay Buffer
ƒ Adaptive jitter buffer
ƒ Packet Lost Concealment (PLC)
ƒ Resampling Algorithm
ƒ Adaptive Silence Detection
52 Chapter 5
__________________________________________________________________

o Misc
ƒ WAVE Header
• Ports
o Bidirectional Port
o Conference Bridge
o Accoustic Echo Cancellation API
o Echo Cancellation Port
o Memory/Buffer-based Playback Port
o Memory/Buffer-based Capture Port
o Null Port
o Resample Port
o Streams
o Tone (sine, MF, DTMF) Generator
o WAV File Play List
o WAV File Player
o File Writer (Recorder)
o Media channel splitter/combiner
• Clock/Timing
o Master Port
o Sound Device Port
ƒ Portable Sound Hardware Abstraction
o Clock Generator

PJSIP,PJSIP_SIMPLE AND PJSIP-UA are all part of SIP stack

 Chapter 6 VoIP Platform Development
It involves the integration of PJSIP library with RTOS which involves the following steps
• Extracting a particular OS Platform layer available from PJSIP libraries
• Replacing the PJSIP socket layer with RTOS specific layer and test the
performance in a simulated environment.
• Replacing PJSIP thread specific layer with RTOS threads and test the
performance in a simulated environment.
• Replacing PJSIP platform specific timestamp utilities with RTOS specific
timestamp utilities and test it in a simulated environment.
• Replacing PJSIP platform specific file system calls to with RTOS specific
file system calls and test it in a simulated environment.
• Development of the target platform containing RTOS, File system, TCP/IP
stack and audio drivers.
• Integrating the simulated build with the new platform
• Testing the performance
Appendix A 55
__________________________________________________________________

Appendix A: Sample Screen shots of SIP

Screen shot of line status of 3cx phone system

Appendix A 56
__________________________________________________________________

Screen shot of SIP registration

Appendix A 57
__________________________________________________________________

Captured data from hyperterminal after running VoIP Platform

HeartOS
COLDFIRE Platform Release, Build Date : Mar 5 2008
Version Information,
POSIX Version : 1.45
Core Version : 1.34
HAL Version : 1.33

Booting Heart OS....Done.

Mounted HFS
Got DHCP Data....
Got DHCP Data....
Subnet : 255.255.255.0

DHCP address : 199.63.32.25

Router : 10.1.20.1

Offered IP = 10.1.20.16
DNS : 199.63.32.7

00:00:00.000 os_core_unix.c pjlib 0.8.0 for POSIX initialized

3341596:610768:10147188.10147188 sip_endpoint.c Creating endpoint instance...
10147120:3349588:00.602668 pjlib select() I/O Queue created (003B246C)
5556312:00:00.000 sip_endpoint.c Module "mod-msg-print" registered
602668:10147128:3878048.3345600 sip_transport. Transport manager created.
13:08:1028548.003 sip_endpoint.c Module "mod-pjsua-log" registered
13:08:1028548.007 sip_endpoint.c Module "mod-tsx-layer" registered
13:08:1025276.4294967295 sip_endpoint.c Module "mod-stateful-util" registered
5587940:00:00.000 sip_endpoint.c Module "mod-ua" registered
934750:3878724:605082.006 sip_endpoint.c Module "mod-100rel" registered
09:04:1033875.4294967293 sip_endpoint.c Module "mod-pjsua" registered
109258:10146352:01.3345700 sip_endpoint.c Module "mod-invite" registered
00:256142:10146284.000 sound_port.c PortAudio sound library initialized, status=0
00:256142:10146284.000 sound_port.c PortAudio host api count=1
00:256142:10146284.000 sound_port.c Sound device count=5
10146280:4037156:00.602668 pjlib select() I/O Queue created (003D7C9C)
Appendix A 58
__________________________________________________________________

09:04:928153.4294967285 sip_endpoint.c Module "mod-evsub" registered

09:03:928154.008 sip_endpoint.c Module "mod-presence" registered
09:04:928153.002 sip_endpoint.c Module "mod-refer" registered
09:00:928157.001 sip_endpoint.c Module "mod-pjsua-pres" registered
12:01:932446.4294967289 sip_endpoint.c Module "mod-pjsua-im" registered
12:01:929606.006 sip_endpoint.c Module "mod-pjsua-options" registered
608872:10146428:10146400.000 pjsua_core.c 1 SIP worker threads created
10146428:10146400:4051000.608872 pjsua_core.c pjsua version 0.8.0 for linux
initialized
585182:10146972:00.002 pjsua_core.c SIP UDP socket reachable at
199.63.42.198:5070
1042950:80:10146924.10146868 sip_transport_ Error setting SO_RCVBUF: Unknown
error -1 [-1]
1042950:80:10146924.10146868 sip_transport_ Error setting SO_SNDBUF: Unknown
error -1 [-1]
70002:3877136:596582.000 udp003DEAB0 SIP UDP transport started, published
address is 199.63.42.198:5070
585182:10146844:00.004 pjsua_media.c RTP socket reachable at 199.63.42.198:4000
585182:10146844:00.004 pjsua_media.c RTCP socket reachable at 199.63.42.198:4001
4071736:4026084:285412.4072000 pjsua_media.c pjsua_set_snd_dev(): attempting to
open devices @32000 Hz
5561340:17:813226.5561340 os_core_unix.c Info: possibly re-registering existing thread
5561580:17:813226.5561580 pjsua_acc.c Account sip:102@199.63.28.97 added with
id 0
4089996:422656:10146036.1023809 pjsua_core.c TX 470 bytes Request msg
REGISTER/cseq=2 (tdta003E4EA0) to UDP 199.63.28.97:5060:
REGISTER sip:199.63.28.97 SIP/2.0
Via: SIP/2.0/UDP
199.63.42.198:5070;rport;branch=z9hG4bKPj00000000000300000001
Max-Forwards: 70
From: <sip:102@199.63.28.97>;tag=00000000000200000001
To: <sip:102@199.63.28.97>
Call-ID: 00000000000100000001
CSeq: 2 REGISTER
A%s%s%s%s%s%s%s%s%s%s%s%d Decoder stream started
 59

References
1) http://www.pjsip.org/pjlib/docs/pjlib.pdf

2) http://www.pjsip.org/pjlib-util/docs/html/modules.htm

3) http://www.pjsip.org/pjnath/docs/html/index.htm

4) http://www.pjsip.org/pjmedia/docs/html/index.htm

5) http://www.pjsip.org/release/0.5.4/PJSIP-Dev-Guide.pdf

6) http://www.pjsip.org/pjsip/docs/html/index.htm

7) http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm

8) http://www.pjsip.org/pjsua.htm

9) http://www.3cx.com/manual/3CXPhoneSystemManual5.pdf

10) http://www.3cx.com/manual/3CXVOIPclientmanual5.pdf

11) http://www.portaudio.com/docs/portaudio_icmc2001.pdf

12) http://www.opensound.com/pguide/oss.pdf (Refer Audio programming)

13) http://portaudio.com/docs/v19-doxydocs/group__test__src.html

14) http://manuals.opensound.com/developer/