uninett sip infrastructure

UNINETT SIP infrastructure 7 February 2010

UNINETT SIP infrastructure, 7 February 2010

of 2


Page 1 of 36

Introduction This document describes UNINETT’s proposed SIP infrastructure. It is the result of work carried out as part

of the GigaCampus programme (2006-2009) and forms the basis of UNINETT’s continued work in this field.

From 2010, campus coordination activity will constitute a permanent area of emphasis for UNINETT, and

SIP infrastructure is incorporated as a key area of focus.

The document outlines the component issues and recommendations regarding the practical

implementation of the establishment of, and transition to, SIP. Moreover, it describes a range of possible

services that can be introduced. The document is written for HE institutions that wish to find out more

about the background concepts, technology, and the procedure required to participate in the SIP

infrastructure. It contains three main chapters and three supplementary annexes.

1. Infrastructure, page 4 Deals with the design of the SIP infrastructure

2. Migration, page 11

Addresses how an institution can make the transition from using a pure PBX-oriented system to SIP.

3. Services, page 17 What services are available, and what added value will accrue from employing SIP

A. SIP – a technical introduction, page 22 A simplified introduction to SIP, SRV, NAPTR and ENUM

B. SIP and security, page 27 A brief discussion regarding security issues related to SIP telephony

C. The migration process – step by step, page 30 Referring to Chapter 2 – a more detailed description of the migration process.

Abbreviations, page 36 This is a living document, and will be revised and modified to reflect the decisions made and practical

experience gained in connection with projects such as pilot implementation projects.


Page 2 of 36

Background and motivation Today we are utilising many forms of electronic communication such as one-to-one, one-to-many and

many-to-many. These include e-mail, telephony, instant messaging (IM), video calls/conferencing and

shared work surfaces. Looking into the future, we can get a glimpse of some of the new co-operative and

communications tools that may be developed, but we can be quite sure that others will appear that we

would never have predicted. A common feature of all these tools is the need to establish a connection between the parties in

communication. In order to achieve this we must have a means of defining addresses. We are all familiar

with the use of digits on our telephones. It is both unnatural and difficult for a human being to relate to

long strings of numbers. The Internet with its associated IP addresses provides a classic example of a

situation in which with the help of DNS we have managed to translate these into words, names and terms

that are easier to remember and to use. We have had to live with telephone numbers ever since

switchboards were first automated. Things have become more difficult as more digits have been generated

in each number as a result of the ever-increasing number of telephones

When we send e-mails, we use an e-mail address. In IM this varies depending on the type of IM we use, but

here too it is standard practice to have an address in a format that we are familiar with from our e-mails.

Gradually, as ever more and varied services become available, we will unfortunately also have to get used

to several different forms of addresses. Wouldn’t it be nice only to have to use one and the same address

for all these different services?

SIP (Session Initiation Protocol) technology opens the door to a wide variety of possibilities. SIP enables us

to call a name instead of a number. An SIP address is based on a logic format that can be structured

similarly to the one we use for e-mails. The use of a rational naming convention enables us to identify a

person, department, organisation and country in a format that is easy to remember and look up.

SIP enables us to facilitate the contact, thus making it possible to establish various different forms of

communication between the parties in question. One of the services most commonly associated with SIP is

telephony. However, telephony is such a well-known and much used service that it can easily overshadow

all the other possibilities that SIP has to offer. IP telephony and “VoIP” (Voice over IP) are terms that have

been the subject of much use and misuse. We should be aware that these terms may incorporate many

different types of systems that do not necessarily employ SIP, and may not be compatible with other

systems.

In our current context, we view IP telephony as a powerful augmentation of the service by means of putting

telephony “online”, and thus paving the way for a wide range of technological opportunities. A further

incentive is that we will be able to achieve financial savings in the longer term. There is currently no

technical reason why telephony and computing need be isolated by the use of their own separate lines and


Page 3 of 36

hardware. Nor is there any reason for us to deal with a single manufacturer for all our equipment needs,

software and services simply because the company in question is also manufacturer of the switchboard. In

other words, we are transferring the telephony logic onto the Internet while at the same time augmenting

the service by being able to establish links to other systems and tools that we already have - in an

environment that both the users and IT personnel are familiar with. This will result in financial savings for

the organisation in that the skills required for running both IT and telephony equipment can be merged in

the same department. By building up a person-to-person infrastructure, we also facilitate dynamic growth

towards other forms of communications media such as video, without encountering restrictions imposed

by an intermediary. In our SIP infrastructure, we intend to aspire to the following key principles:

• Maximise the use of open standards to ensure interaction between products and services from

different providers. This will generate competition among the manufacturers and we will get the opportunity to

combine the various products in ways that best suit our local requirements. It will also enable us to

carry out more rapid restructuring in anticipation of future services.

• The infrastructure must not put limits on our use of future services. SIP is commonly set up to support telephony services only. Such systems will encounter problems

in adapting to the needs of future facilities such as video telephony, and will exclude other services.

In some cases it is possible that we may wish to isolate telephony from other types of services. In

such situations telephony can be isolated, for example on separate networks and behind dedicated

portals. In the true spirit of SIP, data communication should be routed directly between the parties

while signalling passes though an intermediary. Under such conditions it will be up to the individual

client to decide which services it can support, without the artificial restrictions imposed by an

intermediary.

• Individual institutions will be able to utilise the services as they wish, both in terms of extent and

rate of system development. For various reasons, not all institutions will want immediately to adopt SIP in their local

infrastructure. Naturally enough, there will also be many who have made major investments in a

given telephone system and who intend that it should continue to function until the expiry of its

anticipated lifetime. This does not necessarily mean that such institutions will be unable to receive

some of the benefits and services provided by SIP. The infrastructure we build will take this into

account and will also pave the way for a gradual migration process, as required. In other words, it

will be possible theoretically to port numbers one by one at the desired rate. Our goal is that SIP will become a familiar and attractive technology in the HE sector, and that all personnel

will be allocated an SIP identity so that they will be reachable on the various services that SIP facilitates. In

time, on allocation of an SIP identity, it will also be possible to contact other organisations in Norway and

abroad that also utilise SIP. The number of such organisations is increasing rapidly, and it is evident from

development trends that this is the way the world is headed.


Page 4 of 36

1. The infrastructure The UNINETT SIP infrastructure is not a stand-alone infrastructure, but represents SIP applied in practice. It

consists of the individual institutions’ SIP-services, UNINETT-driven SIP services and, not least, the fruits of

extensive project coordination. In this respect the core of the infrastructure is represented by UNINETT’s

network infrastructure from which we exploit its characteristics of generous capacity and redundancy

which allow it to carry SIP-based services such as telephony. Naturally, the last-named service will receive

much emphasis in this document. The infrastructure is illustrated in the diagram below. The colour-shaded boxes represent the various

networks/organisations within which we have located the different entities and services. The presence of

one colour-shaded box within another indicates that the inner box is directly linked to the resources

provided by the outer.

Internet

SIP

UNINETT

SRV

ENUMe164.arpa

nrenum.net

PSTN

MGW

SIP PBX

PBX

Services

SIP

SIP PBX Services

SIP

Migration path

SRV

ENUMe164.arpa

nrenum.net

Services

Institution A

Institution B

TELEPHONY

MGW


Page 5 of 36

The institution (yellow- and green-shaded boxes) The status in respect of telephony at the various institutions may vary considerably. They may employ a

telephony exchange, such as those supplied by Nortel, Alcatel, Ericsson or Cisco. Some have made a partial

migration to VoIP, while others perhaps are already using SIP via facilities provided by the exchange.

However, even with these different starting points, combined with various in-house requirements, we are

seeking to build a system by which it will be possible to connect an institution to UNINETT’s SIP

infrastructure either in its entirety or by means of a gradual migration process. This can be achieved by

establishing an external unit which “homogenises” the link to the SIP infrastructure. In the diagram, this

unit is termed the “SIP PBX”. Depending on which type of PBX an institution has employed previously, this

will be connected to the “SIP PBX” either via a “Media Gateway” (MGW) or directly using SIP. The

institution in question can opt to add services such as call answering, calendar integration and telephone

conference services to one or more units termed “Services” in the diagram. It will also be possible to make

many different services accessible to clients linked to PBX via MGW and SIP PBX. The basic concept involves all telephone users being allocated an identity in “SIP PBX” written in the form

of the user’s own e-mail address. It will also be possible to reach all telephone users via the number used as

an SIP address. Persons with an SIP account will also be able to log on using their customary user name.

This will enable all users to be reached via an SIP address. How a call made to an address of this type is

processed will depend on the service in question. As far as possible, the institution in question will be able to select the software or equipment it wishes to

use. In other words, the institution will be able to select the type of SIP system it requires provided that it

supports the requisite standards and methods. It is worth noting that virtual machines are not suited for

use in telephony systems. Dedicated network cards with good quality drivers provide optimal functionality.

UNINETT will provide assistance with the installation and configuration of a basic package incorporating the

