How to scope an IPT and unified communications project for RFP

How to scope an IPT and unified communications
project for RFP
Published: 12 December 2007
© 2007 SAS Global Communications Limited. Reproduction of this publication in any form without express
permission is forbidden. The information contained herein has been obtained from sources believed to be reliable.
SAS does not accept liability for errors, omissions or inadequacies in the information or its interpretation. The
opinions expressed in this document are based on judgements at the date of publication and are subject to change
without notice. All Rights Reserved.
Table of contents
Introduction ............................................................................................................................ 3
Glossary................................................................................................................................. 3
RFP prerequisites .................................................................................................................. 4
IP infrastructure audit ............................................................................................................. 4
Traffic planning study ............................................................................................................. 5
Project team configuration ..................................................................................................... 6
Architecture options ............................................................................................................... 7
Single site centralised cluster ............................................................................................ 7
Multi-site centralised cluster .............................................................................................. 8
Multi-site decentralised ...................................................................................................... 9
Home and mobile working solutions ...................................................................................... 9
Key components of a successful IPT and unified communications RFP .............................. 11
Global standards .................................................................................................................. 11
IP fundamentals; how will the IP sub-netting work? ........................................................ 11
Manufacturer market penetration; is support readily available? ...................................... 11
Vendor choice; does resource match the business footprint? ......................................... 11
Carrier and communications availability; is the global footprint adequate? ..................... 11
Application standards; are they consistent at all points? ................................................. 11
Standard system configuration; is the interpretation of the architecture consistent? ....... 12
Global SLAs; can they be globally coordinated? ............................................................. 12
PBX interoperability with existing PBX and IT systems ........................................................ 12
Fixed mobile convergence and IPT handsets ...................................................................... 13
Existing infrastructure integration and re-use ....................................................................... 14
Communications consolidation ............................................................................................ 15
Failover and business continuity .......................................................................................... 16
Proof of concept ................................................................................................................... 16
IPT readiness and voice path validation............................................................................... 17
Testing and approval process .............................................................................................. 18
SLAs - infrastructure support ............................................................................................... 19
Extended maintenance services .......................................................................................... 20
Conclusion ........................................................................................................................... 21
About SAS ........................................................................................................................... 22
List of Figures
Figure 1-1 IP infrastructure audit - discovery and documentation .......................................... 4
Figure 1-2 Traffic planning study ........................................................................................... 5
Figure 1-3 Single site centralised cluster, with a centralised admin and control .................... 7
Figure 1-4 Multi-site centralised cluster ................................................................................. 8
Figure 1-5 Multi-site decentralised ......................................................................................... 9
Figure 1-6 Home and mobile working solutions ................................................................... 10
Figure 1-7 PBX interoperability with existing PBX and IT systems ...................................... 12
Figure 1-8 Communications consolidation ........................................................................... 15
Figure 1-9 Proof of concept ................................................................................................. 16
Figure 2-1 IPT readiness and voice path validation ............................................................. 17
Figure 2-2 IPT readiness and voice path validation ............................................................. 18
Figure 2-3 Testing and approval process............................................................................. 18
Figure 2-4 SLAs - infrastructure support .............................................................................. 19
Figure 2-5 Extended maintenance services ......................................................................... 20
Published: 12 December 2007
© SAS Global Communications Limited
Page 2 of 22
Introduction
The technical requirements of legacy PBX systems are not an adequate basis for
developing an RFP for IP telephony and unified communications.
IP telephony does not stand alone on the network; it has multiple interdependencies and it
interfaces with virtually every component within the infrastructure. Ignoring these
interdependencies is likely to affect call quality, ease of use and even the availability of the
system itself.
Companies planning to implement IP telephony and unified communications will need to
expand the scope of the project to review areas such as data requirements, LAN and WAN
upgrades, cabling and other physical site requirements, applications support and telephone
features.
This white paper offers a proven process for scoping IP telephony and unified
communications projects for an RFP.
It also highlights critical areas for review and integration, including areas which product
vendors may overlook because they fall outside the boundaries of the vendors’
responsibilities.
Glossary
IP SLA – IP service level agreement
IPT – IP telephony
Jitter – Variation in time by which an IP packet is delayed on the network
Latency – Time by which an IP packet is delayed on the network
MCS – Managed communication services
MOS – Mean opinion score
Packet loss – Percentage of packets unable to reach their destination
QoE – Quality of experience
QoS/CoS – Quality of service/Class of service (AF/EF standard)
SIP – Session initiation protocol
UC – Unified communications
UM - Unified messaging
VoIP – Voice over IP; analogue traffic converted to IP at the router
Published: 12 December 2007
© SAS Global Communications Limited
Page 3 of 22
RFP prerequisites
IP infrastructure audit
The IP infrastructure audit is an essential first stage in the development of an RFP for IP
telephony and/or unified communications.
The multiple interdependencies and interfaces the system has, with virtually every
component within the network infrastructure, cannot be ignored.
A comprehensive audit serves to prevent deployment of a poor or inadequate solution and
identifies areas that may require upgrading or modifying to support an IP telephony solution.
If these issues are not addressed at the commencement of the project they will simply result
in unanticipated costs in the future.
For these reasons the RFP should be expanded to include data requirements in addition to
other requirements which will be more self-evident, such as those relating to the site and the
telephony system itself.
Figure 1-1 IP infrastructure audit - discovery and documentation
WAN service
Carrier router
PSTN / BRI / PRI
Firewall
VPN
Voice gateway router
WAN router
Web server
Storage device
SAN
Default gateway
Application server
Printer
Switch gateway
Email server
Switch
WiFi switch
Work station
WIP phone
UM server
Call control server
Switch gateway
IP phone
Laptop
The components shown in Figure 1-1 are typical of those found within most infrastructures.
A comprehensive audit should document all key components, including all IP devices and
the way in which they are connected to the network, the structured cabling system into the
local area network switch infrastructure (shown in the second row up from bottom), the
server infrastructure (third row up) and then connectivity to the outside world.
If multiple sites are involved, the audit should include the wide area network connection
(top, far left) and voice network connection (top, far right).
Other key areas for the audit include the system deployed for wide area network
connectivity from any carrier (red circle, top left), Internet connectivity (red circle, top centre)
to remote users or third parties, and ISDN or PSTN analogue circuits (red circle, top right)
providing connectivity to the outside world.
Published: 12 December 2007
© SAS Global Communications Limited
Page 4 of 22
This latter area (external connectivity via analogue circuits) can often produce cost savings
when traditional analogue basic rate ISDN or primary rate ISDN circuits are managed and
routed through a smaller consolidated number of lines and circuits within the IPT and UC
solution.
In overall terms, a thorough understanding of the current IP infrastructure enables vendors
to assess requirements for enhancements, upgrades or modifications to the existing
network, to support the new system.
At the same time it provides an overview of external carrier connectivity, showing areas that
are either fit for purpose or can be modified to reduce costs, contributing to the return on
investment for the project.
Traffic planning study
As part of the audit process, a traffic planning study highlights the different components
involved within the network and how traffic routes across it, between sites.
A scenario typical of most company networks is illustrated in Figure 1-2
Figure 1-2 Traffic planning study
DSL or Fractional T1
PSTN
Catalyst switch
with
Secure LAN
features
Cisco voice-enabled
router
Catalyst
switch
with inline
power and
Secure
LAN
features
IP
WA
N
Internet
PSTN
Cisco distributed
CallManager
platform
Dedicated connection
DSL or Fractional T1
Teleworker/remote
access
Gigabit or 10/100
Ethernet
Main business
location
Catalyst switch
with Secure
LAN features
Cisco voice
application
servers
P
S
T
N
Corporate
servers
Desktops/lapto
ps with
third-party
anti-virus
software
Cisco IP
Phone
XML apps or
IPCC Express
agent
POTS phones
Cisco voice-enabled
router
with firewall and VPN
Branch office
DSL or Cable
Broadband
access modem
Laptops/desktops w/Cisco
VPN Client, Cisco Secure
Agent and PC-based
Softphone
Fax
Catalyst
switch
with inline
power and
Secure
LAN
features
Cisco IP
Phone
XML apps or
IPCC Express
agent
Desktops/laptops
with third-party
anti-virus software
It includes a main business location (at the top), a remote worker (bottom left) with basic
broadband Internet connection into head office, and a small branch office (shown bottom
right) with a number of users and a private MPLS connection back to head office.
With the voice path it is important to understand exactly how traffic will route across the
network once it is deployed, not as it currently exists but in the final design for the RFP.
The voice path is indicated by the eight red circles in Figure 1-2.
In this example, a call is initiated on an IP telephony handset at head office (red circle, top
right).
The requirement for IP telephony handsets, or whatever device is ultimately selected to
deliver the IPT solution to users is, therefore, immediately recognised.
Published: 12 December 2007
© SAS Global Communications Limited
Page 5 of 22
The call will then route through an edge switch (next red circle), where there will also be a
requirement for structured cabling, before it ends up at a core LAN switch, again requiring
structured cabling.
If the core LAN switch is located in the data centre, other specific considerations may have
to be taken into account.
Generally voice traffic is separated onto a dedicated VLAN in order to easily prioritise,
manage and monitor the voice IP packets.
Connectivity to the outside world is then through the wide area network router.
One of the key considerations highlighted by the traffic planning study, as summarised in
Figure 1-2, is the number of components involved within the voice path before the call is
even routed to the outside world; the fewer the better.
If the call is then handed off to a third party, it may go through the external PSTN dial
connectivity or, as shown in Figure 1-2, across the MPLS wide area network.
This places particular and specific operational demands on the MPLS network itself.
It will need to have expedited forwarding class of service (EF CoS) applied to ensure that
quality of service is maintained on the call whilst it is routed across the wide area network,
through to the wide area network router at the branch office.
From here, the call will go through another switch and on to a handset (the last two red
circles in the sequence).
One of the most revealing facets of the traffic planning study is that it shows how a simple
call from the main business location through to a branch office impacts numerous areas of
the network; all of which need to be analysed.
Ensuring that the analysis is effective depends on considering each particular business
profile; how calls route within the estate, and which components and devices they route
across.
This then facilitates an assessment of whether or not the components and devices are fit for
purpose as they are, can be upgraded or modified, or need to be replaced, in which case
they should be included in the RFP.
Project team configuration
When carrier connectivity as well as the internal infrastructure, and its constituent
components, have been fully understood and comprehensively documented, a project team
must be put together.
This team will be responsible for the development of the RFP and the review of proposed
solutions.
It should include, but by no means be limited to, employees of the business.
To ensure the broadest mix of expertise it should also include technical personnel from the
selected vendors and any other third parties responsible for the applications, network
infrastructure and external circuit connectivity.
Published: 12 December 2007
© SAS Global Communications Limited
Page 6 of 22
If external carrier connectivity is through a major carrier, that carrier should be represented
on the project team.
This not only ensures that the carrier is aware of any changes proposed, but serves to
expedite matters, since the carrier’s representatives can clarify infrastructure compatibility
issues as the project develops and help identify related areas that may need to be included
within the scope of the RFP.
The project team will be responsible for identifying the needs, and soliciting the input, of
each department within the business.
Whilst it should include representatives from IT, it is imperative that it is not allowed to
become the exclusive domain of the IT department; the main focus must be on the needs of
the business, not on the technical functionality in isolation.
To ensure the highest possible degree of business relevance and value, the requirements of
all departments must be explored and accommodated.
Finance, for example, may require call logging or billing functionality which is either not
available in the current system or simply has to replicate whatever functionality does exist in
the current system.
Project team configuration should represent a broad spectrum of interests and requirements
across the business, in terms of user interface and experience, departmental needs and,
from an IT perspective, the infrastructure required to deploy the solution.
Architecture options
With the team in place, the next stage is to decide which architecture option best fits the
business. Factors to be taken into account include the number of remote users and type of
office infrastructure; a head office with either no remote sites, a number of small remote
offices, or a number of evenly-sized branch offices.
Single site centralised cluster
Figure 1-3 Single site centralised cluster, with a centralised admin and control
CallManager
Cluster
PSTN
V
System IPCC
IV
R/I
S
N
AW
/H
DS
Admin
Control
ler
Agent
Signaling/CTI
IP Voice
TDM Voice
I
P
The first scenario is a single site centralised cluster, as shown in Figure 1-3.
Published: 12 December 2007
© SAS Global Communications Limited
Page 7 of 22
The ‘agents’ are shown at the bottom; these are the users connecting into the system,
through either an IP handset or a softphone running on a desk top.
The IP voice traffic will route through the network, centralised at the head office and only
having connectivity to the outside world when users specifically activate it, usually by
dialling 9 or 0 for an outside line.
This is the most basic, straightforward solution.
Where multiple offices are involved it is unlikely that such a scenario would prevail within the
network.
Multi-site centralised cluster
Figure 1-4 Multi-site centralised cluster
CallManager
Cluster
cluster
PSTN
System IPCC
central
controller
V
AW/HDS
Admin controller
PG/
CTI controller
Agent
IP/
IV
R
VoIP
WAN
Signaling/
CTI
IP Voice
TDM
Voice
A
ge
nt
I
P
A
ge
nt
I
P
The second scenario, the multi-site centralised cluster, is where there may be several small
remote sites with no requirement for large amounts of equipment.
It can be seen from Figure 1-4, that the set-up at head office is similar to the single site
centralised cluster, the key equipment being located at the head office; the call manager
cluster can be seen top right, and external connectivity through the PSTN dial network
(shown centre) is also through the central site.
The key difference, however, is the inclusion of a wide area network component (bottom
layer) connecting to routers and agents at a remote site.
This option is preferable when a number of smaller branch offices are included in the
network since it avoids the necessity for too many components at each remote site.
Equipment is concentrated at head office and remote connectivity is made available to
remote users.
Published: 12 December 2007
© SAS Global Communications Limited
Page 8 of 22
Multi-site decentralised
Figure 1-5 Multi-site decentralised
IPCC Enterprise
Central Controller
P
G
IPCC System PG
(CCM/IP-IVR)
AW/HDS
IVR
I
V
R
P
IPCC System PGG
(CCM/IP-IVR)
VoIP WAN
V
V
CallManager
Cluster 1
Signaling/CTI
IP Voice
TDM Voice
CallManager
Cluster 2
PSTN
A
ge
nt
I
P
A
ge
nt
I
P
The third scenario, multi-site decentralised architecture, is more complicated than the
previous two.
Two call manager clusters are shown in the example in Figure 1-5; one located at the
central site, on the left-hand side, and another set located on the right-hand side, the design
of the two sites creating a mirror image.
Both sites have PSTN connectivity to the outside world.
Wide area network connectivity is present between the two sites.
A multi-site decentralised architecture is preferable in a situation where there are similar
large offices requiring their own internal infrastructure.
It is also offers resilience.
Were one site to experience problems with remote connectivity to the PSTN dial network, it
would be able to route through the wide area network and out through the other site.
Home and mobile working solutions
With any of the foregoing architecture options, the needs of different types of remote users
coming into the network must be accommodated.
Figure 1-6 uses the same diagram featured earlier to illustrate the traffic planning study
(Figure 1-2).
If remote workers are equipped with softphones, the optimum mode of access will be
through WiFi access points coming in through the Internet.
Published: 12 December 2007
© SAS Global Communications Limited
Page 9 of 22
Figure 1-6 Home and mobile working solutions
DSL or Fractional T1
PSTN
Catalyst switch
with
Secure LAN
features
Cisco voice-enabled
router
Catalyst
switch
with inline
power and
Secure
LAN
features
IP WAN
PSTN
Internet
Cisco distributed
CallManager
platform
Dedicated connection
Gigabit or 10/100
Ethernet
Main business
location
Catalyst switch
with Secure
LAN features
Cisco voice
application
servers
PSTN
Corporate
servers
Desktops/lapto
ps with
third-party
anti-virus
software
Cisco IP
Phone
XML apps or
IPCC Express
agent
POTS phones
Cisco voice-enabled
router
with firewall and VPN
DSL or Fractional T1
Teleworker/remote
access
Branch office
DSL or Cable
Broadband
access modem
Laptops/desktops w/Cisco
VPN Client, Cisco Secure
Agent and PC-based
Softphone
Fax
Catalyst
switch
with inline
power and
Secure
LAN
features
Cisco IP
Phone
XML apps or
IPCC Express
agent
Desktops/laptops
with third-party
anti-virus software
This arrangement will have its own implication on head office Internet connectivity and how
the network is configured for quality of service.
Quality of service is not currently available across the Internet; user expectations, therefore,
must be carefully managed and consideration needs to be given to how best to support and
manage the system.
Published: 12 December 2007
© SAS Global Communications Limited
Page 10 of 22
Key components of a successful IPT and unified communications RFP
Global standards
One of the key areas to encompass within the scope of the RFP, when global offices are
involved, is that of global standards; how the system will impact all sites within the business.
There are basically seven key criteria to consider in the creation of a global standards
framework:
IP fundamentals; how will the IP sub-netting work?
When deployed across global sites, it may be the case that this will roll out using the same
network standards established for the head office.
However, some remote offices may have IP sub-net conflicts or related complications that
will need to be remedied prior to deployment.
Concerns might apply to a particular office or a particular region; addressing the IP
fundamentals at this early stage will enable them to be highlighted within the RFP to avoid
complications at a future time.
Manufacturer market penetration; is support readily available?
Whatever products are considered, it is critical that the vendors offer support in every
country or region in which the business has a presence.
A manufacturer may be strong in the UK and Europe, for example, but offer no availability in
Asia Pacific or North America.
Specific manufacturer selection against this criterion offers the possibility of reducing the
sub-set within the RFP by requesting only manufacturers whose support networks match
the business footprint.
Vendor choice; does resource match the business footprint?
Any third parties involved in deploying the solution must have the presence, or at least an
engineering resource, to fit with the business footprint, even if locations involved are
exclusively UK-based.
If different time zones are involved then the support and management offerings must also
reflect the business hours.
Carrier and communications availability; is the global footprint adequate?
Where an MPLS wide area network is deployed to connect to remote sites it must extend to
all sites within the business.
It is not an acceptable standard solution if only a limited number of sites connect in this way.
Application standards; are they consistent at all points?
If unified messaging and unified communications are deployed at head office, they should
also be deployed at remote sites. For example, it will be important to ensure that Microsoft
server systems share the same Active Directory and Exchange organisation to simplify UM
and UC deployment.
Published: 12 December 2007
© SAS Global Communications Limited
Page 11 of 22
Standard system configuration; is the interpretation of the architecture
consistent?
The system has to be deployed in a uniform fashion throughout the business; this facilitates
efficient and cost-effective user-support.
Different interpretations of the agreed architecture, in different office locations, will introduce
incompatibilities and additional costs at a later date.
Global SLAs; can they be globally coordinated?
In the case of multiple offices, spread across various territories, a decision has to be taken
as to whether or not separate in-country companies will be appointed to support the system.
The alternative is a single source; coordination and control through a central help desk.
Whatever arrangements are made for management and support, they will need to be
included in the SLA.
PBX interoperability with existing PBX and IT systems
Figure 1-7 PBX interoperability with existing PBX and IT systems
Feature / benefit
Basic call routing (inbound / outbound)
Advanced call handling
Attendant console (reception)
Advanced call routing (inter-site / in-country breakout)
Voicemail
Unified messaging (email, fax, IM, SMS)
Extension mobility (hot-desking)
MS Windows server – Active Directory
MS Exchange server
MS Mobile 5.0 / 6.0
Blackberry
Yes/No
Figure 1-7 highlights a number of issues to be clarified with vendors on the topic of
interoperability.
The examples shown here do not constitute an exhaustive or definitive list, since
infrastructures and functionality requirements vary from business to business.
One business may require basic IP telephony, whereas another will wish to add unified
messaging or unified communications.
The areas shown in the table are, however, indicative of the type of concerns that will arise
in the development of most RFPs.
Where basic call routing is concerned, for example, there is likely to be a transition period
between systems where the legacy PBX will run in parallel to the new IPT solution.
Basic inbound and outbound call routing will be needed between the two systems.
Published: 12 December 2007
© SAS Global Communications Limited
Page 12 of 22
In the case of businesses with multiple offices, it may be that one office has already moved
onto the new system whilst another has not yet been transferred; in this case it is clearly
vital to the business that offices can continue to talk to each other during the migration.
Where advanced call handling facilities are currently deployed, can they continue to be
used?
Other basic features such as voicemail, although simple, have become essential in the daily
functioning of business, and the consequences can be damaging to the business in the
case of disruption, particularly since roll-out is rarely an instantaneous process.
Interoperability assumes notable importance in ensuring a smooth transition, enabling the
system to offer all appearances of seamless and uninterrupted functionality.
Fixed mobile convergence and IPT handsets
Deciding how users (also referred to as agents) will communicate with the system, and how
remote users can be integrated, is a significant focus area within an RFP; offering the
opportunity for swift adoption within the business through high relevance to the detailed way
in which the business may operate, combined with easy-to-understand functionality
Investment in handsets often becomes one of the larger cost areas not because of
individual component cost but simply due to the number of handsets required.
Whilst many multi-functional models are available, offering attractive features such as colour
display screens, they tend to carry high individual price tags.
Multiplied by the number of agents on the network, this results in a figure which often
renders the high-end handset option unfeasible.
Handset selection should ultimately be based on essential functionality rather than alluring
additional features and attractive design.
IP telephony devices range from simple analogue telephones to advanced feature phones;
devices that are slightly different from normal handsets, such as conference phones.
If conference phones form part of the network requirement, it is likely that they are already
present within the existing infrastructure.
It is not necessary to replace them with IP-enabled units; which are absolutely identical, with
the only difference being that they are IP-enabled. Analogue adaptors can be used to
convert these devices, enabling them to work with the IP network.
This practice can create significant cost reductions.
IP wireless infrastructures also require careful consideration.
WiFi-enabled IP telephones are often deployed as replacements to a DECT infrastructure.
There are implications on wireless network coverage within the office infrastructure; where a
wireless network exists prior to deployment of the new system, it will need to be analysed to
ensure that it is fit for purpose with the new system, supports the voice protocols, and offers
sufficient radial coverage within the building to support voice as well as the existing data.
Another area to consider is video telephony, basically a video-enabled telephony device,
and video conferencing integration.
Published: 12 December 2007
© SAS Global Communications Limited
Page 13 of 22
Since all of these devices are IP-enabled, the process of enhancing them to include video
as well as voice is relatively simple and straightforward but does involve an additional
overhead in terms of network configuration costs.
This is in the areas of both quality of service, where assured forwarding class of service (AF
CoS) is required for the video traffic, and the additional bandwidth needed on the network.
In terms of mobile usage, softphones offer a cost-saving opportunity.
It may even be the case that IP handsets are not actually required if the business is made
up of large numbers of mobile or home workers or even desk space users.
In such situations, deployment of softphones to the desk tops would suit the working style
and needs of both the users and the business.
The softphone is simply another application that runs on the PC, using the IP connectivity of
the desk top to run across the network,
Accommodating the needs of mobile users means assessing their information needs and
working style, dictating the requisite functionality.
There is still no one device that offers functionality to suit all needs; developments in mobile
telephony are extremely fast-paced at this point in time so it may be opportune to set mobile
needs aside to be addressed at a later date, whilst remaining aware of market and product
developments.
Existing infrastructure integration and re-use
Having addressed the needs of the business, the existing infrastructure should be reassessed in collaboration with the selected vendor or vendors to discover which
components can be re-used.
The recent SAS white paper, ‘How to identify if existing network equipment will work with
IPT’ (12.11.07) covers this aspect in depth.
The re-use of components is primarily a cost-saving exercise but it also reduces the scope
of work and amount of change to the network.
Starting with the network switch infrastructure; do current switches support the virtual LANs
enabling the separation of voice and data traffic?
Do the switches support power over Ethernet, meaning that separate power supplies will not
have to be run to IP handsets, if deployed?
If so, this will enable power to be injected through the systems via the structured cabling
system, direct to the phone.
If wireless IP handsets are deployed, does the access point infrastructure support the
required voice quality?
Applications integration should also be considered.
If unified messaging is to be deployed, any current issues need also to be discovered at this
point; any legacy Active Directory issues will become major disruptions when further
devices are added into the mix.
Published: 12 December 2007
© SAS Global Communications Limited
Page 14 of 22
Adding unified messaging will increase storage requirements in the email environment so
capacity and storage must be re-evaluated.
Best practice would be to clean up the estate or expand the system before any adverse
situation is allowed to arise.
The other key area to assess is that of external connectivity - the routing infrastructure particularly through any wide area network.
An audit of the external connectivity will ascertain if the routing infrastructure is quality of
service enabled to ensure that class of service can be maintained across the external
connectivity, guaranteeing uninterrupted quality of experience and quality of service.
Communications consolidation
The relationship with any vendor involved in delivering an IP telephony, or unified
communications, solution will be long-term and ongoing.
This applies as much to external connectivity carriers as to other third parties involved in the
network infrastructure.
The RFP scope should be expanded in order to derive maximum benefit from such
relationships.
Figure 1-8 Communications consolidation
An example of areas to consider within a master services agreement is shown in Figure 18, designed to ensure ongoing support within the UK and into any international territories
pertinent to the business and the infrastructure.
Support is best provided through a single point of contact (SPOC) both for additions and
changes and for in-life product development; particularly for those areas where the pace of
development is more rapid than within the industry as whole.
Most notably, this includes areas such as mobile communications- PDAs and Blackberrysas well as smart phones.
The business is best served by a single contract to cover calls, lines, the wide area network,
the Internet, conferencing, mobile working and WiFi.
Published: 12 December 2007
© SAS Global Communications Limited
Page 15 of 22
A single point of contact is not only the most efficient arrangement, but also offers full
transparency in all events.
If a single party is responsible for the whole solution, then any issue arising clearly falls
within the remit of that party and there are no blurred lines of responsibility arising from the
partisan interests of different vendors or manufacturers.
Failover and business continuity
Business continuity is an absolutely critical area for the RFP. If failover is required between
circuits or devices, then system support is an important issue, particularly in the case of a
power outage, an occurrence exacerbated within a centralised system.
Any uninterruptible power supply or backup generator must have the capacity to supply the
system if the power fails.
Were a power outage to be of long duration, however, even the UPS might fail; the servers
would then have to be shut down in a controlled manner but a traditional phone system
would continue working by being injected across a standard analogue signal.
It could, for example, have PSTN connectivity, with a small voltage coming through from a
carrier.
In an IP telephony solution, no power means no phone system, so alternative power supply
arrangements must be robust and 100% reliable.
Proof of concept
Proof of concept is a highly desirable stage for signing off any RFP.
It entails creating a miniature version of the proposed IP telephony or unified
communications system such as that shown in Figure 1-9 which can be used by the
different stakeholders within the project group to test the system.
Figure 1-9 Proof of concept
WLAN
Telephony
access security
Internet
PSTN
Switching
Mobile users
Fixed users
Converged Network
Published: 12 December 2007
© SAS Global Communications Limited
Page 16 of 22
The example system shown includes a basic power over Ethernet switch, with a selection of
IP telephony handsets.
Softphones might be included, if the final system is to offer wireless access to users with
notebooks and handsets.
A single access point can also be included, as well as a representative sample of users as
indicated on the top right part of the diagram.
Connectivity to the outside world then allows a live test of system functionality.
Users are also given the chance to try the handsets and familiarise themselves with the
functionality.
Since these are the agents who will work with the system on a daily basis, their input on the
suitability of the functionality can serve to identify development areas for the RFP which
may have been overlooked or received lower priority than they may deserve.
The proof of concept stage offers two significant benefits.
Firstly, it is an opportunity for the vendor to prove that the system functions exactly as it was
designed to.
Secondly, it offers the system owner the chance to test it and, if necessary, further develop
the RFP if additional or different requirements emerge during the proof of concept stage.
IPT readiness and voice path validation
Prior to implementation of the new system, the voice path needs to be tested for IP
telephony and unified communications readiness using the mean opinion score (MOS) test.
Figure 2-1 shows results for different voice paths where each was scoring different results
for different factors, ranging, at the top, from 4.5 down to 1.0.
Figure 2-1 IPT readiness and voice path validation
Published: 12 December 2007
© SAS Global Communications Limited
Page 17 of 22
The system should score 3.5, or higher, to ensure that it is working effectively, that quality of
service is present and that there is no delay or jitter in the voice traffic.
Regular MOS testing affords the opportunity to improve and enhance different areas of the
network, re-testing until the system is within the 3.5 threshold, as shown in Figure 2-2, the
point at which the voice quality is likely to be maintained across the network.
Figure 2-2 IPT readiness and voice path validation
Testing and approval process
Arrangements for signing off the network should be put together at the RFP stage in
discussion with the relevant vendors, taking into account the testing and approval processes
with which they are accustomed to working.
Figure 2-3 summarises the core stages in the process.
Figure 2-3 Testing and approval process
Testing and approval
Project
initiation
Live operation
System
design
IPT and UC
project
•
•
•
•
Agree a project plan
Agree a testing plan
Agree acceptance criteria
Approval must come from each
department
• Monitor each system during testing
to understand impact on network
performance
Migration
Acceptance
test
Implementation
Published: 12 December 2007
© SAS Global Communications Limited
Page 18 of 22
The project plan and testing plan should be agreed with the vendor/s, as should the
acceptance criteria to be brought to bear at the sign-off stage.
This will ensure that parameters for the project conclusion are clearly identified and clarified
between both parties, for the avoidance of all doubt and to expedite project finalisation.
Approval must come from each department.
Success of the project is not governed purely by the IP infrastructure, but also by user
response to, and acceptance of, its functionality; user opinion should be canvassed to
ensure that users have the functionality and information required.
Monitor each system during testing to understand the impact on network performance.
The proof of concept stage and MOS testing of the infrastructure, both require an individual
testing and approval phase.
SLAs - infrastructure support
When the system is live it will require a comprehensive level of support, particularly since it
comprises different clusters of devices as shown in Figure 2-4.
Included within the infrastructure are a wide area network solution, external carrier
connectivity, the network server infrastructure as well as individual desk tops and users.
Figure 2-4 SLAs - infrastructure support
WAN service
Carrier router
Fire
wall
PSTN / BRI / PRI
VPN
Voice gateway
router
WAN router
Web
server
Application
server
SAN
Default gateway
Application server
UM server
Email server
Switch
Printer
Switch
gateway
Work station
WiFi switch
WIP
phone
Call control server
Switch gateway
IP phone
Laptop
These areas are typically supported by different teams or external third parties, but when IP
telephony and unified communications are introduced across the estate a common service
level agreement is required to encompass the various different devices and the different
infrastructure components.
Published: 12 December 2007
© SAS Global Communications Limited
Page 19 of 22
Extended maintenance services
Whilst the RFP begins with the build, infrastructure design, implementation, provision and
install, it should also incorporate two further stages to ensure continuous functionality and
longevity of use: management and support.
The various elements involved are summarised in Figure 2-5.
Figure 2-5 Extended maintenance services
A comprehensive extended maintenance service agreement should be put in place to
provide reactive support, incident management, preventative maintenance, routine
maintenance, moves, adds and changes.
The agreement should also cover policy development; continuous evolution and
development of the system as new features and functions become available.
Further detail on support will be found in the SAS white paper, ‘How to support an IP
telephony network’ (10.10.07).
Published: 12 December 2007
© SAS Global Communications Limited
Page 20 of 22
Conclusion
In conclusion, detailed planning is required for an IP telephony and unified communications
RFP.
This should extend beyond the telephony system itself to encompass the network
infrastructure, how the business uses telephony and how it will work with other offices and
remote users within the estate.
The key points to bear in mind when putting an RFP together are as follows:
Project team configuration should be on a cross-company basis.
The project team also needs to involve third parties such as carriers and other parties
involved in the communications aspect of the network.
Selected vendor should be, and will be, a long-term business partner.
Selection is, therefore, a process that will have an impact on the business and should be
diligently undertaken.
Any candidate vendors should have the footprint, the coverage, and the support and
management options to support the business at all its locations.
The product should be evaluated both for its present functionality and its future road
map.
This is an area which is developing very fast, particularly in terms of functionality, like
presence, and features such as mobile users.
It is important that any business moving into IP telephony deployment stays aware of
developments into the future.
A successful IPT and UC RFP is driven by the business requirement.
Technical requirements will come out of the business needs and should clearly never be
specified in isolation from them or because of the standalone attractiveness of the system
and features it may offer.
An RFP must be clear, concise, offering easy evaluation of, and comparison between,
different vendors.
Endeavouring to interpret and compare different documents in different styles and formats
can be an unnecessarily time-consuming process.
Establishing unequivocal key metrics to monitor each response clarifies the process and
ensures that comparisons are made on a like-for-like basis.
Multiple vendors should be evaluated for each manufacturer.
If there is a manufacturer of choice, perhaps dictated by the global footprint, multiple
vendors should still be compared.
Client references from similar project implementations should be requested.
Asking for references alone does not always elicit an appropriate response since they may
not reflect the type of business, the business footprint or the type of solution that is being
proposed.
To ensure an accurate and appropriate base for assessment, the references should relate
to similar project implementations.
Published: 12 December 2007
© SAS Global Communications Limited
Page 21 of 22
Proof of concept of the solution is a key stage of any vendor selection.
Proof of concept also provides an opportune exit route.
Should a vendor fail to deliver against this stage it is unlikely that the same vendor would be
successful at the full implementation stage.
An alternative approach would be to select more than one vendor to undertake individual
proofs of concept to see the difference between solutions on offer.
Meetings must be held with the vendor’s implementation and support team.
It is an insufficient basis on which to move forward if vendor meetings have only ever been
held with the vendor’s sales team.
The implementation and support team will provide an understanding of the business, the
support offered and what the in-life experience will be like once the system is deployed.
About SAS
SAS Global Communications is a major provider of managed and professional network
services. The company provides consultancy and implementation services to design, build
and manage converged IP networks for enterprises of all sizes. Since its inception in 1989,
the company has successfully delivered more than 2000 highly commended solutions, to a
broad spectrum of clients including many renowned brands, such as Coca Cola Enterprises,
The Body Shop International and Millennium and Copthorne Hotels.
For more information contact:
SAS Global Communications Limited
SAS House
Blackhouse Road
Colgate, Horsham
West Sussex RH13 6HS
Tel: +44 (0) 1293 851951
Fax: +44 (0) 1293 852200
Email: [email protected]
www.sas.co.uk
Published: 12 December 2007
© SAS Global Communications Limited
Page 22 of 22