Peering with a SIP Proxy Server · 2015-11-19 · Crossroads: Peering with a SIP Proxy Server IIT...

Crossroads: Peering with a SIP Proxy Server IIT

Project Report 1

Crossroads Peering with a SIP Proxy Server

Gus Herrera - A20315178 Cruz Tovar - A20277095

December 5, 2014


Project Report 2

Abstract Asterisk has many communication functionalities and is widely used in commercial and

non-commercial settings. The most common use of Asterisk is its use as a Voice over IP

(VoIP) gateway. This allows the legacy Public Switch Telephone Network (PSTN) to

create a bridge between VoIP connections. Other functionalities of Asterisk include an IP

PBX, voicemail server, call center, and more. In this project Asterisk is used as a SIP

proxy in order to allow connectivity, or create peering connections, between multiple

VoIP endpoints inside the Real Time Communications (RTC) Lab. The scope of this paper is to show how to interconnect two or more VoIP end-points

through an Open Source Session Initiation Protocol (SIP) Proxy server. By peering

connections between to other testbeds, Asterisk is able to control how calls are

established from end-to-end. The remainder of the paper describes the goals of the this

project, network topology, description of testbeds used for peering, a brief overview of

how to configure Asterisk, description of ladder diagrams taken from Wireshark from our

peered connections, and lastly conclusions of what was achieved.


Project Report 3

Table of Contents

Abstract ........................................................................................................................................ 2 Table of Contents ...................................................................................................................... 3 Introduction ............................................................................................................................... 4 Project Goals ............................................................................................................................... 4 Materials and Equipment ...................................................................................................... 4 Test Beds ...................................................................................................................................... 5 Logical Architecture ................................................................................................................ 5 Physical Architecture .............................................................................................................. 6 Asterisk ........................................................................................................................................ 6

sip.conf Configuration File .............................................................................................................. 6 extensions.conf Configuration File ............................................................................................... 7 Peering with Asterisk ........................................................................................................................ 8

Kamailio ....................................................................................................................................... 9 Peering with Kamailio ...................................................................................................................... 9

Ladder Diagram...................................................................................................................... 10 Conclusions .............................................................................................................................. 13 References ................................................................................................................................ 13 Appendices ............................................................................................................................... 14


Project Report 4

Introduction Creating a peering connection between SIP proxies is a way to allow traffic to pass

without needing to rely on DNS to lookup where a proxy lives. By peering a SIP proxy

server it allows efficiency to communicate with other SIP proxies that it may need to

communicate with regularly. For example, configuring a peering connection between

different site locations for businesses is a prime example. If one business has a location

in Chicago and another in Seattle, a peering connection may be set in place between two

SIP proxy servers to allow these offices to communicate via phone and or video

conferencing. In this project the Crossroads SIP Proxy Server, will act as the device that

will create peering connections to the various Real Time Communication Labs testbeds.

By having a central device, this allows communication to travel efficiently between these

networks.

Project Goals

The goal of this project was to interconnect the various testbeds at Illinois Institute of

Technology (IIT) Real Time Communnication (RTC) Lab by using Asterisk as peering

SIP proxy. RTC testbeds include Voice Over IIT (VoIIT) and Mobility. VoIIT uses

Kamailio as its SIP proxy and Mobility uses Asterisk as its SIP proxy server.

Materials and Equipment

The Asterisk gateway runs on a Premio Desktop running Centos 6.5. The version of

Asterisk was built from the source code and is version 11.13.10. Installation of Asterisk

also included several other libraries and packages in order for Asterisk to run on Centos.

These included: ● gcc ● g++ ● make ● libncurses-dev ● libxml2-dev ● libsqlite3-dev ● libssl-dev ● uuid-dev

To test the Asterisk gateway and the testbeds, we configured softphones to make test

calls. X-Lite and Zoipher classic were used to make test calls between the various

testbeds.


Project Report 5

Test Beds

For this project there are several testbeds that are capable for peering with the Asterisk

gateway. For the scope of this project VoIIT and Mobility were used to make peered

connection with the Crossroads Asterisk SIP proxy. The Mobility testbed studies real-time communications applications and services that are