SIP PBX and Services modules and, if necessary, MGW based on open source code software.

In the diagram, a grey arrow located below the yellow and green boxes indicates the migration path. The

arrow symbolises the desired telephony technology development path within the institution. When an SIP

PBX is in place, perhaps also with a Services module, the way is clear for the institution to opt for either a

gradual or complete migration to a pure SIP-based system in which all clients make use of SIP. When all

users have SIP telephones it will no longer be necessary in many cases to operate an in-house exchange and

this can be phased out in the natural course of events. UNINETT will be able to support the operation and maintenance of the systems using SIP PBX, MGW and, in

part, the Service modules via a centralised administrative centre.


Page 6 of 36

UNINETT (underlying pale blue-shaded box) UNINETT will assume responsibility for administering key services such as DNS (SRV and ENUM) and, not

least, the service linking to the telephony provider. In the diagram, the latter is termed “TELEPHONY

MGW”. Centralised services are established where it makes sense to centralise management. It could also be that

there are institutions that are unable to administer their own local services such as call answering and

telephone conference facilities. In such cases there would be little or no technical difficulty in permitting

UNINETT to manage this as part of a centralised service.

DNS is a vital component of such an infrastructure. SRV is used to find the various servers that will handle

the services, while ENUM is employed to locate the number being called. DNS greatly simplifies the

practical administration of the infrastructure and ensures that the system is dynamic. DNS is already

established with satisfactory redundancy at several levels. The TELEPHONY MGW is also a vital component. All incoming calls from the telephony provider to the

institutions and all outgoing calls from the institutions to a telephone inaccessible directly via SIP will pass

through this service. In other words, all SIP PBX modules belonging to the institutions will establish this

service as the next jump address if the number being dialled is unavailable via SIP. The TELEPHONY MGW

represents a B2BUA (“MGW”) between the institutions and the telephony provider (PSTN). In other words,

it serves as the call’s termination point as seen from both parties. This means that everything, including

signalling and voice streams, is routed through this service. The diagrams below demonstrate how signalling is routed between parties under different sets of

circumstances.


Page 7 of 36

PSTN network

UNINETTInstitution A

Client SIP PBX

Institution B

Client SIP PBX

Institution C

Client PBX

Cell phones and hard lines on PSTN

Client

Connection with E.164 via TELEFON MGW

PSTN

TELEPHONY

MGW

The logic incorporated in the TELEPHONY MGW is designed to utilise ENUM. In other words, all calls to a

particular number are converted to E.164 format if they do not already exist as such, and are checked

against ENUM. In Norway, we can use the official ENUM tree e164.arpa. UNINETT is also able to make use

of the tree nrenum.net. Our goal here is to access only e164.arpa, and it is unfortunate having to waste

time searching through several trees. However, as long as we see that we have possible connections in

other trees, we must make a judgement as to whether any given tree should be included in the search. An

ENUM inquiry carried out in the TELEPHONY MGW is limited to e164.arpa and nrenum.net.

As a minimum requirement, all numbers to be routed in via the TELEPHONY MGW are stored in ENUM. An

institution may also opt to make itself accessible via ENUM even though the call is not routed from the

PSTN to the TELEPHONY MGW. In other words, other institutions that use ENUM actively will then take the

Internet route instead of calling via the PSTN. UNINETT will carry out the task of registering number series

on behalf of the institution as part of the process involved in linking the institution to the TELEPHONY

MGW. The use of the TELEPHONY MGW makes it possible to log all incoming and outgoing calls in a Call Detail

Recording (CDR) system, in which both incoming and outgoing numbers, together with the duration of a

call, can be stored. The CDR will be available to authorised personnel from the institution in question via a

web interface, and protected using FEIDE (an identity authentication system employed in the Norwegian HE

sector). Here it will be possible to limit searches in order to generate lists that can be used, for example, to

check itemised invoices from the telephony provider.

Security is vital to the TELEPHONY MGW for many reasons. It has protection against downtime, hacking and

unauthorised telephone use. It also provides security functions that will assist individual institutions in the

administration of their telephone use. The TELEPHONY MGW service is designed with optimal uptime in mind. In other words, redundancy has

been built in at several levels, both physical and logical. The diagram below illustrates the logical

construction of the service.


Page 8 of 36

Proxy

MGW

Proxy

MGW

UNINETT

SIP telephony provider(s)

Each TELEPHONY MGW host is equipped with redundant power supply and disk capacity. The servers run

each service (Proxy and MGW) on their own separate network card. If a set of services on one server should

be rendered inaccessible, the corresponding service on another server will be preferred automatically. This

prioritisation process will be achieved in part with the aid of weighted SRV records in the DNS. Technically,

the TELEPHONY MGW can work with external databases. However, in order to maintain uptime and the

shortest possible response/inquiry times, the databases are local and independent of other systems. The

databases are updated on a continuous basis across the units. Several TELEPHONY MGW hosts are located at different sites throughout Norway. By exploiting the

generous redundancy that UNINETT possesses within its network, combined with strategically located

units, it will require a major incident to render the TELEPHONY MGW service totally inaccessible. A

potential scenario involving a fully developed infrastructure may incorporate redundant hosts located in

Tromsø, Trondheim, Oslo and Bergen. Initially, there are redundant hosts established in Trondheim and

Oslo. It is prerequisite that the telephony provider also has the required redundancy within his own

network. A system of this type also provides an opportunity for regional load sharing and the consequent

exploitation of all available TELEPHONY MGW hosts.

It is difficult to safeguard against hacking, but we mitigate the risk by imposing restrictions on which IP

addresses are permitted to communicate with the unit. The use of router filters and iptables allows us to

impose restrictions that permit only welcome IP addresses or sub-networks to communicate with the

TELEPHONY MGW, and thus only with desirable ports. What is regarded as essential must be assessed on a

case-by-case basis. However, as a prerequisite, everything must be blocked with the exception of RTP and

SIP to and from those addresses at the institution which must be enabled to carry on a telephone call.

Similarly, a path must be cleared for the telephony provider’s contact point. It is possible to block other

addresses because it will not be relevant for external networks to use the TELEPHONY MGW. Legitimate

mobile users using other networks must make their telephony systems accessible by means of local

systems such as VPN or a B2BUA, combined with additional safeguards provided by the institution in

question. Having been made aware of the risk and consequences, the individual institutions must then

assume responsibility for selecting the addresses that can be permitted to utilise the TELEPHONY MGW.

This is because any misuse will result in financial consequences for the institution affected. Administration

of the CDR is carried out via an independent web server.


Page 9 of 36

Unauthorised telephony use can rapidly develop into a very expensive consequence of inadequate

protection against hacking or false servers. It does not help to safeguard the TELEPHONY MGW against

hacking if the problem is that the institution in question has permitted authorised users to make numerous

and expensive calls in the first place. Restrictions on the IP addresses that are permitted to utilise the

TELEPHONY MGW will greatly mitigate this problem by restricting the permitted sources of the calls.

However, the local SIP PBX may also be subject to hacking, or misuse may be traced to an internal source,

such as via a hacked PC. We require “fraud detection” systems to tackle these problems. The CDR provides

us with a chronological record of calls. Based on this we can design procedures that search for a call

pattern. If such a pattern is detected, managers responsible at the institution in question can be alerted.

Illustrations of this are situations such as in which one and the same number exceeds its prescribed cost

limit, an abnormally large number of calls made within a given period of time, total exclusion of all calls to a

given country, or alert notifications if cumulative call costs exceed budgetary limits, etc. This can be

administered by the individual institution via a web interface protected using FEIDE. Underlying systems

employ module-based procedures to monitor status and flag hits for further processing and subsequent

response. A minimum set of regulations will be established as standard, accompanied by notifications to

local managers. The use of blocking and filters in the TELEPHONY MGW must be viewed as a last resort as a means of

preventing expensive misuse and for maintaining control of telephony usage. The local SIP PBX module has

the task of enforcing the principal rules governing how calls shall be handled and, if necessary, of restricting

accessibility to and from certain numbers. In the longer term, a TELEPHONY MGW may play an important role in dealing with several telephony

providers simultaneously. One possibility is that the system of agreements will give the institutions the

opportunity to choose their telephony provider according to where one wishes to call. For example, it may

be the case that provider A is preferable for domestic calls, whereas provider B is best for international

calls. It may also be the case that an institution may enter into agreements regarding mobile telephony by

which it utilises different telephony providers depending on which operator the number is located at. A

TELEPHONY MGW will permit such processes to be administered seamlessly for both the institution and the

user.


Page 10 of 36

Internet (grey-shaded, underlying box) Beyond the boundaries of UNINETT an ever-increasing number of SIP-based clients are appearing who will

want to communicate with clients within our infrastructure without having to go through the telephone

network. The use of DNS with ENUM will make them easy to reach and be reached. This will occur

seamlessly for those clients possessing a similar infrastructure to ours, and will not require the user to take

any action. The exception will be if the institution starts to use SIP URI for input in preference to a

