of 79
8/6/2019 Suresh Report Voip1
1/79
8/6/2019 Suresh Report Voip1
2/79
8/6/2019 Suresh Report Voip1
3/79
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
8/6/2019 Suresh Report Voip1
4/79
8/6/2019 Suresh Report Voip1
5/79
8/6/2019 Suresh Report Voip1
6/79
8/6/2019 Suresh Report Voip1
7/79
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.
8/6/2019 Suresh Report Voip1
8/79
8/6/2019 Suresh Report Voip1
9/79
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
8/6/2019 Suresh Report Voip1
10/79
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
8/6/2019 Suresh Report Voip1
11/79
Table Of Contents
Chapter 1 Introduction ............................................................................................ 1
1.1VoIP............................................................................................................... 1Chapter 2 VoIP Protocol Stack........................................................................... 3
2.1 Data Plane protocols ..................................................................................... 32.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................................................................................... 8Chapter 3 Control Plane Protocols.................................................................... 11
3.1SIP(Session Initiation Protocol)................................................................... 113.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 .................................................................................................... 254.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....................................................................................... 344.6 PJSIP Transaction ...................................................................................... 35
8/6/2019 Suresh Report Voip1
12/79
12 Chapter 2
4.7 PJSIP Authentication Frame work............................................................. 36
4.8 Basic User Agent Layer.............................................................................. 374.9 SDP Offer/Answer Framework.................................................................. 39
4.10 Dialog Invite Session................................................................................ 41Chapter 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................................................................ 53Appendix A: Sample Screen shots of SIP............................................................ 55
References............................................................................................................. 59
8/6/2019 Suresh Report Voip1
13/79
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
8/6/2019 Suresh Report Voip1
14/79
8/6/2019 Suresh Report Voip1
15/79
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 ...................................... 19Figure 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
8/6/2019 Suresh Report Voip1
16/79
Figure 5.3.1. 1 Organization of Stun Library........................................................ 48
Figure 5.3.2. 1 Organization of ICE Library ........................................................ 49
8/6/2019 Suresh Report Voip1
17/79
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
8/6/2019 Suresh Report Voip1
18/79
HTTP Hyper Text Transfer Protocol
RFC Request For Comments
CRC Cyclic Redundancy Check
8/6/2019 Suresh Report Voip1
19/79
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 thenetwork 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.
8/6/2019 Suresh Report Voip1
20/79
8/6/2019 Suresh Report Voip1
21/79
8/6/2019 Suresh Report Voip1
22/79
8/6/2019 Suresh Report Voip1
23/79
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
8/6/2019 Suresh Report Voip1
24/79
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.
8/6/2019 Suresh Report Voip1
25/79
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.
8/6/2019 Suresh Report Voip1
26/79
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.
8/6/2019 Suresh Report Voip1
27/79
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 CODECsThere is a wide range of voice CODECs (coder/decoder or compression/decompression)
protocols
available for VoIP phone implementation. The most common voice Codecs 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/6/2019 Suresh Report Voip1
28/79
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 phones 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
8/6/2019 Suresh Report Voip1
29/79
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 phones 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
8/6/2019 Suresh Report Voip1
30/79
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.
8/6/2019 Suresh Report Voip1
31/79
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 Forces (IETFs)
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 pointSIP supports address resolution, name
mapping, and call redirection.
Determine the media capabilities of the target end pointVia 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 pointIf 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 pointIf the call can be
completed, SIP establishes a session between the end points. SIP also supports mid-call
8/6/2019 Suresh Report Voip1
32/79
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 callsSIP 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
8/6/2019 Suresh Report Voip1
33/79
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:
8/6/2019 Suresh Report Voip1
34/79
14 Chapter 3__________________________________________________________________
PhonesCan 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.
GatewaysProvide 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
codecs 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 serverThe proxy server is an intermediate device that receives SIP requests
from a client and then forwards the requests on the clients 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 serverProvides 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 serverProcesses requests from UACs for registration of their current
location. Registrar servers are often co-located with a redirect or proxy server.
3.3 SIP WorkingSIP 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:[email protected]. 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
8/6/2019 Suresh Report Voip1
35/79
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 serverIf 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
8/6/2019 Suresh Report Voip1
36/79
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
8/6/2019 Suresh Report Voip1
37/79
Control Plane Protocols 17
__________________________________________________________________
Figure 3.3.1. 3 SIP Session Through A Proxy Server
3.3.2 Working Of SIP Using Redirect ServerIf 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
8/6/2019 Suresh Report Voip1
38/79
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.
8/6/2019 Suresh Report Voip1
39/79
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.
8/6/2019 Suresh Report Voip1
40/79
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
8/6/2019 Suresh Report Voip1
41/79
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
8/6/2019 Suresh Report Voip1
42/79
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
8/6/2019 Suresh Report Voip1
43/79
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
8/6/2019 Suresh Report Voip1
44/79
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
8/6/2019 Suresh Report Voip1
45/79
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
8/6/2019 Suresh Report Voip1
46/79
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 SIPtransports and controls message parsing and printing.
It owns a single instance of PJLIBs ioqueue. The ioqueue is a proactorpattern to dispatch network events.
8/6/2019 Suresh Report Voip1
47/79
pjsip 27
__________________________________________________________________
It provides a thread safe polling function, to which applications threadscan poll for timer and socket events (PJSIP does not create any threads by
itself).
It manages PJSIP modules. PJSIP module is the primary means forextending the stack beyond message parsing and transport.
It receives incoming SIP messages from transport manager and distributesthe 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 states life time is as shown in the figure below
8/6/2019 Suresh Report Voip1
48/79
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 asshown 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
8/6/2019 Suresh Report Voip1
49/79
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
8/6/2019 Suresh Report Voip1
50/79
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 informationareobtained. 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 numberhigher 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 numberto lower than
transport layer.
8/6/2019 Suresh Report Voip1
51/79
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_urirepresents tel: URL. Aname address (pjsip_name_addr) does not really define a new type of URI, but ratherencapsulates existing URI (e.g. SIP URI) and adds display name.
4.3 PJSIP Header Fields
The following figure shows the PJSIP header class diagram
8/6/2019 Suresh Report Voip1
52/79
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
8/6/2019 Suresh Report Voip1
53/79
8/6/2019 Suresh Report Voip1
54/79
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 transports 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 APIs 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
8/6/2019 Suresh Report Voip1
55/79
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
Transactions lifetime normally follows these steps:
Created by pjsip_tsx_endpt_create_uac ()/pjsip_tsx_create_uas().
After initializing UAS transaction, application needs to callpjsip_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().
8/6/2019 Suresh Report Voip1
56/79
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.Theauthentication 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
8/6/2019 Suresh Report Voip1
57/79
pjsip 37
__________________________________________________________________
It consists of a client authentication frame work and server authentication frameworkTheclient authentication framework manages authentication process by client to all
downstream servers. It can respond to servers 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 providessession-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 doesnt 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
8/6/2019 Suresh Report Voip1
58/79
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 dialogs 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.
8/6/2019 Suresh Report Voip1
59/79
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
8/6/2019 Suresh Report Voip1
60/79
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 remotes SDP, it must call pjmedia_sdp_neg_rx_remote_answer() with
providing the remotes 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 remotes SDP to this
function. After this the negotiation function can be called. The negotiation
functions 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
remotes answer.
8/6/2019 Suresh Report Voip1
61/79
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 remotes 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 remotes answer.
After the dialog has sent offer to remote party, it should receive answer back from the
remote party. The dialog must provide the remotes SDP to the negotiator so that the
negotiation function can be called. The dialog provides the remotes answer by calling
pjsip_sdp_neg_rx_remote_answer(). If remote has rejected locals offer (e.g. returning
488/Not Acceptable Here response), dialog MUST still call
pjsip_sdp_neg_rx_remote_answer() with providing NULL in remotes 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
8/6/2019 Suresh Report Voip1
62/79
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 authenticationhandling (e.g. retry the request on receipt of 401/407 response),SDP offer and answerhandling,High-level forking handler,Session timeout,Session extensions, such assession 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.
8/6/2019 Suresh Report Voip1
63/79
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
8/6/2019 Suresh Report Voip1
64/79
8/6/2019 Suresh Report Voip1
65/79
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
8/6/2019 Suresh Report Voip1
66/79
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-UTILThe 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
8/6/2019 Suresh Report Voip1
67/79
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
8/6/2019 Suresh Report Voip1
68/79
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
8/6/2019 Suresh Report Voip1
69/79
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:
8/6/2019 Suresh Report Voip1
70/79
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 PJMEDIAPJMEDIA is a rather complete media stack, distributed under ,featuring small footprint
and good extensibility and portability. The pjmedia Library contains the followingmodules
PJMEDIA Library
o Codec Framework
G711
GSM 06.10 Codec
iLBC Codec
L16 Codec Family
8/6/2019 Suresh Report Voip1
71/79
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
8/6/2019 Suresh Report Voip1
72/79
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
8/6/2019 Suresh Report Voip1
73/79
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
8/6/2019 Suresh Report Voip1
74/79
8/6/2019 Suresh Report Voip1
75/79
Appendix A 55
__________________________________________________________________
Appendix A: Sample Screen shots of SIP
Screen shot of line status of 3cx phone system
8/6/2019 Suresh Report Voip1
76/79
Appendix A 56
__________________________________________________________________
Screen shot of SIP registration
8/6/2019 Suresh Report Voip1
77/79
Appendix A 57
__________________________________________________________________
Captured data from hyperterminal after running VoIP Platform
HeartOSCOLDFIRE 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)
8/6/2019 Suresh Report Voip1
78/79
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" registered09: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:[email protected] 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.0Via: SIP/2.0/UDP
199.63.42.198:5070;rport;branch=z9hG4bKPj00000000000300000001
Max-Forwards: 70
From: ;tag=00000000000200000001
To:
Call-ID: 00000000000100000001
CSeq: 2 REGISTER
A%s%s%s%s%s%s%s%s%s%s%s%d Decoder stream started
8/6/2019 Suresh Report Voip1
79/79
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/