carried over wireless networks. In this testbed, Asterisk is used as SIP Proxy. The Voice over IIT (VoIIT) is a working SIP-based telephone service test bed. Its

routing proxy is Kamailio and it uses MySQL database to store its user information.

VoIIT is connected to the PSTN using a SIP-Trunk from Cbeyond, a Voice Service

Provider.

Logical Architecture

Figure 1: Logical Architecture Diagram


Project Report 6

Physical Architecture

Figure 2: Physical Architecture Diagram

Asterisk

Asterisk is an open source communications framework created in 1999 by Mark Spencer.

Asterisk allows users to build and install Asterisk onto a typical server and its output

becomes a sophisticated communication server. Asterisk can be used as a PSTN

gateway, voicemail service, Interactive Voice Response (IVR), conference bridging, and

more. For the scope of this project Asterisk is configured as a SIP proxy server that will

act as a bridge between the other SIP-based testbeds in the RTC Lab by peering with the

other testbeds.

sip.conf Configuration File

Within Asterisk there are two main files that are used for configuration of the Asterisk,

sip.conf and extensions.conf. The latter file will be explained in more detail in the

following section The sip.conf file is used for the configuration of the SIP protocol. This is the file that will

allow a SIP phone to be registered with the system. The below sample code is a typical format for configuring SIP protocol to be used with

Asterisk. Options under the [general] section, will be applied to all SIP clients and

trunks used in Asterisk. Using two brackets [ ], signifies that a new section is being


Project Report 7

created in the configuration file.

In the below example [MySipPhone] is the next section being defined. It is this

section that defines the SIP device to be used, MySipPhone is the name of the device as

well as the extension. When configuring devices for SIP it is possible to use

alphanumeric characters to define a device. The next option in this section is type,

which is set to friend. This means that the client (or user agent) will be able to send

and receive calls. The host option in our example is set to dynamic. This means that

client has a dynamic IP address and that it is not static. If there was a static address for

this client, then the IP address could be set here. The secret option is a password for

this client, in our example the password would be supersecretpasswordhere.

The last option that is set is context, which is set to internal. This references a

section in the extensions.conf configuration file, which will then go through a set of rules

defined in the [internal] section of this file.

extensions.conf Configuration File

The extensions.conf file is the dialplan of Asterisk, which helps calls route to the correct

client when they are dialed. Dialplans have two special context sections, which do not

necessarily need any options defined in the dialplan. These are [general] and

[globals] section. In the example below, we have not set any options under these

contexts.

In the example below, we have defined a context as [internal], which is also

referenced by the sip.conf file. This context defines what will occur when referenced by

the extensions in the context=interal option of the sip.conf file. In the dialplan, an

extension is composed of three components that are name, priority and application.

Below is the format of completed extension.

The exten => is syntax for extension. The name, is the extension that was defined

[general]

[MySipPhone]

type=friend

host=dynamic

secret=supersecretpasswordhere context=internal

exten => name,priority,application()


Project Report 8

which in the above example is MySipPhone. This is then followed by priority, which is

a 1 or n. The n priority stands for next, and will continue to go down the dialplan for the

extension being called and will add a 1 to the previous priority. This makes it easier to

prioritize dialplans so that when a change happens not all the dialplans will need to be re-

numbered. Lastly is the application componenet, which is a command that perform some

action to the extension being called.

In our first completed extension the first priority is to dial the MySipPhone extension

for 15 seconds. If the call is not answered after 15 seconds, it will then go to the next

priority that will playback a message that states “The party you are calling is currently

unavailable”. After that message is played, the next priority is to HangUp() which will

terminate the call.

Peering with Asterisk

In order to create a peering connection with other SIP Proxies, the sip.conf file must be

modified to include a register parameter. Below is an example of how the register

parameter should be configured.

Domain could either be the Fully Qualified Domain name of the SIP proxy, or could be

its IP address. Once this line had been added into the sip.conf file the peering proxies

should be able to register. In Asterisk type the command sip show registry and it

will show who is peering. Figure 3 shows that peering connections have been registered.