telephone number. The PSTN is the telephony provider. There may be several such providers in operation simultaneously, all

offering the most attractive prices for their preferred services such as domestic telephony, mobile

telephony and international calls. The PSTN will be located on its own IP network. We must make it a

requirement that they are equipped with the necessary quality and redundancy within their networks in

order to meet our needs.


Page 11 of 36

2. Migration

The transition from PBX to SIP PBX can be carried out gradually by means of a migration process. It will be

up to each individual institution to determine how rapidly this process will be carried out, and it is not

necessary that all stages must be strictly adhered to. An institution may choose to omit certain stages. In most cases, the migration process will extend over a period of several years. Much of the work is

involved in the planning, facilitation and establishment of the basic components within the organisation.

Following this, the institution will follow an adaptive process leading to the ultimate phasing-out of the old

PBX. An important objective of the process is that the users will remain unaware that the transition is

taking place. However, it could be advantageous if the user is made aware of the expansion in

opportunities that the new technology provides, including the new range of services. It is also important

that the institution gives all details its full consideration and does not underestimate the time it may take to

get the minor details in place.

UNINETT will provide assistance in facilitating the migration so that the process is carried out as smoothly

as possible, while providing local management and technical personnel with the necessary training which

will allow them to continue with future operations and maintenance.

The components The basic and most vital component of a new local SIP infrastructure is the “SIP PBX” entity. It is the SIP

router that monitors incoming and outgoing calls, and acts as a registrar for SIP users. The ultimate

objective is that all telephony users will be linked to this using an SIP telephone.

Another important entity is the “MGW”. This provides the link between the SIP world and the local

telephony system.

Finally, we have the “Services” entity, which facilitates local services such as call answering, a conference

system, automated telephony notifications, calendar integration, etc. The diagram below illustrates how these entities are linked within a given institution.

In practice, and in very many cases, these entities are integrated and run on one and the same host.


Page 12 of 36

Migration options As noted previously, an important objective of the migration process is that the user will experience as little

disturbance as possible. In order to provide an impression of how a migration process evolves in practice,

the following provides a summary of two possible scenarios we have at our disposal in order to achieve this

aim. Since there are a wide range of possibilities, there may be several variations on these themes. At some

stage during the process the institution must decide whether or not the user will be provided with an SIP

telephone and if so, when. Alternatively, the institution may decide that he will retain his existing

telephone. A – Retain PBX telephone for as long as possible B – Switch to SIP telephone as soon as possible 1. Starting point

2. Phasing-in of SIP PBX, MGW and Services

A3. Change routing for outgoing calls

A4. Port number to SIP

A5. Replace telephone

6. Remove MGW and PBX, cancel ISDN

1. Starting point

2. Phasing-in of SIP PBX, MGW and Services

B3. Replace telephone

B4. Change routing for outgoing calls

B5. Port number to SIP

6. Remove MGW and PBX, cancel ISDN 1. Starting point Initially, the institution is most probably equipped with a local PBX and its appurtenant telephones. PBX

may be supplied by manufacturers such as Alcatel, Ericsson, Nortel or Cisco. All calls to other local

telephones will be routed either via PBX or directly between telephones, although PBX will administer the

calls. Calls using PSTN (“exchange line calls”) are routed either via ISDN (PRI) or SIP using PBX as a gateway.

2. Phasing-in of SIP PBX, MGW and Services If SIP PBX and MGW are in place, the institution is accessible via SIP over the Internet. In such cases, the

institution will immediately have access to a range of possibilities, even before it has established a single

SIP user, and without causing any practical changes to the way in which existing users use the system.

• The institution’s telephony users can be allocated an SIP address (SIP URI), taking the form of an e-

mail address, and thus become accessible via the Internet. • The institution’s telephone number can be registered in ENUM and be linked to the fixed

telephones on the PBX. A consequence of this is that all institutions that utilise ENUM for outgoing

calls will assume that it is working. If this is not the case, they will not be able to get through. • The institution’s telephony users can be set up so that they can call out via ENUM and the Internet

in situations where this is available, if necessary by using a direct inward dialling number. • If the “Services” module is also implemented, the institution’s telephony users will be able to utilise

the services available. The number of the service from local number series is set up so as to be

routed out via MGW. Some institutions have set up their IP-capable telephones and/or PBX on an RFC 1918 network (private

network). Some PBX exchanges are able to link to SIP, but their implemented use of SIP is perhaps not

sufficiently compatible. The majority of PBX exchanges have only ISDN. In all these situations we


Page 13 of 36

recommend the use of MGW. This will then give the institution the opportunity to customise its connection

and at the same time standardise the exterior interface in a compatible form. Moreover, this will have the

additional benefit of leaving the existing PBX as undisturbed as possible. Calls to and from the PSTN will

continue as before.

MGW

SIP PBX Services

PSTN

provider

PBX

UNINETT

ISDN

SIP

A – Retain PBX telephones for as long as possible A3. Change routing for outgoing calls Even with a telephone linked to a PBX it will still be possible to redirect call routing for one or more

telephones. Incoming calls arrive via ISDN and are routed onwards in the usual way. Outgoing calls are

directed to MGW and onward to the SIP PBX. At this point the SIP PBX must be connected to the

TELEPHONY MGW. This will make it possible to access exchange line calls via SIP. Neither local users nor call

recipients via the PSTN will notice any difference between this and a pure ISDN system. Nevertheless, the

local user will have taken a step further towards conversion to SIP. Calls to other numbers via PBX will be

processed by the PBX in the usual way.

PSTN

provider

MGW

SIP PBX Services

PSTN

provider

PBX

TELEPHONY

MGW

ISDN

SIP

PBX

A4. Port number to SIP When a user is ready to use the SIP path for outgoing calls, the time will have come to port the number

from ISDN to SIP. In practice this means that incoming calls will arrive via the TELEPHONY MGW instead of

the local ISDN. Technically, the porting process can be carried out one number at a time, but in practice it is

more convenient to port either in several larger batches (e.g., by selecting successive departments or


Page 14 of 36

number series), or all numbers at once. This process will appear to pass off seamlessly both for the institution’s users and those calling in. Calls will

arrive via ISDN right up until the moment at which the provider has carried out the port. At that moment

calls will then arrive via the TELEPHONY MGW. In practice, neither the caller nor the user will notice any

difference. As usual, the PBX will ensure that internal telephones are routed correctly.

A5. Replace telephone When both incoming and outgoing calls are routed via SIP, the institution can opt to allocate the user a

complete SIP account with all the possibilities that this provides, together with an SIP telephone. When the

process has reached this point, all other SIP-related preparations will be complete to the extent that the

only role that the PBX plays in reality is to act as a large “SIP adapter” for the older generation of

telephones. It is thus effectively superfluous. Unless his old telephone can be converted to SIP, the user will find a new telephone on his desk. Otherwise

the user will experience no change. Alternatively, the PBX may retain its role as an “SIP adapter” for some

telephones due to financial or practical considerations.

PSTN

provider

MGW

SIP PBX Services

PSTN

provider

PBX

TELEPHONY

MGW

SIP

SIP

B – Switch to SIP telephone as soon as possible B3. Replace telephone


Page 15 of 36

Once the SIP PBX and MGW are in place, the institution can opt to allocate the user a complete SIP account

with all the possibilities that this provides, together with an SIP telephone. The PBX will be configured to

forward all calls to the number in question to the MGW, which will in turn facilitate the correct routing to

the SIP PBX, and ultimately to the user. In the same way, all outgoing calls from the user can be configured

in the SIP PBX so as to be directed onward to the MGW which will then forward them to the PBX. The PBX

will in turn route them locally or send them to the PSTN provider over PRI. Apart from the new telephone, the user will experience no practical changes in his use of the system.

B4. Change routing for outgoing calls Incoming calls arrive via ISDN and are routed onwards in the usual way. Outgoing calls will de

directed to the SIP PBX. At this point the SIP PBX must be connected to the TELEPHONY MGW. This

will make it possible to access exchange line calls via SIP. Neither local users nor call recipients via

the PSTN will notice any difference between this and a pure ISDN system. Calls to other numbers

via the PBX will be processed by the MGW to the PBX.

PSTN

provider

MGW

SIP PBX Services

PSTN

provider

PBX

TELEPHONY

MGW

SIP

ISDN

SIP

B5. Port number to SIP This item will be almost identical to A2, with the exception of the starting point for the telephone

apparatus.


Page 16 of 36

PSTN

provider

MGW

SIP PBX Services

PSTN

provider

PBX

TELEPHONY

MGW

SIP

SIP

6. Remove MGW and PBX, cancel ISDN When all telephones are removed from the PBX, both the PBX and the MGW become superfluous and can

be removed. When the ISDN connection to the PSTN becomes redundant, it can either be cancelled or

reduced to a minimum in case the institution requires a local back-up function. A local PRI connection to a

PSTN provider can of course also be linked directly to the MGW so that the PBX is not needed for that

reason alone.

The practical experience gained from UNINETT's progressive introduction of an SIP infrastructure to the

