suresh report voip1

8/6/2019 Suresh Report Voip1

1/79


2/79


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


4/79


5/79


6/79


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/79


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


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


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


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


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


14/79


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


16/79

Figure 5.3.1. 1 Organization of Stun Library........................................................ 48

Figure 5.3.2. 1 Organization of ICE Library ........................................................ 49


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


18/79

HTTP Hyper Text Transfer Protocol

RFC Request For Comments

CRC Cyclic Redundancy Check


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.


20/79


21/79


22/79


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


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.


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.


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.


27/79


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.


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


29/79


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


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.


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


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


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:


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


35/79


__________________________________________________________________

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


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


37/79


__________________________________________________________________

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


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.


39/79


__________________________________________________________________

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.


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


41/79


__________________________________________________________________

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


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


43/79


__________________________________________________________________

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


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


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


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.


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


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


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


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.


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


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


53/79


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


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().


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


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


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.


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


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.


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


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.


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


64/79


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


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


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


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


69/79


__________________________________________________________________

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:


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


71/79


__________________________________________________________________

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


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


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


74/79


75/79

Appendix A 55

__________________________________________________________________

Appendix A: Sample Screen shots of SIP

Screen shot of line status of 3cx phone system


76/79

Appendix A 56

__________________________________________________________________

Screen shot of SIP registration


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)


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


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/

suresh report voip1

Documents