Figure 3: Peering Connections with Crossroads

general]

[globals]

[internal]

exten => MySipPhone,1,Dial(SIP/${EXTEN},15)

exten => MySipPhone,n,Playback(the-party-you-are-

calling&is-curntly-unavail)

exten => MySipPhone,n,Hangup()

register => username:[email protected]


Project Report 9

Kamailio

Kamailio is a very capable SIP router, much more sophisticated than Asterisk as it can

look inside packets and route based on what it finds or even re-write packets based on

user specified logic. Kamailio is an Open Source SIP Server able to handle thousands of call setups per

second. It can act as Registrar server, Proxy server, and Redirect server as well as

Location server, and SIP Application server. It supports many backend systems such as

MySQL where users are registered and network admin assign other privileges to them

throughout a user-friendly Web Management Interface: Siremis. Kamailio also offers a flexible debug and error message logging system with custom

messages including any header or pseudo-variable and parts of SIP message structure

incredible useful for testing, troubleshooting, and debugging purposes. Its interoperability

with other Media Servers can be used to build large VoIP servicing platforms or to scale

up SIP-to-PSTN gateways, PBX systems or media servers like Asterisk.

Peering with Kamailio

Kamailio does authentication for registration. If successful, it notifies Asterisk with a new

REGISTER, this means that the phone is available at its IP address. In order to

authenticate the users, Kamailio verifies the user's credentials in its MySQL database. Provisioning a user into the database is quite simple. Kamailio uses a graphical user web

interface called Seremis to simplify this process. In order to provision a user the

information that needs to be entered is the System username, password, and the SIP

domain. Lastly, once a user has been entered into the system they will be assigned into a

group that handles authentication when an incoming call is received.

Kamailio also handles call authentication. If the incoming call has the correct

authentication such as group name, the call will then be forwarded onto its final

destination. This process is done based on Kamailio config (Kamailio's config file locate

in /etc/kamailio) where the users credentials, user group and domain are verified. In

Figure 5, the username u-vk1-to-va-92 is registered to the Crossroads. Also in this Figure

we see the extensions 99111 and 99112 configured, which are the extensions able to

receive calls.


Project Report 10

Figure 4: Kamailio Online SIP Subscribers

Ladder Diagram

Below are two ladder diagrams, Figure 4 and Figure 5. Figure 4 shows a user agent (UA)

client that is configured on the Mobility Asterisk calling to a Crossroads UA. Two user

agents are configured on the Crossroads SIP Proxy in order to do testing, but will be

removed once Crossroads is at a production level.

In the testing process we tested to the closest hop working toward the furthest away hop.

Meaning we started centrally from the Crossroads and tested with either testbed

individually working our way to testing from end to end, Mobility to VoIIT networks.

Figure 4 displays an INVITE from Mobility UA going towards the Mobility Asterisk.

After the INVITE is received at the Mobility Asterisk, noting is captured between

Mobility Asterisk and Crossroads. This is because Wireshark is not capturing the

INVITE once it leaves Mobility Asterisk and comes to Crossroads. Once the INVITE

comes to Crossroads we can now see that the INVITE is being forwarded to the

Crossroads User Agent.


Project Report 11

The next ladder diagram (Figure 5) shows a call between Kamailio user agent and

Crossroads user agent. However, it is important to note that because of other issues

involved with peering we are not able to call the Crossroads UA without adding the IP

address where it resides. Under normal conditions we should just be able to dial the

extension of the user agent and because of the peered connection, it should route to the

appropriate softphone. However, due to versioning issues with our Asterisk and the

Kamailio on VoIIT it is not possible to dial by extension only. Therefore this ladder

diagram shows the Kamailio User Agent going directly to Crossroads and then reaching

the user agent on the Crossroads.

Figure 5: Ladder Diagram - Mobility Asterisk UA calling to Crossroads UA


Project Report 12

Figure 6: Ladder Diagram - Kamailio UA calling to Crossroads UA


Project Report 13

Conclusions Upon creating peering connections with VoIIT and Mobility testbeds our softphones for

testing purposes that are configured on the Crossroads were able to call to VoIIT and