various institutions will make a major contribution to enhancing our expertise. A document outlining

planning and implementation is being maintained by UNINETT in order to record such experience. This will

make the process for subsequent institutions somewhat easier. We refer to Annex C (page 30) for a more detailed 15-step description of the migration process.


Page 17 of 36

3. Services The term “services” in this context refers to facilities made available to users above and beyond standard

telephony services. The transference of telephony over to the IT domain opens the way immediately for a

range of opportunities to establish linkage to other systems. The institution can achieve this using an

interface with which existing users are already familiar. The following list is not exhaustive, but sets out some examples. In some cases it will be appropriate for

UNINETT to provide such services, whereas others will be better established locally. The following is a list of services described later in the chapter. This list is intended as reference material, and does not represent a priority ranking. 1. Call answering 2. Mobility 3. Enquiry/information services 4. Conference services 5. Web-based administration of own user/profile 6. Switchboard 7. Voice services 8. Click-2-Call 9. Enquiry routing of incoming calls 10. Student services 11. Emergency calls 12. Telephones for individuals with special needs 13. Callback when free 14. Alarm in the event of anomaly detection 1. Call answering Accessibility is an important issue in the field of telephony. If a call recipient cannot be reached, many

regard it as a useful service to be given information such as when the person in question will be expected

to return, and if necessary to be able to leave a message.

Using available software based on open source code, and by working together with an SIP PBX, this can

easily be implemented both for users with SIP clients and those linked to a co-operative PBX. The incoming

call can be routed to another destination after a predefined period if the call is not answered. If this other

destination is the call answering system, it will be possible, for example, to configure a generalised answer

for the organisation/department, and/or a personal answer for the individual in question. If required, it will

also be possible to set up a menu system for callers. The answer can also be formulated based on the result

of enquiries made to external systems, such as calendar systems, so that it will vary depending on the date,

and the status of the person being sought. If a message is left, this can be forwarded as an attachment in an

e-mail to the person in question. It is possible that UNINETT will establish a simplified and generalised call answering service which the

institutions can utilise. In other words, UNINETT will act as host for the technical system, while the

institution in question structures the service as a recipient for non-answered calls. However, each

institution will be able to install both general and personalised answers for the recipient in question.

2. Mobility One of the strengths of SIP is its ability to accompany the client between different IP networks. In many

cases this feature will in fact be rendered impossible due to the limitations of the network imposed by


Page 18 of 36

factors such as NAT, firewalls, other filters, and perhaps also configurations deliberately built in to the

server.

In practice, NAT and firewalls/filters function so that whereas calls go out, one hears nothing. It may also be

the case that the client fails to access the server in the first place. It can be argued that security will be

enhanced by placing restrictions on the locations from which users can register their accounts. Typically, we

may want only to be connected from approved IP addresses.

Thus in many cases, in order to re-establish mobility, we must set up an additional service for this purpose.

Such a service can be set up for the special handling of NAT and firewall traversing. This can be achieved

using additional safeguards for the user accounts which are perhaps not required under local

circumstances. Such additional security functions may incorporate a separate user name and password for

the mobile account in question, restrictions on the numbers that can be called, or a requirement to provide

a PIN-code when dialling invoiceable numbers. Additional requirements such as encryption can also be

prescribed. This mobility will be transparent to those calling the institution. Since this is a service that provides access to local resources and users of local funding (telephony

expenditure), it is natural that the responsibility for administration of the system will be assumed by the

institution in question. UNINETT will provide assistance in configuring the system and in preparing

operational procedures. 3. Enquiry/information services In situations involving connection to a number database, it will be possible to install automatically a “Caller

ID” containing the identity of both incoming and outgoing calls. As a result, the user will, for example, be

able to view the identity of the caller which will only be displayed in a call log, if such is available.

The source of this information may be a local database, such as a private telephone list retained by the user

himself or a subscription to an information service provider. It may also be a combination of these. An SIP PBX has the ability to make enquiries automatically for incoming calls. A solution may also be found

permitting the user to have his telephone equipped with a special button that makes enquiries as required

for both incoming calls and a call log. It is also possible that the institution does not restrict itself simply to

numbers and identities, but also that other information could be made available and forwarded to the

receiver as an e-mail or IM. Such a service will in the first instance be something that the institution in question has to offer in the light

of local practical considerations. However, UNINETT can also provide assistance in configuring these

services.

4. Conference services A multi-party telephone conference is a straightforward and free service that can be set up using open

source code software. Typically this is achieved by making certain fixed numbers available to callers who

wish to take part in a conference. These may be routed directly to a conference room or to a joint

“reception” facility. Calls to conference rooms may be directed to pre-defined conference numbers or

created dynamically. The conference rooms can also be password-protected.

The use of an IP-based conference system makes it possible to bring together callers using different

technologies. Callers using the traditional telephony network will be able to access the conference by

calling pre-defined telephone numbers. SIP users gain access via SIP to a dedicated address, such as

[email protected], and contact addresses can also be established for H.323 clients. It will not be

necessary to be a registered SIP user at a given organisation in order to take part in the conference. For

example, an individual can use a software-based SIP client in Person-to-Person mode and make a direct call

in order to join the conference. This will thus save foreign participants a great deal of money in telephone

expenses and is therefore an attractive service to be able to offer.


Page 19 of 36

It will be natural for UNINETT to set up a conference facility of this type for the HE sector. However, it

requires very little in terms of resources to establish such a service locally. 5. Web-based administration of own user/profile It will be relevant to set up a web-based service which will permit the individual user to modify aspects of

his account and telephony usage. The institution can choose to adopt an advanced or a simplified

approach. For example, web-based services can be protected by logging on to FEIDE in order to obtain a

personalised logging-on facility. Likely adjustable parameters and information to the user may include:

• Account information (user name, connection details, telephone number, description, etc.) • Password (change) • Status (Not logged on, Available, Engaged, Forwarded) • Forwarding (following a given number of rings, to which number, call answering service, etc.) • Last x calls in/out/not answered • List of the user’s own telephone expenditure • Calendar connection option (link to calendar information) • User’s own administration of call answering facility (notifications, status, etc.) • User’s administration of personalised telephone catalogue (Click-2-Call, Caller-ID enquiries

incoming and outgoing) This service may thus evolve into a “My page” facility which permits a user to find all the essential

information about his or her own personal telephony usage. UNINETT can be of assistance at the outset by

configuring tailor-made prototypes of such systems. 6. Switchboard The switchboard’s function is crucial because to those calling in it represents the organisation’s “outward

image”. It is anticipated that the switchboard will be set up so as to direct callers to the most suitable

destination, whether this be a given post within the organisation or a named individual. In other words, the

switchboard must have an overview of role and availability of those individuals whom it is possible to reach

by telephone. Moreover, it frequently serves as an information service provider. The requirements of a local switchboard will vary from institution to institution. Some switchboards will be

equipped with an automated voice menu system, e.g., in combination with group calling, whereas others

will employ a manned answering service where the staff will have full overview of the status of all calls. It is

important that the individual institutions draw up a specification of their requirements in terms of

switchboard facilities. For some this may involve a system similar to that which they currently employ.

Others will favour restructuring.

We must be aware that in contrast to the traditional PBX, SIP is a more distributed system in which it is no

straightforward matter to view status, monitor or gain access to calls. If such functions are included in the

requirements specifications, they must be given special consideration when setting up the local

infrastructure. A possible intermediate solution could involve the implementation of such special functions

for a particular group of telephones for which they are required, while the remaining users make use of the

standard SIP model. Straightforward functions such as the transfer of a call will give rise to no problems,

whereas functions such as callback to the exchange can be carried out, for example, by means of a call

answering service. It is possible to purchase complete off-the-shelf switchboard systems. Alternatively, it will be possible to

develop them oneself if the institution’s requirements are straightforward and few. This will be best


Page 20 of 36

resolved on a case-by-case basis, according to individual need. UNINETT can provide assistance in finding

the most appropriate solution. 7. Voice services The term voice services refers here to the variety of verbal messages conveyed to incoming callers. One

such system involves the caller pressing successive buttons as he works his way through an interactive

voice response (IVR) menu system. A voice service may provide information regarding general status and

results regarding examination grades, absence, the weather and traffic conditions.

Such services are closely related to voice mail and the conference system, and can be developed with the

aid of the same platform. It is possible that UNINETT could configure some of these services, whereas

others will be more specific to the institution in question. 8. Click-2-Call In many situations it will be practical for a user to be able to make a call simply by clicking on a number, e.g.

from a website. When the user clicks on the number the telephone will start ringing. When the user lifts the

receiver, the number clicked on is dialled.

This is convenient in situations such as where the caller wishes to ring a number that he or she has found

via an information service facility, website, etc. It can be implemented with the aid of a plug-in in popular

browsers, or configured with the aid of a special URL on dedicated web pages. This will be a local service, but UNINETT will be able to provide assistance with the technical aspects. 9. Enquiry routing of incoming calls For typical systems operations centres and such like, it may be practical that forms and databases displayed

on the screen of the call recipient can be interrogated automatically based on the number of the caller. In

such cases much may already be prepared before one answers.

Under certain criteria, an SIP PBX can be configured to call other systems. In this case, other systems may

consist of routines that forward the essential message to the call recipient’s machine, which in turn makes

the necessary enquiry.

Such systems will be specific to the institution in question, but UNINETT can provide technical assistance. 10. Student services Students can be provided with an SIP account based on the standard user account employed at the

institution in question. Such accounts can be restricted to the extent that they permit the user to make free

calls within the institution and to all other institutions connected to this infrastructure or to ENUM. For

example, such a system could be integrated with a pre-configured software-based client making it easy for

the student to use. Moreover, it will be possible to connect to other technologies for co-operation and IM.

Consider the situation in which the institution has a Jabber server linked to the SIP profile and the SIP client.

In this case the student would be able to gain access to all essential local resources by means of both voice

and IM using one and the same client. Relevant contact lists and IM groups can be made available

automatically to the individual user and be updated dynamically as required, perhaps also with a

connection to a personalised “My page” facility on the local web server. Systems of this type already exist and are in operation in other countries. 11. Emergency calls This is a basic function that can be configured in a variety of ways and under varying degrees of security.

For example, it is possible to route all emergency calls out on a local ISDN (a standard BRI subscription) if

the Internet connection is unavailable or if it is possible to permit all emergency calls to be routed to the

PSTN provider in the usual way. The PSTN provider is equipped with a connection between the number and


Page 21 of 36

address, and the PSTN provider is responsible for ensuring that this information is forwarded to the

emergency call. Experimental work is being carried out to establish integration between network information and

geographical location (as in GPS) in connection with SIP. In this way, detailed information about

geographical location can be directed to the nearest emergency services centre.

12. Telephones for individuals with special needs There exist a number of options and systems to cater for individuals with special needs. The ability to

connect the telephone to the Internet provides opportunities for systems that can be adapted to the

specific need in question, and which can be customised as required. Applications will include services such

as video phones (to facilitate sign language and lip-reading), Braille texting, induction loops adapted to

telephones, voice synthesis, etc. 13. Callback when free When the telephone you are calling is engaged, you can opt to let the telephone call you back automatically

when the person in question hangs up. Initially, your own telephone will ring. When you take the call the

telephone belonging to the person you are calling will ring. This is a handy function to have in connection

with the PSTN world and others with only a single available line. In the case of SIP users, there are several

“lines” and these are always “available”. In the world of SIP, the line will only become unavailable if the

user has logged off all of his clients. 14. Alarm in the event of anomaly detection Full control over call flow, combined with a good CDR, allows us to monitor call patterns. It will be possible

to set up functions that detect various patterns among the calls made, and by this means to discover

whether abnormal patterns are developing that we should be aware of. For example, we may wish to

investigate a situation in which a given number rings an international number on ten consecutive occasions

during a short period, and perhaps even block automatically the number in question. The manager

responsible might also consider setting up a system to detect and provide notifications in situations such as

where telephony expenditure limits are being approached.


Page 22 of 36

Annex A – A technical introduction to SIP This annex provides a high-level technical introduction to SIP, SRV and ENUM.

SIP Session Initiation Protocol (SIP) is an IETF RFC standard. There are over 100 RFCs related to SIP. It has been

said that “The nice thing about standards is that there are so many of them to choose from.” (Andrew S.

Tanenbaum) . Also in the case of SIP there are so many variants of the standard to choose from that

implementations become incompatible. This unfortunate consequence applies to both the equipment, like

the telephones, and software. Moreover, there are several products on the market which have in part

borrowed considerably from SIP, but which have been supplemented with their own components and have

thus in practice developed into proprietary systems. All this means is that it is important to ensure that the

products invested in function as anticipated. As an aid to both developers and users, some guidelines as to how to implement SIP have been drawn up.

• A Hitchhiker's Guide to the Session Initiation Protocol (SIP)

http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-05 This provides guidelines as to which RFC should be used for a given purpose.

• SIPConnect

http://www.sipforum.org/content/view/273/227/

This initiative was developed under the auspices of the SIP Forum with the aim of standardising the

way in which developers and manufacturers implement SIP in their products. They can boast an

extensive list of members among manufacturers and others, and have built up a considerable

influence in the SIP world. They also have produced the “SIPConnect Compliant Certification

Program” which serves to check for compatibility within the prescribed guidelines. From the end-

user perspective it is important to demand that both equipment and software adhere to the

specifications stipulated in SIPConnect. In addition, UNINETT has produced some draft technical specification (UFS) documents on the subject:

• UFS123 - Krav til telefoni-ruting i UH-sektoren (Telephony routing requirements in the HE sector) https://ow.feide.no/_media/gigacampus:ufs_123_-_utkast_1_-_krav_til_telefoni-ruting_i_uh-

sektoren.pdf (in Norwegian) • UFS124 - Krav til telefoni-tjenester i UH-sektoren (Telephony service requirements in the HE sector)

https://ow.feide.no/_media/gigacampus:ufs_124_krav_til_telefonitjenester_i_uh_sektoren.pdf (in

Norwegian) SIP is a signalling protocol that negotiates and establishes contact between units termed User Agents (UA).

The signal can pass directly between two UAs or it may be forwarded via a Proxy. This can also be facilitated

via stages in which a given unit terminates the connection at both ends by acting as a UA at each

termination (Back-to-back UA – B2BUA). If one is part of an organisation, it is normal practice to use a Proxy

so that one can obtain an address in the form of an e-mail address, such as <[email protected]>, for all

user accounts within the organisation. The users will then register with a Registrar which will usually also

monitor the user’s actual Location within the network. Without a Proxy and Location, the UA would have to

utilise an IP/Alias in order to establish contact. By using a Proxy in combination with a Registrar, it is also

possible to place restrictions on the use of certain services. For example, the organisation can require

identification and consent before expensive calls are made. A server incorporating a Proxy, Registrar and

Location will often be one and the same entity, particularly in smaller organisations.


Page 23 of 36

• User Agent (UA) – The location at which the communication terminates. Most commonly, this is

represented by the client utilised by a user. This may be software installed in a PC or a dedicated

telephone apparatus. • Proxy – handles the SIP routing. • Registrar – Authenticates and registers users. • Location – Monitors the locations within the IP network of the various registered UAs.

In this example, communication between the UAs is routed via a Proxy at both organisations, but on the

precondition that the UA has already been registered.

It is entirely possible to communicate with a UA that is not affiliated to an organisation, i.e. directly.

If one wishes to call a public exchange line it is simply a question of getting the Proxy to route the enquiry

to a service of this type, provided that the user has authorisation.

SIP also involves the facilitation of direct contact between the parties in communication. Once the UAs

have identified each other, the remainder of the SIP communication can be routed directly between them

without going via the Proxy. However, if one uses the “Strict Outbound Proxy” function, the users will be

obliged to communicate via the Proxy at all times. In some situations, this can have its advantages. This SIP protocol establishes the contact and negotiates possible modes of communication, but it is

important to note that it does not itself facilitate communication to and from the service that it has

negotiated. SIP serves simply to maintain the communication set up as a result of the negotiation. SIP

telephony is concerned with two separate RTP streams that pass to and fro directly between the UAs

involved. The port representing the destination negotiated in the SIP process can vary within a predefined

area within the UA in question. This factor is relevant when establishing firewalls and filters.


Page 24 of 36

This example illustrates how the RTP stream adopts a direct path between the UAs.

In situations where a B2BUA is in operation, this will terminate the RTP stream itself and then in turn

establish a new connection onward to the other UA. In a configuration of this type a B2BUA will also be

capable of acting both as Registrar and Location. This situation is commonly observed in configurations in

which we are focusing exclusively on telephony and wish to develop a system incorporating firewalls, etc. It

is important to note that a system such as this imposes heavy restrictions on the scope of application of SIP

and, if not utilised correctly, may inhibit the concept of development of a future-oriented system. SIP can operate over both UDP and TCP. However, UDP is the most common. RTP operates over UDP.

Whereas SIP has its fixed ports, the RTP ports may vary from time to time. No standard has been

established for the identity of these ports. However, a recommendation for a standard has been developed,

and the majority of products either has been, or can be, adapted to utilise the ports in question.

• 5060 UDP SIP signalling port

• 5061 TCP SIP signalling port

• 16384-16485 UDP primary RTP media stream

• 49152-49162 UDP alternative RTP media stream So far, this annex has described the pure SIP/RTP model which constitutes a vital component of the

infrastructure. In order to communicate with parties who do not use SIP/RTP, we must employ a translator,

termed a Media Gateway (MGW). In telephony, we generally find the MGW acting as an intermediary

between the organisation and the telephone exchanges (PBX and PSTN).


Page 25 of 36

In this configuration the Proxy ensures that the UA has the required authorisation to be able to