Mobility. However when trying to call from end to end, either from VoIIT to Mobility or

Mobility to VoIIT calls were unsuccessful. With many hours spent looking at Wireshark

traces and troubleshooting with Lab Manager, Don Monte. He assessed that it could be

the version of Asterisk we are running on Crossroads. We believe this to be a fair

hypothesis since when putting the configurations on another Asterisk SIP proxy server

running an older version found no issues to peer. Further testing will be to change the

release version of Asterisk and see if that would solve any issues.

The next steps for the Crossroads project will be to solve the peering issues with

Kamailio and to successfully connect with other testbeds. We also need to move into the

production environment of the Mobility testbed, which will hopefully be achieved later

this month. Further peering with NG911 and WebRTC testbeds will be possible as well.

Once connected to the other testbeds testing can start on how call flow-through travels

through the interconnected RTC Lab testbeds. This will provide vital learning for how

SIP works with many peering devices that use various SIP proxy servers.

References Asterisk.org. (n.d.). Retrieved December 5, 2014, from http://www.asterisk.org/

Kamailio SIP Server. (n.d.). Retrieved December 5, 2014, from

http://www.kamailio.org/w/

Meggelen, J., & Smith, J. (2009). Asterisk the Future of Telephony. (2nd ed.). Sebastopol:

O'Reilly Media.


Project Report 14

Appendices sip.conf file in Crossroads

[general]

context=phones

canreinvite=yes

register => U-VK1-to-VA92:[email protected]/U-VK1-to-VA92

register => mobility:[email protected]/crossroad

[VoIIT]

type=peer

qualify=yes

secret=password

host=64.131.109.226

context=fromVoIIT

disallow=all

allow=ulaw

allow=alaw

allow=gsm

allow=h263

allow=h263p

[mobility]

type=peer

qualify=yes

secret=password

host=dynamic

context=fromMobility

disallow=all

allow=ulaw

allow=alaw

allow=gsm

allow=h263

allow=h263p

[98100]

type=friend

host=dynamic

secret=password

context=phones

[98101]

type=friend

host=dynamic

secret=password

context=phones


Project Report 15

extensions.conf file in Crossroads

[general]

autofallthrough=yes

[phones]

include => internal

include => remote

include => fromVoIIT

include => fromMobility

[internal]

exten => _981XX,1,Dial(SIP/${EXTEN},15)

exten => _981XX,n,Playback(the-party-you-are-calling&is-curntly-

unavail)

exten => _981XX,n,Hangup()

[remote]

;Mobility Extensions

exten => _980XX,1,NoOp()

exten => _980XX,n,Dial(SIP/mobility/${EXTEN})


;VoIIT Extensions on Kamailio


exten => _991XX,n,Dial(SIP/${EXTEN})


[fromVoIIT]

include => internal

[fromMobility]

include => internal


Project Report 16

sip.conf file in Mobility Asterisk

[general]

context=phones

canreinvite=yes

register => crossroad:[email protected]/mobility

[crossroad]

type=friend

secret=password

host=dynamic

context=fromCrossroad

allow=all

[98000]

type=friend

host=dynamic

secret=password

context=phones

allow=all

[98001]

type=friend

host=dynamic

secret=password

context=phones

allow=al

l


Project Report 17

extensions.conf file in Mobility Asterisk

[general]

autofallthrough=yes

[phones]

include => internal

include => remote

include => fromCrossroad

[internal]

exten => _980XX,1,Dial(SIP/${EXTEN},15)

exten => _980XX,n,Playback(the-party-you-are-calling&is-curntly-

unavail)


[remote]


exten => _981XX,n,Dial(SIP/crossroad/${EXTEN})



exten => _991XX,n,Dial(SIP/crossroad/${EXTEN})


[fromCrossroad]

include => remote

include => internal

Peering with a SIP Proxy Server · 2015-11-19 · Crossroads: Peering with a SIP Proxy Server IIT...

Documents

Transcript of Peering with a SIP Proxy Server · 2015-11-19 · Crossroads: Peering with a SIP Proxy Server IIT...