communicate with the MGW. The MGW will be perceived from one side as a UA acting as a termination

station for both SIP and RTP, but from the other side as having another form of connection, such as with an

ISDN system. This other connection may be achieved with a separate telephone exchange, or directly via

locally-subscribed ISDN lines. In the opposing direction, the MGW will facilitate a mechanism for finding out

to where a call sourced from a PBX/PSTN must be routed in order to reach the UA. An MGW is not

necessarily restricted to SIP/RTP and ISDN, but can also facilitate H.323, SCCP (Cisco’s “Skinny” VoIP

protocol) or analogue lines. An MGW thus makes it possible to link the one or several telephone exchanges required for SIP to function.

In other words, even if the equipment that one has fails to support SIP, it will still be possible to obtain a

form of SIP support on other types of telephones by forward placement of an MGW. In practice, the user

will not notice any difference except for an increase in the number of potential services.

It would be possible as part of an SIP infrastructure to configure static routing between all the Proxies, but

this is not scaleable and very cumbersome. For this reason, DNS serves as a vital support mechanism,

including for SIP in situations where one wants to develop other UAs and services.

NAPTR NAPTR posts (RFC 3403) define those protocols available for a service within a given domain. Making an

enquiry for an NAPTR post for the domain segment of the address in question enables us to obtain a

response regarding the protocols that are being supported. NAPTR posts appear in the form "domain-name TTL Class NAPTR order preference flags service regexp

target". For example: "organisation.no. IN NAPTR 60 50 "s" "SIP+D2U"" _sip._udp.organisation.no." In this context, D2U means UDP, and D2T means TCP. In addition, we have D2S which means STCP.

SRV SRV (RFC 2782) represents the next operation. If an NAPTR post exists, the client will know which protocols

are supported and on this basis will be able to locate the SRV. If no NAPTR posts exist, or if the NAPTR posts

are not in use, the client bases the search on enquiries to its own preferred protocols. As in the case of

NAPTR, the SRV is asked for the domain. The response should consist of the specific service address.

SRV posts appear in the form: "_Service._Proto.Name TTL Class SRV Priority Weight Port Target" For example: "_sip._udp.organisation.no 3600 IN SRV 10 10 5060 sip.organisation.no" In most cases, this address directs us to the organisation’s primary SIP proxy which in turn will, if relevant,

route the call onward to a destination within its organisation.

ENUM ENUM (RFC 3761) is the final important DNS component. ENUM represents an expansion of DNS and allows

us to look up numbers in E.164 format in order to see if they are available on the Internet.

NORID (the UNINETT-affiliated registration authority for the “.no” domain) has written more on E.164 and

ENUM.

http://www.norid.no/enum/ENUMfokus2005.html (in Norwegian) http://www.norid.no/enum/om_enum.html (in Norwegian) SIP.edu has prepared an ENUM “cookbook” in English: http://web.mit.edu/sip/sip.edu/dns.shtml


Page 26 of 36

ENUM is linked to the high level internationally-preferred e164.arpa domain. In Norway this domain still

has only trial status in anticipation of more extensive usage. However, there is nothing to prevent an

organisation registering in other ENUM trees. For UNINETT members, the nrenum.net domain is also

available and will enable an organisation to reach a number of other academic organisations across Europe.

In addition, e164.org is universally available. However, it is important that registered components are of

high quality, and this in turn is contingent on a well-administered registration system. It is also desirable to

restrict the number of trees to a minimum (preferably just one) because of the time it takes to process

enquiries. Even though this only takes a short time, the minimum requirement becomes critical if there are

several trees that require checking.

We look up a fully qualified E.164 number. This means that the country code must be included. For

example, the number to the switchboard at UNINETT is 73557900, but the fully qualified E.164 number is

+4773557900. In DNS we store a number or number series as a domain. The numbers are entered “in reverse” as is usual

when dealing with domains. $ORIGIN 9.7.5.5.3.7.7.4.e164.arpa. $TTL 86400 @ 3600 IN SOA biff.uninett.no. hostmaster.uninett.no. ( ; $Revision: 1.10 $ 2009010101 ; Serialnumber 28800 ; Refresh, 8 hrs 3600 ; Retry, 1 hr 604800 ; Expire, 1 week 86400 ) ; Minimum (& default) TTL, 1 day ; Name servers: NS biff.uninett.no. NS nn.uninett.no. ; ; Domain data: ; 0.0 NAPTR 10 10 "u" "sip+E2U" "!^\\+*(.*)$!sip:\\[email protected]!" . 0.0 NAPTR 20 10 "u" "smtp+E2U" "!^\\+*(.*)$!mailto:[email protected]!" . 1.0 NAPTR 10 10 "u" "E2U+SIP" "!^\\+*(.*)$!sip:\\[email protected]!" .

In order to start using ENUM an organisation must be allocated the DNS zones corresponding to the

number series that it uses. This is carried out either via the organisation’s register or via NORID in the usual

way. It is important not to start publishing ENUM information before the organisation is accessible at the

published contact addresses. There are several organisations around the world that utilise ENUM and

which expect that the contact information is functional.

We recommend that you do not register a user’s address directly associated with a given number in ENUM,

but rather that you register an Alias that is processed by an SIP Proxy. For example, associate the number

+4773557900 to [email protected] in preference to [email protected]. This results in easier

administration during updating in cases where the number is transferred to other use, and provides better

protection against mail address harvesting from DNS for undesirable purposes.


Page 27 of 36

Annex B – SIP and security This annex outlines some considerations surrounding the issue of security related to VoIP and telephony in

general. Under the broad term “security”, we include both system reliability and data protection.

Security We hear a great deal about security in connection with VoIP. Security is frequently an important issue

where telephony is concerned because such a service is crucial in terms of its operative reliability; it may be

sensitive in terms of its content and can be expensive in the event of misuse. For these reasons security in

relation to telephony is an issue that should be taken seriously. Where our focus in terms of security should be directed may vary greatly from organisation to organisation,

and perhaps also within different departments and groups within a given organisation. For this reason, the

individual organisation's requirements specifications must form the basis of security-related work. The first

step is to draw up a security policy. Using such documents as a starting point we can construct a telephone

system that meets the organisation’s requirements, accompanied by guidelines for its operation,

administration and status monitoring/surveillance. Security can be subdivided into two main categories:

1. System reliability – The ability of the service to function as we expect it to. Here we must establish

a list of all relevant contingencies and stipulate requirements in terms of how the system should

respond in the event that any of these eventualities should come to pass. Such contingencies may

include the following:

o Power failure o Cable failure o Equipment failure o System unavailability due to hacking or such like o Etc.

2. Data security, e.g., the extent to which the service is capable of protecting the information it

communicates, and of protecting itself against misuse/unauthorised use. Such contingencies may

include the following:

o Integrity o Confidentiality o Accountability o Etc.

Both categories have in common that the contingency may be directly linked to the telephony system or to

external circumstances, some of which are outside the control of the organisation in question, such as the

result of our dependence on external resources. The fact that it may not be possible to call anyone in

Denmark because all the physical connections to that country have been severed, is perhaps not the sort of

contingency that we can realistically expect to protect the system against. Frequently, security is

dependant on economic factors. For example, can the organisation manage with a single telephone

exchange, or should it install two to guarantee redundancy? Should the organisation employ a single fibre

optic link into the building or one on each side of the building? If local routers go down such that the

network connection is severed, will this have a practical impact on the telephony system, or are we so

dependant on the network connectivity that it doesn’t matter if the phones are also out of order? On the

issue of information security, one task could be to assess the consequences and risks of a potential

eavesdropping against the level of sensitivity of the content of the conversations.

We have mentioned previously guidelines for operation/administration and monitoring/surveillance. These

are important in order for us to be able to continue to meet the requirements set out in the specifications


Page 28 of 36

and security policy. During the system’s lifetime, changes will occur in internal and external circumstances

that may compromise the security of the system. Examples of such changes may include; a) it may be

desirable to undertake a regular revision of security measures, b) requirements related a given certification

or test of the clients, or c) a new version of client software that the organisation intends to install, etc.

When an organisation acquires a telephony system linked to a data network with all the opportunities that

this provides, it also obtains many possibilities for carrying out monitoring and surveillance of the user. In

such situations we can stipulate requirements such as notifications in the event of abnormal telephone

usage, for example, if a client suddenly calls an international premium rate number on three successive

occasions, the administrator will receive an e-mail. After ten occurrences, the user will be blocked. As noted previously, not all organisations have the same needs. For this reason it pays to draw up a realistic

plan suited to local circumstances. There may also be legal obligations which stipulate given requirements. So before an organisation tackles this problem, it is important to be aware that telephony security is not a

new issue that has arisen in the wake of VoIP. Security problems have existed ever since telephony was

invented. VoIP has the potential to resolve some of these problems, but may also give rise to some new

ones.

The following are some examples:

o Cable failure – This is just as likely to occur with a dedicated telephony cable as in a data cable. The

issue centres on whether we build redundancy into the cable or adopt an alternative means of

communication. o Power failure – Presumably, the telephony provider has UPS installed in his network, and it will

thus be irrelevant as to whether communication is via IP or ISDN. The local PBX probably also has

UPS installed, and we can of course also install this on systems on which VoIP relies. We can also

consider alternative means of communication. Be aware that only a minority of mobile telephone

antennas are installed with UPS. This means that in many places in Norway, the mobile telephone

network will be non-operational in the event of a power failure. o Denial of Service (DoS) – This phenomenon is not exclusive to the data network. Today, it is

possible using straightforward measures to carry out an effective DoS attack against any corporate

telephone network simply by continuously dialling all available numbers. SPIT (SPAM over

telephone) is also independent of the telephone technology that the organisation employs. In the

past, such attacks were unlikely because it was expensive for the caller. Today, the combined use of

hacked exchanges and IP telephony makes it possible to carry this out from abroad. o Hacking of the telephone exchange – We can distinguish between direct hacking of a telephone

exchange that has installed an administration interface over IP, and the exploitation of weaknesses

in the technology or configuration. Many modern PBX systems have an administration interface on

IP even though the system itself does not utilise VoIP. We have observed cases of this type of

hacking, as a result of which an organisation may become vulnerable to eavesdropping and/or

misuse. We started already to observe the exploitation of weaknesses in the technology in the early

1970’s with the “Captain Crunch” phone phreaking phenomenon, and later with the more

widespread “Blueboxing”. It remains a relevant issue that third parties, with the aid of a modem

and DTMF, will search for weaknesses in the configuration of a telephony system in order to tap

lines that were not intended for outside access.

o Eavesdropping – In the past as now, parties intent on listening in are reliant either on establishing

a connection to a cable that transmits voice traffic or on hacking into a telephone exchange. In the

case of analogue lines this can be achieved simply by connecting a tape recorder directly to the

cable. In the case of ISDN the process requires a little more sophisticated equipment and skill, but is

far from difficult. In the case of VoIP it is necessary to “sniff” the network in question and then

interpret the data stream. This is also seldom a difficult task. Fortunately, VoIP gives an

organisation the possibility of encryption, if necessary.

o Social Engineering – This is a commonly underrated source of risk that seldom has any direct

relationship to technology. In some situations, the easiest way of obtaining sensitive information is

simply to ask for it.


Page 29 of 36

One argument against transferring telephony “online” is that from enjoying “security through obscurity” by

employing systems that required specialist insight, we are now entering a world in which many others have

the skills and expertise to carry out unwanted interference. The Internet permits unauthorised persons to

probe systems for weaknesses rapidly, simply and in practice without legal consequences. DoS is not an

unknown phenomenon in the Internet world, and it can be a challenge to protect the traffic flow from

manipulation and eavesdropping. On the other hand, we can benefit from a redundancy and the

monitoring technology in our own network that perhaps exceed those of the telephony provider. Tools for

mutual authentication and encryption may make it possible to protect against misuse, manipulation and

eavesdropping. At the very least we gain access to testing, administration and monitoring tools that can

respond rapidly in situations where something unusual occurs.


Page 30 of 36

Annex C – The migration process, step by step In order to implement the process in practice, it is useful to have carried out a little preparatory work

beforehand, and to have drawn up a plan for the process itself. The following represents a suggestion for

such a process plan. In collaboration with pilot organisations, UNINETT will combine theory with practice and, in the course of

the work, gain experience that will result in a migration plan that will be better and more thorough than

that presented in this document. List of items 1. Evaluation and documentation of the existing telephony system 2. Establishment of the SIP PBX 3. Establishment of the MGW 4. Establishment of “Services” 5. Connection to the TELEPHONY MGW using trial numbers 6. Establishment of a SIP user database for testing 7. Establish trial clients 8. Testing of local infrastructure (all paths) 9. Establishment of a user database for all SIP users 10. Establishment of a provisioning service 11. Restructuring of a selected number of users for a trial period 12. Person-independent clients 13. Documentation/Specify roles 14. Put the infrastructure into operation 15. Phase-out PBX and MGW 1. Evaluation and documentation of the existing telephony system It is important to be aware of what the organisation currently has and how it works.

Documents:

• All numbers/series, the purpose for which these are used and, if necessary, their location. Offices,

meeting rooms, faxes, port telephones, lift telephones, etc. • Type and number of telephones. • Type of PBX, software version and appurtenant equipment. • Call groups and special numbers. • How the switchboard is employed in practice. • Specialised systems.

With the support of this documentation we will draw up a list of telephony-related specifications for the

new system. In some situations this will involve a duplication of existing functionality. In others we may

discard functionalities that are either little used or not used at all or, in some cases, add a new and

desirable functionality. We must expect that this process will take some time. An absence of items from the list may result in

complications and additional loss of time at later stages in the process. 2. Establishment of the SIP PBX This is the core of the local infrastructure. There is nothing to prevent this from being in place at an early

stage, and the work involved will be a continuous process. It is important to select good quality hardware

that provides the required level of redundancy and which can handle the volume of UDP traffic in a


Page 31 of 36

satisfactory manner. In principle, this will consist of a PC with a minimum of one network card. We

recommend an Ubuntu Server 8.04LTE as the operative system, and OpenSER/KAMAILIO as the SIP Proxy.

At the outset this must be equipped with a basic configuration for handling call routing and user

registration, i.e., connection to a user database. In connection with call routing, restrictions will be imposed

as required regarding which numbers the users will and will not be permitted to call.

Security must be handled with the aid of the protection of the OS and the installation of essential filters in

iptables and/or routers. 3. Establishment of the MGW A media gateway must be located between the SIP PBX and the local PBX. This is one or several hosts each

installed with one or several PRI cards that are connected to PRI cards in PBX. These are connected at the

other end to the SIP PBX via IP. Instead of PRI, an MGW can also utilise SIP to communicate with the PBX.

An assessment must be made on a case-by-case basis as to whether this is dedicated hardware or whether

the MGW host can be identical to the SIP PBX host. Smaller institutions may benefit from combining these,

whereas larger organisations ought to separate them. Beyond this, we recommend use of Asterisk and a

Digium PRI card, which is well supported in Asterisk.

The MGW is set up to forward incoming calls from the one side to the other and by so doing keep the

complexity in the configuration to a minimum. The call routing itself is the task of the SIP PBX

For its part PBX must be configured with the essential basic PRI card to enable connection to the MGW. The

configuration can be arranged in such a way that all calls that are not intended to be forwarded to another

PBX-connected telephone are routed out on the PRI connection. Incoming calls to the PBX via the PRI

connection will be routed only to those telephones that are connected to the PBX. In practice we can say

that the combination of the MGW and the PBX acts as a large SIP conversion unit (Analog Telephone

Adapter - ATA) for units that do not handle SIP. Note of course that this configuration cannot be

implemented before the SIP PBX is connected to the TELEPHONY MGW, and the telephony provider has

rerouted the organisation’s number so that it can be connected over SIP to the TELEPHONY MGW. During a

test phase it will be possible in the PBX to select specific numbers that will be routed out via the MGW. In some cases this will involve a PBX that can handle SIP. In such cases it may be possible to omit the MGW.

However, this must be tested on a case-by-case basis. Not all providers’ SIP are handled in the desired

fashion. 4. Establishment of “Services” In those cases where we wish to establish local telephony services, we can start to do this in parallel with

configuration of the SIP PBX. Typical basic services include call answering and telephone conference

services. Beyond this, local requirements and the organisation’s creativity will determine which other

services are included.

This may involve one or several machines, or in some cases a separate process configured on the SIP PBX.

This will be determined by local conditions and preferences. We recommend the use of Asterisk as a service

platform since this represents a termination station with great expansion potential.

Provided that we have an SIP PBX to route the calls, it will be possible to make services available both to SIP

users and the users of standard telephones.

5. Connection to TELEPHONY MGW using trial numbers With an SIP PBX in place, it will be possible with assistance from UNINETT to establish some trial numbers


Page 32 of 36

and a connection with the TELEPHONY MGW. This will entail a minor configuration of the TELEPHONY

MGW, SIP PBX and filters in order that the parties in question will recognise each other. This is the first phase involved in testing that the infrastructure is working satisfactorily. 6. Establishment of a SIP user database for testing In order to be enable it to authenticate and monitor legitimate users, the SIP PBX must be provided with a

user data base.

At the outset it may be wise to use some fictitious trial users linked to the trial numbers routed through the

TELEPHONY MGW. Such users can be made the subject of experiment in order to see if the systems

respond as expected. This represents the second phase in the testing of the infrastructure. 7. Establish trial clients In order run a satisfactory test of the infrastructure, we require a selection of relevant clients in order to

test registration and use of telephony services over SIP. Examples of relevant clients may include various

types of desktop telephones, wireless telephones, mobile telephones with SIP and software-based clients.

These clients must be able to register themselves with the test user over the SIP PBX from the desired IP

sub-network, and be able to communicate using RTP with other SIP clients both within and outside the

organisation, and with the TELEPHONY MGW. This represents the third phase in the testing of the infrastructure. 8. Testing of local infrastructure (all paths) During the final phase of testing we make use of a combination of established test users, users from PBX

and external telephone numbers (such as mobile telephones) in order to test that the infrastructure is

working as intended along all paths and that services are also functioning as intended. 9. Establishment of a user database for all SIP users When the infrastructure is tested and is functioning satisfactorily, we will be able to establish a definitive

user database for all SIP users. This database should act as a source of user data to use as a basis for the subsequent addition of essential

supplementary information. At the outset users can be generated automatically, e.g. by utilising a previously established user name in

combination with an automatically generated password of appropriate complexity. BAS is an example of

such a source. For the purposes of subsequent administration and maintenance, we might consider a

website protected using FEIDE, where the individual user can log on and modify parameters such as call

transfer, the time elapse prior to activation of the call answering service, or the generation of new client

passwords, etc.

As a minimum requirement, all users should employ user names that are already established, but

accompanied by two Aliases in the form of an e-mail address and telephone number.

For example:

User name: [email protected] Alias 1: [email protected] Alias 2: [email protected]

The password should be at least 12 characters in length, use alphanumeric characters only, and should

include a mixture of small and large case characters. For security reasons the user should not be given the

opportunity to generate these passwords. Nor should the password be used by other systems.


Page 33 of 36

All of the institution’s telephone users can be registered in this database – even those connected to the old

PBX. The SIP PBX will thus ensure that even the older telephones will be accessible over SIP, and that their

users will be able to benefit from many of the services. In the user database, users must also be generated for telephones that are not linked to a particular

individual. Such users will include conference room telephones, reception, port telephones, fax machines,

etc. As SIP clients they should be allocated a user name and password, together with an alias which makes

it easy to locate them via SIP. For example: User name: [email protected] Alias 1: [email protected] Alias 2: [email protected] Such users must be given special administrative consideration by the appropriate technical staff.

10. Establishment of a provisioning service Provisioning involves the automatic establishment and configuration of a client. Optimal establishment of a

provisioning service can result in considerably easier administration. Ideally it will be possible to plug a

telephone straight from the factory directly into the network socket and get it automatically configured and

made ready for the user. Different telephones have different ways of achieving this. Consequently, the methods and procedures

involved will vary depending on the make and model of telephone. Based on the switchport the telephone

is allocated, or the telephone’s MAC address (which is most likely marked on the telephone itself and/or its

box), it will be possible in combination with user information in the user database to customise an

automatic configuration using the desired parameters. In other words, an evaluation must be made as to how a user will be linked to a given client. For example, it

will be possible to adopt a system whereby the client itself is registered as a separate entity and where the

user via the telephone itself is able to register or de-register using the telephone in question. Alternatively

there are systems whereby the user is registered directly via the telephone. Several variations on this

theme may be considered depending on the wishes and needs of the institution in question. 11. Restructuring of a selected number of users for a trial period During a transitional period it will be appropriate to try out the new system using a small group of

individuals who can provide feedback as to how the system is functioning. In spite of prior testing there are

many places where defects might be hidden away. Some such defects will only show themselves when the

system has been made fully operational. An organisation should be aware of the following issues:

• Can the users register themselves on the SIP server? (User database/configuration) • Filters that prevent free movement for RTP (Typically unidirectional voice stream) • Numbers that cannot be reached when an individual rings out. (Is the numbering plan configured

correctly? MGW? ENUM?) • Numbers that cannot be reached when an individual rings in (Is the numbering plan configured

correctly? MGW? ENUM?) • “Noise” on the line, poor sound quality? Echo? Noticeable sound delay? (Capacity problems in the

network? Correct codec selection? Echo cancellation?) • Are all the configured services functioning? • Is the call maintained throughout, or is it interrupted after a certain time has elapsed? • Are the security measures working? Is it possible to call a prohibited number? Are the filters and

warnings activated if pre-set threshold values are exceeded?


Page 34 of 36

Hopefully, in this way it should be possible to identify and rectify the majority of defects before embarking

on the operational phase. 12. Person-independent clients Very many telephones and telephone numbers are linked to a given individual occupying a predetermined

role. As a rule, these are easy to relate to because the individual in question may be allocated an account

and a telephone registered on the basis of his or her identity. However, it is not unusual to encounter

telephones that have a more general or specific role quite unconnected with a particular individual. Finding

an SIP replacement in such cases is far from trivial. It is therefore important that the institution reviews all

these telephony systems to find one that is optimal in each individual case. The following list is not exhaustive, but is intended to provide some examples:

• Meeting/conference rooms – May commonly employ a standard SIP desktop telephone, but linked

to a "meeting room" user. • Reception – This generally involves a somewhat specialised telephone system with several lines and

devices that provide indications of the status of other lines. Reception systems may also be

intended to function in connection with an application or exclusively as an application (softphone).

Functions such as the transferring, forwarding, monitoring, etc. of calls may be important. Such

needs may be assessed on a case by case basis in order to find the most suitable system. • FAX – FAX over SIP using ATA or an alternative system employing FAX over Internet. • Port telephone – Probably analogue. Can be replaced with a pure SIP system or connected via an

ATA. • Lift telephone – Probably analogue. Can be replaced with a pure SIP system or connected via an

ATA. 13. Documentation/Specify roles Documentation of the system is vital to its future operation. It is a useful tool during troubleshooting,

training and future development. It is equally important to revise the documentation when changes are

made. Operational documentation is required for the administration of day-to-day operations. For example, which

systems should be up and running? What is the procedure for installing a new telephone? What is the

procedure for transferring a user from PBX to SIP? What is the procedure for integrating updated versions

into the system? Who should be contacted to carry out a specific task? It is also important to make clear who has responsibility for the different technological aspects of the

system, so that enquiries can be dealt with and action taken as efficiently and economically as possible. Nor should the users of the system be forgotten. Most people can manage to use a telephone. However, a

little more insight may be required to utilise all of the possibilities that SIP provides. Special functions such

as reception services will most likely require extensive training. Websites with “help to self-help” functions

may also be a useful tool. 14. Put the infrastructure into operation When the documentation is in order and practical pilot user trial projects have proved to be satisfactory,

the system is ready to change its status and become fully operational. From this point on it will be possible to transfer users from the old PBX to SIP at the tempo required by the

organisation in question. User training will be a continuous process. Administration is carried out in accordance with the documentation which is revised and modified as and

when required.


Page 35 of 36

15. Phase-out PBX and MGW As a natural consequence of the fact that all telephones and users have migrated from PBX to SIP, the PBX

can be phased-out together with the MGW.


Page 36 of 36

Abbreviations ATA Analogue Telephone Adapter. A unit that serves as an SIP UA at one end and as an

analogue telephone connection at the other. Ensures that analogue telephones can utilise

SIP. Can also be used for FAX. There are also ways of connecting to ISDN telephones, such

as via an ISDN-card in a standard PC. B2BUA Back-2-Back User Agent. An “end station” (sender/receiver) in SIP terminology is a User

Agent. When we refer to a B2BUA we are dealing with a more or less “invisible” bridge

between two other parties, but which in technical terms looks like the respective parties’

call partner. Both the SIP and RTP streams are channelled through a B2BUA. CDR Call Detail Record – a description of calls made, including information such as source,

destination, time and date, duration, etc. ENUM Registration of telephone numbers in E164 format in a DNS making it possible to resolve

the number to an SIP URI if this is available. MGW Media GateWay. Functions most often as a link and «translator» between two different

communications technologies. An MGW can also function as a portal where one can exert

full control over the call traffic passing through it. This also includes the voice stream itself. PBX Private Branch Exchange. A term describing a privately-owned telephone exchange/in-

house exchange. Traditionally, this describes a unit where the physical connections of an

organisation’s telephones are housed. A PBX communicates with a PSTN via an interface

such as PRI. PRI Primary Rate Interface. A telecommunications standard for carriers of multiple voice

and/or data channels in the form of ISDN (64 Kbps). A PRI is most often connected to an E1

connection at 2.048 Mbps, which in Norway provides us with 30 B channels (ISDN

voice/data) and a single D channel (control) in PRI. PSTN Public Switched Telephone Network. A term describing the global (for the most part

digital) telephony network that consists of fixed and mobile telephones. RTP Real-Time Transport Protocol. A term used to describe the data stream making up an SIP

call. There is one RTP for each direction between the parties in question. SIP Session Initiation Protocol. A collection of IETF RFC standards that describe person-to-

person signalling. In this context SIP most often establishes a direct voice and/or video

stream between the parties in question (SIP UA). SIP Proxy May also be termed an SIP router. SIP Registrar A service enabling a UA to authenticate itself and make a connection within a SIP domain. SIP UA SIP User Agent. An agent that can be regarded as the client or the “telephone apparatus”

in the SIP world. SIP URI SIP Uniform Resource Identifier. An address in SIP format, e.g. SIP:[email protected]