Integrating Enterprise Telephony with Office Communications Server 2007 R2

elbowshelmetΔίκτυα και Επικοινωνίες

30 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

116 εμφανίσεις



Integrating
Enterprise
Telephony with

Office Communications Server
2007
R2



Office
Communications

Server
Group

Microsoft Corporation

March
200
9


Page
2

of
47


The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commit
ment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.

This
w
hite
p
aper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR
STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable laws, including copyright laws, is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in
,

or introduced into a retr
ieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications,

trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these pa
tents, trademarks, copyrights,
or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e
-
mail addresses, logos,
people, places
,

and events depicted herein are fictitious, and no association with

any real company, organization,
product, domain name, email address, logo, person, place or event is intended or should be inferred.




200
9

Microsoft Corporation. All rights reserved.

Microsoft, the Microsoft logo, the Office logo,
Active Directory,
Outlook,
Windows,
Windows Live,
and Windows
Server
are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries. All other trademarks are the property of their respective owners.

Abstract

This paper defines
Microsoft strategy
toward
enterprise
telephony
integration

and, in particular, its
approach to

integration using
Microsoft
®

Office Communications Server
.

We have included p
rogressively
more detailed levels of technical information to pro
vide readers in various disciplines
with
an
understanding of the integration that we are striving to achieve.

The intended audience for this paper
consists of

Microsoft customers, partners
,

and the industry at large.

T
o address the needs of our diverse
customer base, we have defined several deployment scenarios
,

and
each is described in detail, including high
-
level feature descriptions, migration paths
,

and call flows.

A
broad ecosystem of partnerships has been created to facilitate the deployment scenar
ios and to smooth
the path to deployment and integration.

Micros
o
ft has implemented p
rograms to support these
partnerships
,

and these are also described.


This paper is written as a supplementary text to various other documents
that

describe Microsoft unif
ied
communications strategy, value proposition, features
,

and functions.

Information that is dynamic in nature
is maintained
on

W
eb pages
on
http://technet.microsoft.com/UCOIP

and will be supported by link
s to
partner
W
eb sites.

A glossary of terms is included in the appendices for those unfamiliar with some of the
terminology in this paper.

Please refer to those documents for further information.


Page
3

of
47

Table of Contents

Introduction

................................
................................
................................
................................
......

5

Microsoft and Telephony Partners

................................
................................
................................
......

6

Intermediation of Telephony

................................
................................
................................
..............

7

Overview of Telephony
Integration

................................
................................
................................
..

10

Architectural Overview

................................
................................
................................
................

10

Voice Functionality

................................
................................
................................
......................

11

The Offi
ce Communications Server Difference

................................
................................
..............

13

Office Communications Server Deployment Scenarios

................................
................................
..

14

Office Communications Server Stand
-
Alone
................................
................................
................
14

Office Communications Server Co
-
existence Scenario
................................
................................
.
15

Partner Ecosystem

................................
................................
................................
..........................

17

Media Gateways

................................
................................
................................
........................
17

PBXs

................................
................................
................................
................................
.........
17

SIP Trunking

................................
................................
................................
.............................
17

Media Gateway In
tegration

................................
................................
................................
..........

18

Basic Media Gateways

................................
................................
................................
...............
18

Hybrid Basic Media Gateways
................................
................................
................................
.....
19

Integrated Media Gateways

................................
................................
................................
.......
19

PBX Integration

................................
................................
................................
...........................

20

UC
-
Enabled PBX

................................
................................
................................
........................
20

UC
-
Capable PBX

................................
................................
................................
........................
20

Non

UC
-
Capable

PBX

................................
................................
................................
................
21

SIP Trunking Integration

................................
................................
................................
.............

22

SIP Trunking and Standards

................................
................................
................................
......
23

Unsupported Scenarios
................................
................................
................................
................

23

Branch Office Survivability

................................
................................
................................
.........
23

Hosted
Telephony

................................
................................
................................
......................
23

Non
-
Office Communicator Endpoint Support

................................
................................
..............
24

UDP as a SIP Transport

................................
................................
................................
.............
24

Telephony Integration Features and Mechanisms

................................
................................
.............

26

Office Communications Server 2007 Stand
-
Alone Telephony Integration

................................
......

26

Inbound Call

................................
................................
................................
..............................
26

Outbound Call

................................
................................
................................
...........................
27

Call Forward and Transfer

................................
................................
................................
..........
27

Conference

................................
................................
................................
................................
28

Office Communicati
ons Server 2007 Co
-
existence Telephony Integration

................................
.....

30

Inbound Call

................................
................................
................................
..............................
30

Outbound Call

................................
................................
................................
...........................
30

Call Forward and Transfer

................................
................................
................................
..........
31

Co
nference

................................
................................
................................
................................
32

Do Not Disturb

................................
................................
................................
..........................
32

Migration Paths and Integration Strategies

................................
................................
......................

33

Page
4

of
47

Building the Foundation

................................
................................
................................
...............

33

PBX
to Office Communications Server 2007 Co
-
existence
................................
.............................

33

PBX to Office Communications Server 2007 Stand
-
Alone
................................
..............................

34

Office Communications Server 2007 Co
-
existence to Office Communications Server 2007 Stand
-
Alone

................................
................................
................................
................................
..........

34

Customer Location That Has No Current Telephony Infrastructure to Office Communications Server
2007 Stand
-
Alone

................................
................................
................................
.......................

35

Summary and Conclusions
................................
................................
................................
...............

36

Appe
ndix A: Office Communications Server Stand
-
Alone Scenario


Call Flows
................................

37

Inbound Call
................................
................................
................................
................................

37

Outbound Call

................................
................................
................................
.............................

38

Call Placed on “Hold”

................................
................................
................................
...................

39

Append
ix B: Office Communications Server Co
-
existence Scenario


Call Flows
...............................

40

Make a Call

................................
................................
................................
................................
.

40

Answer a Call

................................
................................
................................
..............................

41

Forward

................................
................................
................................
................................
......

42

Transfer

................................
................................
................................
................................
......

43

Conference
................................
................................
................................
................................
..

44

Do Not Disturb

................................
................................
................................
............................

45

Glossary
................................
................................
................................
................................
..........

46


Page
5

of
47

Introduction

On October 16, 2007, Microsoft entered the emerging unified communications product space with the
worldwide launch of
Microsoft
®

Office Communications Server 2007

and Microso
ft Office Communicator

2007.

Combined with
Microsoft Exchange Server 2007,
the
Microsoft unified communications platform
delivers streamlined communications for enterprise users
, enabling direct communication from
the
applications they use most
,

such as Mi
crosoft Office Outlook
®

messaging and collaboration client
.

With
this
release, t
he concepts of context
-
based, person
-
centric collaboration that shipped with
Microsoft
Office
Live Communications Server 2005 and Microsoft Office Live Meeting 2005
were

now ti
ghtly
integrated with multi
-
modal communications using voice, video,
W
eb

conferencing
,

and instant
messaging

(IM)
.

Now, a
dditional
capabilities have been brought to the platform

with the introduction of
Microsoft Office Communications Server 2007 R2
, which
streamlin
es

communications for end

users,
provid
es

operational flexibility and control for IT, and
offer
s

a rich extensible development platform for
integrating business processes with communications capabilities.

For
more than

100 years, telephony

has played an increasingly important role in business
communications.

With the advent of mobile networks, the ability to communicate
from

almost any location
and situation has increased the reliance of business users on telephony
.

The telephony world is h
ighly regulated, with every national government playing a role in regulation of
telephony service providers, telecom devices, and, in some cases, telecom technology standards.

Many
different national networks operate on various dialects of telephony standa
rds
,

and many countries
require that vendors have their telecom products certified by the national telephony authorities.

Some
telephony business markets have undergone deregulation over the last 20 years,
which

has increas
ed

the number of vendors and serv
ice providers, all of whom have made different product and technology
choices.

As a consequence, enterprise telephony has become increasingly complex in terms of architecture
,

feature
,

functionality
,

and
integration with business processes

(
e.g., call cent
ers
)
.

The

average enterprise
of at least moderate size and age owns multiple installations of PBX
systems
spanning several
generations of technology.

Furthermore, companies that have expanded by acquisition often have several
different vendors’ products in

their communications infrastructure.

Personal habits, operational
preferences
,

and the inherent limitations of telephony and the traditional telephone form factor have
created myriad features and functions that are addressed more intuitively within unifie
d communications.

Microsoft works

with
enterprise telephony infrastructure
vendors to successfully
integrat
e

Office
Communications Server

with enterprise telephony

systems
.

We have engaged in technology exchanges
with these partners
,

and we continue to wor
k with them to validate the interoperability of our respective
solutions.

To

provide broad coverage for the spectrum of telephony solutions in which our customers
have already invested, we are establishing and participating in broad interoperability verifi
cation
programs.

Complexities notwithstanding, the integration of enterprise telephony systems
with u
nified
c
ommunications is an imperative.

Office Communications Server
2007
R2

delivers software
-
powered
VoIP functionality that works with enterprises


exis
ting messaging and telephony infrastructure and can
adapt to changing business needs.

With Microsoft customers around the world numbering in the
hundreds of millions, we face an integration
challenge that

spans the entire spectrum of telephony.

This
paper
details for our customers, partners
,

and the industry at large the approach that
Microsoft has

defined and the various programs
that

support
a

strategy

to simplify the telephony interface when
integrating with the telephony world
.

Page
6

of
47

Microsoft and Telephony P
artners

Microsoft works with a range of partners to
promote

unified communications, including those in the
telecom industry

that are

most
affe
cted by the emergence of unified communications products and
solutions, namely the
SIP/PSTN
gateway and PBX
vendors.

Voice communication has long been purchased, provisioned
,

and managed separately from the rest of
the IT infrastructure.

Convergence has seen three basic waves of change in this view.

The first wave
combined voice and data traffic on backbone netw
orks.

Later, IP PBXs allowed for that traffic to be
combined at the desktop level.

The final wave, represented by unified communications, integrates voice
with other communications methods and data at the application level.


The

integration of voice means
that the stand
-
alone box known as a PBX ceases to exist as an
independent silo, and the monolithic, vertically

integrated functions therein have been disaggregated and
replaced by a set of services that live in a highly distributed model borne over an IP n
etwork.

Many of
these services, such as directory or presence services, no longer exist separate
ly

for voice
communications, but rather subscribe to those services
that

already exist within IT, such as e
-
mail, IM,
policy
,

and security.

Increasingly the new

world begins to assume roles and attributes from the PC
ecosystem, which is not vertically integrated but consists of horizontal platforms and capabilities.

Independent
s
oftware
v
endors (ISVs) build applications and add value on top of those platforms;
pe
ripheral vendors add functionality through devices.

Eventually
, communications will become a truly universal and standards
-
based network, and it will be a
plug
-
and
-
play
experience.

But for the foreseeable
near
future, there will continue to exist many
forms of
voice technologies, protocols, standards
,

and regulatory environments in which interoperation

and co
-
existence
are

required.

The installed base of PBXs is massive, and the business users of those systems
expect their investments to be protected.

T
elecom vendors have amassed
expertise
over the years
that
clearly

positions them to provide integration leadership, both in products and in consultancy.

The opportunities
for partners
will also expand as unified communications enhances workflow, becoming
m
ore integrated with line
-
of
-
business processes and applications.

Once again, many of these vendors
have deeply established market positions within certain verticals and this competence will apply directly to
unified communications.

Building applications
th
at

are well integrated with Microsoft platforms

in particular Exchange Server and
Office Communications Server

will provide a rich functional base and the potential for broad market
adoption for value
-
added capabilities.

Distribution, support, and training

models will be jointly developed
to compl
e
ment partner expertise and focus on core Microsoft technologies for unified communications.

Page
7

of
47

Intermediation of Telephony

T
he complexity of the telephony infrastructure is
one of the
major issue
s

that we have had to

consider in
determining our strategy.

As

a later entrant into the telephony space, there are certain required areas of
engineering expertise that
Microsoft
do
es

not possess and
areas are not seen

as an opportunity to
innovate and differentiate.

This

asses
sment

coupled with the significant
customer
investment in
telephony infrastructure

has led us to
focus on
existing telephony
interoperability
via IP technologies
rather
than make our own investments in telephony protocols.

Microsoft
i
s already
recognized

as
a leader

in the industry with its unified communication technologies
enabling
next
-
generation communications

using SIP, SIMPLE
,

and Real
-
time
Transport
Protocol (RTP)
media technologies.

In G
artner’s September 2008 report “Magic Quadrant for Unified Co
mmunications
,


Microsoft landed in the leader category.
Live Communications Server 2003
and
2005, Office
Communications Server 2007
,

and Office Communications Server 2007 R2 have
raised
the bar for
enterprise
-
grade communications solutions with significant

innovations and advancements in the areas
of:



Intuitive user experience



Multi
-
modality (e.g.
,

voice, video, text messaging,
desktop sharing,
and W
eb collaboration)



Ad

hoc
,

multiparty, multimodal conferencing



Integration with business applications



Rich
p
re
sence



Mobility



Security



Regulatory
c
ompliance



Scalability



Total
c
ost of
o
wnership (TCO)



Operational
c
ontrol

Delivering these innovations has required that we adopt the latest standards and technologies in our
software
.
Some examples of these
technologies
a
re:



The use of Transport Layer Security (TLS) to encrypt SIP messages to facilitate
more
secure
signaling



The use of Secure Real
-
Time Protocol (SRTP) to encrypt media packets to facilitate private
conversations



The use of a range of SIP methods and headers

defined in various IETF RFCs to facilitate a rich
set of feature functions required of an enterprise
-
grade communications platform



The early adoption and deployment of the emerging
Interactive Connectivity Establishment (
ICE
)

standard for Media/NAT traver
sal to facilitate the mobility of clients outside the enterprise network



The creation of advanced
RTP

codecs that deliver a high
-
quality audio experience by providing
resilience to bandwidth congestion and other adverse network conditions that can be found

on
the public Internet



The early use of draft standards to facilitate ad

hoc
,

multimedia
,

real
-
time conferencing

Page
8

of
47



The use of the inherent functions of the Windows Server
®

operating system
to provide a
seamless management and monitoring experience

When we e
xamined the telephony market we found that,
although
many vendors had made initial
investments in next
-
generation communications using SIP and RTP, the technology implementations
were often several generations behind those being u
s
ed in Office Communicatio
ns Server
2007
.

One
example of this is that few of these elements supported
Transmission Control Protocol

(
TCP
)

as a SIP
transport protocol even though this was part of the original SIP specification, IETF RFC 2543, which was
ratified in March 1999.

Even f
ewer vendors support SIP over TLS
,

which was specified within IETF RFC
3261 in June 2002

and which

our clients and servers use to encrypt SIP traffic.

Therefore, a consequence
of Microsoft
innovation and support for
progressive

standards is that our
c
lient
s and
s
ervers do not
interoperate with some
SIP
-
based
telephony elements.

One interoperability option that we considered was that our clients and servers could be adaptive and
interoperate with telephony elements at the level of technology that they were a
ble to support.

The
disadvantages of this approach were:

1.

The value of our advanced features in the areas of security, audio quality, mobility
,

and
network resilience would be nullified when a user makes a PSTN call
.

2.

The mechanism within SIP that would
enable this (i.e.
,

the SIP OPTIONS method) was not
generally supported within telephony elements
.

3.

The test matrix of multiple Microsoft clients and servers being tested against each of the
thousands of proprietary incremental telephony elements would be un
manageable
.

A second option
was

to issue specifications that would enable partners to
deploy
the features that
Microsoft
had implemented.

The disadvantages of this were:

1.

When we started planning for the unified communications products in 2005, we did not h
ave
a clear sense of the feasibility of influencing partners’ development road

maps (particularly in
such a significant way) in order to facilitate interoperability with our clients and servers
.

2.

Since we knew how much time and effort it took for us to impl
ement these mechanisms, we
knew that partners’ implementation timelines would be a gating factor on customers being
able to take advantage of the value of Microso
ft u
nified
c
ommunications.

3.

Many of
the
Office Communication Server
innovations require signifi
cant CPU cycles (e.g.
,

encryption, bandwidth variable codecs, etc.) and the hardware in currently deployed
telephony elements is often inadequate to support this processing load in addition to the
currently supported functions.

Causing customers to conduct

the required “fork
-
lift upgrade”
to address this issue is clearly counterproductive to our efforts to gain widespread
deployment of Office Communications Server and Office Communicator.

A third option was to provide a “front end” element that would:

1.

Inter
mediate signaling and call flows via a back
-
to
-
back

user

agent (B2BUA); including
adding or removing elements of a SIP transaction that were not supported by most telephony
elements
.

2.

Transcode RTP media flows from
traditional
codecs such as G.711 to our ad
vanc
ed audio
codec: Real
-
T
ime Audio (RTAudio).

3.

Act as an ICE client to enable PSTN
-
originated media flows to traverse intervening NATs and
firewalls.

Page
9

of
47

4.

Enroll in the management, monitoring
,

and provisioning scheme (
using
familiar management
technologies such

as
Windows
®

Management Instrumentation
,
Microsoft Management
Console,
, A
ctive
D
irectory
, and System Center) to extend our seamless management
functions to the PSTN and PBX
.

The

third option was selected as the

most effective

and

pragmatic

approach. It
would not only work
across the board, but also allow us to quickly bring solutions built using Office Communications Server
2007

to our customers.

The element that fulfills the telephony intermediation function has become the
Office Communications Server r
ole of Mediation Server.

Furthermore the initial purchase cost of
Mediation Server, was very small in comparison
with
the initial purchase cost
of
other adjacent telephony
elements

(e.g.,
an IP
-
PSTN
m
edia
g
ateway or a forklift upgrade to an IP

PBX
)
.

Refin
ements to the intermediation strategy in the
R2

release
(
as well as
planned refinements in future

releases
)

will significantly reduce this cost to a negligible level.

As described later, we
have made
it
possible for partners to ship Mediation Server to run

on
m
edia
g
ateways rather than installed on a
separate server element.

Other strategic refinements under consideration
include
expanding the role of
Mediation Server to
providing

such things as:



I
ntermediation for a pool of
m
edia
g
ateways



B
ranch office sur
vivability functions



Interoperability

with older generation
telephone device
s


Page
10

of
47

Overview of Telephony Integration


Architectural Overview

Microsoft

u
nified
c
ommunications
uses
standards and published interfaces to interoperate and integrate
with existing
telephony and applications infrastructure investments, offering a flexible integration of
telephony with other business communications tools.







Page
11

of
47

Voice Functionality

Although

Office Communications Server

2007

R2

is not a PBX,
by using
an Office Communications
Server endpoint (e.g., Office Communicator
2007
R2
, an Office Communicator IP handset
,

or Office
Communications Server 2007 R2 Attendant
)
a user can

communicate in a powerful and intuitive way by
integrating with traditional teleph
ony equipment.
O
ur unified communications software include
s

the
following
voice features and functions:

(
Note that
this

is an illustrative subset
,

not a full feature

list
.
)



An Office Communications Server endpoint can:

o

Click to dial from the Office
Communicator

2007

R2

contact list, corporate directory
,

or
Office
Outlook
2007
contact list
.

o

Log
o
n outside the corporate firewall and have the
same corporate calling experience from almost any
public
I
nternet connection.

o

Dial using t
raditional digit dialin
g in the UI or via a
keypad pull
-
down window.


o

Accept or deflect inbound calls
.

o

Call forward
to numbers, contacts
,

and groups
(rule
-
based) and transfer (blind and
monitored
)
.

o

“Click to conference
,

escalate
a
two
-
party call to
conference

or schedule a dial
-
in conference using
Office
Outlook
.

o

Use c
all
delegation

allowing for call

handling on
behalf of users by
attendant or team admin.




Voice

mail provided by
Exchange Server 2007

Unified Messaging

offers
:

o

Voice
m
ail access
and Message
Wait
ing Indicator
through the
telephone and Office Outlook
2007
inbox

o

Ability to u
se the phone to manage
e
-
mail, calendar, and personal
contacts

o

Take
action using speech
recognition or touch tone


o

Main switchboard and search
directory service

o

Customizable aut
o attendant

Page
12

of
47




Office Communications Server
2007
R2

provid
es

next
-
generation
call management
functionality
,
including
:

o

Call routing independent of physical location

o

Call queuing and treatment
,

including music on hold and multilingual speech recognition

o

Profile
-
based call routing

o

Least
-
cost PSTN call routing

o

Application of global routing rules

o

Near real
-
time monitoring of call quality, including media and network effects

o

Toll
-
free calling for calls that can be routed via Voice Federation






Page
13

of
47

The Offic
e Communications Server Difference

T
he features described above are only a representative sample of telephony
-
type
features offered by an
Office Communicator endpoint
. T
oday’s PBXs typically have many hundreds of such features.

T
he
number of features is pa
rtly a function of:



T
he amount of time that PBXs have been sold on the market



T
he number of players in the market and their need to differentiate themselves



A
daptations due to the inherent architectural limitations of telephony

For example, many of the fea
tures implemented in a PBX are intended to ensure that calls are not missed
or do not end up in voice

mail

(
“find
-
me, follow
-
me” features
)
.

Unified
c
ommunications
uses

a
fundamentally different paradigm to address the underlying customer need.

At the basis

of Office Communications Server are three simple yet fundamental concepts that significantly
change the communications experience:



Person
-
centric communications using a single identity: you communicate with a person, you don’t
dial a device.



Presence
-
base
d communications: you only attempt to communicate with someone who is
advertising
his or her
willingness and ability to communicate with you at any given moment.



Streamlined communications: you can choose the right communications method, move from one
comm
unications method to another, and maintain the context of all communications methods
(e.g.
,

subject, content) across the different methods.

Single identity and rich presence are the foundation for the deployment of software
-
powered VoIP. Office
Communicator allows for presence status to be controlled directly by the user or
to be
determined
automatically based on Office Outlook calendar, log
o
n

status,
phone status
,

and other sources of
information.

Users can set different levels of access for different contacts, allowing for inbound requests
to be handled automatically
depending
on a combination of access level and presence state.

Finally,
ensu
ring
that
you can reach the right person, right now
,

using the optimal method of communication
,

saves time and improves productivity.

This new communications paradigm renders many of the features in a PBX redundant and offers a
simpler and more effective w
ay to communicate.

As the telephony interface with Office Communications
Server, this means that the basic call setup, teardown and redirection features are all that is required to
provide a user with an effective and intuitive PSTN experience.

IP

PBXs hav
e become increasingly common since the turn of the century, so the notion of all IP
telephony is not new.

With the advent of free VoIP hosted by popular
I
nternet services such as Windows
Live

, Yahoo!, AOL
,

and Skype
,

consumers have started to experience t
he power of an IP voice
experience.

However, Office Communications Server

2007

R2

is not meant to be a PBX but an alternative
communications mechanism to that offered by a PBX.

There are a number of
ways
that
Office
Communications Server and Office Communi
cator
interoperate with the IP

PBX
and these will be
discussed below.



Page
14

of
47

Office Communications Server Deployment Scenarios


The
Office Communications Server supports several scenarios that address different customer
deployment strategies and timelines, as
well as customers’ existing telephony investment mix.


Office Communications Server Stand
-
A
lone

Arguably the most progressive option for the deployment is to exclusively use Office Communications
Server
a
nd associated elements for the voice communications
needs of a department
(see
figure
below)
or an enterprise, eliminating the PBX phone
system
altogether for those users. Enabling this scenario,
software
-
powered VoIP can be provided first to groups such as highly collaborative teams, information
workers wh
o are often traveling, mobile and home office workers, and
,

more generally speaking, to
people who use their personal computer
s

all the time and wherever they are.


When deployed as a departmental solution,
the

stand
-
alone

deployment scenario
has
the ent
erprise dial
plan partitioned between Office Communications Server users and PBX users.

This means that users
have either a PBX phone or an Office Communicator endpoint, but not both.

As such, for users
configured in this manner, Office Communicator will s
tand alone as the single corporate telephony
endpoint on their desktop
s
.


The main advantage is that required changes to the PBX are very limited because technically the
scenario is an addition of another node to the existing telephone infrastructure.

Addi
ng a networking
interface to an existing PBX and rerouting incoming calls for migrated users to this interface are the
telephony world’s standard procedures.

As a result, this scenario is u
s
ed as a migration strategy (see
“Migration
Paths and Integration
S
trategies
,
” below) or in the situation where a given PBX is not capable
of forking calls and therefore cannot be integrated into an Office Communications Server
c
o
-
existence
scenario.




Page
15

of
47

Office Communications Server Co
-
e
xistence

Scenario

This scenario involves a PBX
interoperating

with Office Communications Server and Office
Communicator to provide a flexible and powerful combination of traditional telephony and unified
communications.



The
c
o
-
existence deployment scenario involves a
nat
ive integration of a PBX with Office Communications
Server.

The PBX must natively support SIP and IP media in a form that i
s interoperable with Microsoft
u
nified
c
ommunications.

Microsoft announced this mechanism in March 2007 and
several PBX vendors
now
s
upport this scenario.

In addition, a
n interoperability specification

for this scenario is available to PBX
vendors,
1

along with a program to support the integration testing of vendors’ products with Office
Communications Server

(
discussed in more detail be
low
)
.

Note that only the latest PBX models will
support this mechanism and, even then, it is likely that a software upgrade must be supplied by the PBX
vendor.


Remote Call Control

Remote Call Control was the PBX integration mechanism that initially shippe
d with Live Communications
Server 20
05 and continues to be supported in Office Communications Server.

In this scenario, users can
issue comman
ds from Office Communicator to

the PBX for their telephone extension
s

for example,

click
to call, deflect call (e.
g.
,

to another phone number or
to
voice

mail)
,

and
hang up call.

Office
Communicator
does not

act as a “softphone” in this scenario
;

t
he PBX phone
is

the default device used
for the voice conversation
.
Office

Communicator

merely
sends

commands to the PBX to carry out actions
on the calls routed to the user’s extension.





1

Note that this specification does not deviate from SIP standards, but it does contain additional
mechanisms to ensure that calls forked from UC to a PBX are not forked back, thus creating an infinite
loop.

Page
16

of
47



The protocol used for this integration is the CSTA over SIP standard
TR/87.

G
ateways provided by
Corebridge or
Genesys

can be used

with nearly any model of PBX.

Additionally, some PBXs offer

native


TR/87 support through add
-
on modules
.


Remote Call Control can be paired with the
c
o
-
existence scenario
so

the user
can
control the PBX phone
using RCC along with receiving calls directly on Office Communicator.

Dual
f
orking with RCC is
only
available for qualification
with
Office Com
munications Server 2007.

Page
17

of
47

Partner Ecosystem

Microsoft

has
created
a

program

to
qualify
enterprise telephony
vendors against system specifications
that define interoperability with Office
Communications Server.

This program
,
called the Unified
Communications Open Interoperability Program (UCOIP)
,

qualifies
SIP
-
PSTN
gateways, IP

PBXs
,

and
SIP
t
runking
service
providers

to

ensure

that customers have a more seamless experience with setup,
supp
ort, and use of these products with Microsoft unified communications software.

All products that have
been qualified through the UCOIP are listed at the program’s
W
eb

site
:

http://technet.microsoft.com/UCO
IP
.

Customers will look for solutions that have been qualified
in the UCOIP
to
interoperate
with Office
Communications Server
,
provide a high
-
quality initial experience
,

and lower deployment costs.

Going
forward, c
ustomers can have confidence that these products have demonstrated proven enterprise
-
class
scalability and enhanced security at lower operational cost.

The deployment scenarios for Office Communications Server
require

enterprise telephony equipment that
h
as been qualified in the UCOIP with
defined
levels of functionality.

The
s
tand
-
alone deployment scenario
requires that the telephony infrastructure has been qualified for Direct SIP with Office Communications
Server, while the
co
-
e
xistence deployment scena
rio requires that the
m
edia
g
ateway or IP

PBX has
qualified for
d
ual
f
orking.


Media Gateways

Microsoft partners for media gateways have demonstrated that their products interoperate with Office
Communications Server to enable connectivity to the PSTN dire
ctly, or via a
PBX that is not
UC

c
apable

or not
UC

e
nabled.

UCOIP

ensures that gateway partner products meet the requirements
of
Office
Communications Server in
the
areas of audio quality, gateway features, connectivity, performance,
security, and ease

of

use.


PBX
s


Microsoft is committed to ensuring that
most

current

PBX solutions can interoperate with Office
Communications Server to handle scenarios defined as PBX co
-
existence by Microsoft.

This requires that
PBX vendors support certain specific feature
s and handle many end
-
user scenarios.

The PBX co
-
existence
specification
focuses
on key areas of PBX call handling, signaling, audio quality, performance,
loop
-
back detection, connectivity, and other defined items of the specification.

Customers always
have the option of upgrading their PBX installed base to the versions that are certified
by PBX vendors as being compatible with Office Communications Server.

However, if customers choose
to maintain their existing investment in PBX technology, they have t
he opportunity to deploy either the
Office Communications Server
c
o
-
existence
scenario
or
the
Office Communications Server
s
tand
-
alone
scenario in conjunction with a media gateway certified with Office Communications Server that supports
the PBX model in q
uestion.

In making this decision, a careful cost
-
benefit analysis must accompany a
technology strategy review that defines the short, medium
,

and long
-
term goals and objectives for
enterprise communications.

SIP Trunking

Microsoft
works
with several IP
t
e
lephony
s
ervice
p
roviders
that
offer
SIP
t
runking services to enterprises

for the delivery of phone calls from the PSTN entirely without a circuit connection.

Qualification of SIP
t
runking partners ensures that the service meets the requirements needed by
Office Communications
Server for audio quality, end
-
user features, connectivity, performance, security

and ease

of

setup.



Page
18

of
47

Media Gateway Integration

Media
g
ateways play a vital role in unified communications
.

B
ridging users from the Office
Communications
Server
and PSTN worlds together when a SIP
-
enabled PBX is not present requires a
m
edia
g
ateway
to be used
with Office Communications
Server
.

Although
gateways can help complete the picture, Office Communications
Server
uses the latest SIP,
security, and au
dio codec capabilities to deliver an enterprise
-
class VoIP software solution,
potentially
creat
ing

a gap with what the gateways can support today. Mediation Server was created to help reduce
the
amount of change

needed to
interoperate
with Office Communica
tions
Server
;

in many cases
,

all that
is required is
a software upgrade and configuration changes to a gateway.

Since the
development of
Office Communications Server 2007
,

we have worked with
many
gateway partners to
qualify
their
gateway products to work
with Mediation Server.

You can find a

list of supported gateways
at:
http://technet.microsoft.com/UCOIP
.

We are also working with
m
edia
g
ateway companies to evolve their gateway solutions to natively support
the advance features of
Office Communications
Server 2007 R2

and eventually
to
replace the need for a
Mediation Server.

We expect to see these advancements become available
soon
.


To ca
tegorize the landscape of
media
gateways, Microsoft defines two major classes of
g
ateways:

Basic
(including Basic Hybrid) and
Integrated
.

Basic Media Gateways

A Basic Media Gateway is a traditional gateway appliance that supports key functionality
includin
g
SIP,
e164, TCP as a SIP transport, Fax, G.711, number manipulation, and others as described in the
specification

readily available to
m
edia
g
ateway partners
.

T
hese gateways don’t support certain
functionality such as RTAudio or ICE,
so
they require the M
icrosoft Mediation Server to interoperate with
O
ffice Communications
Server 2007 R2
.

The benefit
of

this
arrangement
is that many of the common gateways in use today
have qualified for
interoperation with Mediation Server
,
and they often

only requir
e

a
simple ROM update and configuration.




Page
19

of
47

Hybrid Basic Media Gateways

Considered part of the Basic Gateway family (due to not natively supporting advanced features of Office
Communications
Server 2007 R2
), Basic Hybrid Gateways
are a combination of a Basic Media Gateway
that co
-
exists with a Windows Server
operating system
running Mediation Server
, all on the same
chassis
.


The benefit

of

this design
is
having a single box to physically manage, making it easier for IT to
deploy
.

These boxes can also come preconfigured to work with Office Communications
Server 2007 R2
, making
setup

even
simpler
.



Integrated
Media Gateways

An
I
ntegrated
Media Gateway natively takes advantage of certain “advanced”
features (such as n
ative
RTAudio, SRTP, ICE, and SI
P over TLS) that enable it to interoperate directly with the Office
Communications Server deployment without the need for a separate Mediation Server.

Not only is this a
single appliance that IT
profession
als
can deploy and manage
,

but
there is more room to improve
performance on audio quality and concurrent calls due to
the
native support
for
the advanced features of
Office Communications
Server 2007 R2
.

Integrated g
ateways are currently not available wit
h the release version of Office Communications Server
2007

R2
.

W
e anticipate

that

this class of gateway
will be
available
in 2009
.




Page
20

of
47

PBX Integration


As stated above, Microsoft
u
nified
c
ommunications offers customers the
opportunity to integrate PBXs
with their Office Communications Server deployment and enjoy the benefits of a streamlined
communications experience.

The path to this experience is dictated in part by customers’ current PBX
infrastructure.

Here we will exami
ne the main types of PBX and the options for integration with Office
Communications Server.

UC
-
Enabled PBX

The most capable PBX for interoperability with Office Communications Server has qualified with the
d
ual
f
orking specification and is fully enabled
for
the

co
-
existence deployment scenario.

This mechanism is
described in detail in an interoperability specification that is freely available to current and future partners
and is described in greater detail below.

The specification calls for native integr
ation via the well
-
defined
industry standards of the Session Initiation Protocol (SIP) and Real
-
time
Transport
Protocol (RTP) media.


As with
m
edia
g
ateways, the point of integration is the Mediation Server.

The Mediation Server provides
the functions des
cribed in sections above

and

play
s
a role in ensuring that calls forked from one element
are not forked back to the originating element, thereby
avoiding
an infinite loop.

UC
-
Capable PBX

PBXs that have qualified with the Direct SIP specification are capabl
e of implementing the stand
-
alone
deployment scenario.

Any customer
that
has deployed an IP PBX from a vendor
that
has
qualified
interoperability with Microsoft
may

be able to
achieve
Office Communications Server integration via a
software upgrade from tha
t vendor.

PBX vendors
that
support Office Communications Server will best be
able to advise customers on their upgrade options.



Page
21

of
47

Non

UC
-
Capable PBX

There are many PBX models in use today that are not built on an IP architecture; rather, they belong to
the

TDM (Time Division Multiplexing) generation of PBX.

Customers
that
have deployed PBXs of this
era
may

find that, depending on their vendor’s architecture, they
can
not
upgrade their
software to native
Office Communications Server interoperability.

There
will also be cases where a PBX vendor has chosen
not to participate in interoperability with Microsoft or has, for some other reason, no upgrade path for a
PBX that a customer owns.


These customers
can

cho
os
e
to
:

1.

Upgrad
e

their telephony infrastructure to
a UC
-
Enabled PBX
.

2.

Integrat
e

the existing PBX into the Office Communications Server deployment via the use of a
m
edia
g
ateway to communicate with Office Communications Server 2007.

For use
with the
c
o
-
existence scenario,

this requires that
the
g
ateway
is qu
alified for
d
ual
f
orking.

3.

Enabl
e

interoperability between an existing PBX and the Office Communications Server
deployment.

Here Office Communications Server is considered a peer PBX
,

and users are
homed on either the PBX or Office Communications Server, allowing calling between the two
systems.

4.

Replac
e

PBXs within the enterprise communications infrastructure with an Office
Communications Server stand
-
alone deployment over an appropria
te transition period
.


Further information on
m
igration
s
trategies is provided later
in

this paper.



Page
22

of
47

SIP Trunking Integration

This is a new feature for Office Communications
Server 2007 R2
.

The term “SIP
t
runking” is used in many
ways within the
industry.

Microsoft defines

“SIP
t
runking” as the use of SIP and RTP to pass telephony
traffic from the enterprise network edge to a network service provider over an IP connection (i.e.
,

without
traver
sing TDM or circuit networks).



OR



The value propo
sition of SIP
t
runking for an
Office Communications Server

2007 R2

customer is

an
opportunity to reduce
both
c
apital
expenditure

and
o
perational

expenditure
.

1.

Not having to deploy, maintain, and operate IP
-
PSTN gateways on
-
premise either regionally or at
remote offices
.

2.

Consolidation of d
ata and voice networks into one connection, significantly reducing the cost of
connectivity to the
s
ervice
p
rovider network
.

3.

Reduction of call degradation by reducing the number of conversions of the call from IP to TDM
(a
nd back)
;

note that most calls today are carried on a long
-
distance network over IP transports.

4.

Significant reduction in the cost of telephony calls offered by IP
t
elephony carriers
.

The value proposition of SIP
t
runking for
telephony service providers
is
the opportunity
to bring new value
to their IP customers and to define a servi
ces
-
b
ased UC value
-
proposition.

IP
-
c
entric servic
e providers
have a new channel for competition with the telephony incumbents.

Service
p
roviders can
qualify their
SIP
t
runking service products
for
Office Communication
s

Server

2007
R2
by meeting the requirement
s

of the Open Interoperability Program.

The q
ualified SIP
t
runking
service
products
can be found
at
http://techne
t.microsoft.com/UCOIP
.


Page
23

of
47

SIP Trunking
and
S
tandard
s

There have been several attempts to define standards for SIP
t
runking, most visibly
a

technical
recommendation for “
IP PBX / Service Provider Interoperability
” was created by the SIPconnect technical
working group of the
SIP Forum

in 2006.

In an attempt to address the adoption issue
s
, the SIP Forum
has launched a
new initiative to revis
e the SIPconnect specification.

The Board of the SIP Forum
recognized that Microsoft, as a leading vendor of unified communications solutions, could be a positive
pr
oponent of this effort.

In parallel, we realized that the

usefulness

of a SIP
t
runking feature would be
limited if
s
ervice
p
roviders did not support interoperability with Office Communications
Server 2007 R2
.

Therefore, we are working with the SIP Forum to define the new version of the SIPconnect standard as
well as offeri
ng our own
s
ervice
p
rovider test program via the Open Interoperability Program.

By making SIP
t
runking available to the millions of Office Communications Server users around the world,
we are expanding the market for
s
ervice
p
roviders
that
offer SIP
t
runki
ng, as well as helping to define a
standard
s based approach

for general adoption by the industry.

Unsupported Scenarios

T
o deliver Office Communications
Server 2007 R2

on schedule and with quality,
we limited the
scope
of

the release
and

defer
red

certain f
unctions and scenarios to later releases.

Branch Office Survivability

The Office Communications
Server 2007 R2

stand
-
alone scenario does not
now
provi
de

for the
survivable deployment of Office Communications Server in a remote or branch office (i.e.
,

remot
e from
the
servers running
Office Communications Server)
,
because
the issue of maintaining multi
-
modal
communications during an IP network failure has not
yet
been addressed.

In the event of a failure of the
w
ide
a
rea IP network, an Office Communicator endpoint that is remote from the core Office
Communications Server deployment will
be unable

to communicate with other clients and the PSTN.

This
is true for other clients and even media gateways that are on the same
l
ocal
a
rea
n
etwork, since all
communications are routed via Office Communications Server.


In planning for upcoming releases, we are evaluating c
ustomer feedback on requirements and
on the
optimal approach for covering this scenario
,

us
ing

our key precepts

of standards support and broad
interoperability.

Hosted Telephony

Office Communications Server features a deployment model that enables customers
that
purchase
hosted telephony functionality from
s
ervice
p
roviders to also purchase access to a hosted versi
on of
Office Communications Server 2007 and Office Communicator
2007
operating in a limited mode
. T
his
product is called HMC 4.5 (Hosted Messaging and Collaboration).

In some
s
ervice
p
rovider deployments,
HMC is integrated with hosted voice services via th
e CSTA/Remote Call Control mechanism described
above.


In Office Communications
Server 2007 R2
, this scenario will continue to be supported; however
,

the
direct integration of Office Communicator as a

softphone


is not yet available.

Although challenges

t
o
covering this scenario

remain

such as
integrati
ng

Office Communications Server

with
s
ervice
p
roviders


many

operational support systems

Microsoft
will
continue to
examine the situation

to

enable
the
deployment of this scenario

in the telephony network
.

Page
24

of
47

Non
-
Office Communicator Endpoint Support

As part of a customer’s
Office Communications Server

voice deployment, Microsoft recommends
telephony devices that carry the “Optimized for Microsoft Office Communicator” designation.

Microsoft
has certified these
devices for use with Office Communications Server and Office Communicator.

Certified devices offer plug
-
and
-
play installation, seamlessly integrate with Office Communicator, and
support wideband audio to deliver an optimal end
-
user communications experienc
e.

The current list of
certified devices can be found at:
http://technet.microsoft.com/en
-
us/office/ocs/bb970310.aspx
.


We understand that some IP phone vendors are offering IP pho
nes that are advertised as working with
Office Communications Server as native endpoints.

This is possible because Microsoft has published the
open

standards

based interoperability specifications for Office Communications Server and Office
Communicator as
a part of the Office Protocol Documentation found here:
http://msdn.microsoft.com/en
-
us/library/cc307282.aspx
.

Any IP phone
that is
advertis
ed

a
s

being
compatib
le

with Office Communicati
ons Server
but
that is not
listed at
http://technet.microsoft.com/en
-
us/office/ocs/bb970310.aspx

is not a certified device. Because
these IP phones have not gone through the certification process,
they

are neither guaranteed nor
supported by Microsoft to work with Office Communications Server or Office Communicator.

Further, they
may not offer the ben
efits of plug
-
and
-
play, wideband audio
,

and tight hardware/software integration of
certified devices.

Previous generation

telephony endpoints such as analog phones, fax machines
,

and modems can still be
connected to an existing PBX or IP

PBX, interoperatin
g with Office Communications Server 2007 as
specified in the scenarios detailed above.

Alternately, these devices can be connected to analog ports on
a certified gateway.

Over the next two years, the Unified Communications Group will be examining the
requi
rement for certain devices that are either mission
-
critical (e.g.
,

modems) or cannot be replaced by a
native Office Communicator endpoint (e.g.
,

elevator phones) to be supported natively within an Office
Communications Server deployment.

UDP as a SIP Trans
port

In IP telephony
, the most fundamental level of interoperability is in the IP transport protocol used to
convey SIP messages from one network element to another.

Generically, SIP can use (at least)
three

types of transport: UDP, TCP and TLS
(
this is
defined in the base SIP spec, RFC 3261
)
.

However, Office
Communications Server only supports TCP and TLS, with the latter being the default (actually, TLS runs
on TCP).

If a
thi
rd
-
party network element only supports UDP
,

there would be a fundamental discon
nect

with Office Communications Server
.

This is particularly problematic in the “SIP
t
runking” domain (see
earlier
discussion
), where many service providers currently only support UDP as a SIP Transport.

The lack of support for UDP is not an oversight

but
rather a conscious engineering decision based on the
suitability of UDP as a SIP transport.

There are three issues with UDP:

1.

It is not encrypted, so
users

can
not

ensure end
-
to
-
end security of SIP messages

over UDP
.
There is no shortage of opinions on the
security, or the lack thereof, of SIP (e.g.
,

Cert
®

Advisory).

As a text
-
based protocol that is human
-
readable
,

there are privacy/security issues of sending SIP

in clear.


Furthermore, UDP allows for easier spoofing of packets since
the
connection state
doesn’t need to be maintained (remember
SQL
Slammer
?

[
http://en.wikipedia.org/wiki/SQL_slammer
]
).

This is why customers are strongly recommended to
accept TLS over TCP as the default

SIP transport within the
Office Communications Server
network.

2.

UDP has a fundamental flaw for large SIP messages: the size of the UDP datagram is limited to
1
,
500 bytes, so a SIP message larger than that will be broken into two or more packets.

The
applic
ation layer (client or server) can receive the fragments out of order or a fragment could be
Page
25

of
47

lost (see
the third issue, below
).

Since
Office Communications Server
SIP messages tend to
contain various
XML

bod
ies, machine
-
generated unique IDs (e.g.
,

GRUU
s
),
ICE

candidate
attributes, etc.
,

they will normally span multiple packets.

3.

UDP is a "fire and forget" protocol: this is
,

the transport layer does not consider lost or delayed
packets.

The onus of tracking messages for which no response has been received (and the
generation of new requests) is left to the application layer
. T
his
leaves the application (the client
or the server) vulnerable to overload situations.

In bad network conditions, the best case scenario
is a call setup delay.

The worst case scenario is that the SIP network can reach a tipping point
where the session timers

are tripping for every transaction because the network elements are
busy generating, or responding to, "retries"

a "
retry storm
.
"

UDP presents challenges in the areas
of security, re
liability and scalability
and the SIP RFCs allow us to
choose from alternative SIP transports.

Within the
Office Communications Server

network
,

we use TLS
;

at the edge of the network
,

we can interoperate over TCP.

Page
26

of
47

Telephony Integration Features and Mechani
sms


This section describes telephony integration with Office Communications Server at a more technical level.

Office Communications Server 2007

Stand
-
A
lone Telephony Integration

As described above,
m
edia
g
ateways offer various levels of IP technology
support, not necessarily to the
full capabilities of an Office Communications Server deployment.

T
o enable interoperability with as many
vendors as possible
,

we have simplified the interface being offered to Office Communications Server via
the Mediation S
erver.

This is not to say that the number of functions available to a user in a PSTN call
has been restricted; rather
,

the combination of the call scenarios defined below addresses the
requirements of a
n

Office Communications Server deployment for PSTN int
eroperability.

Those who are interested in additional detail can find
Call Flow diagrams for the following features in
Appendix A.

Inbound Call

A call made from a PSTN network to a user of an Office Communicator endpoint will be routed by the
service provi
der to the trunk line at the edge of the enterprise network.

This trunk line will be attached to
the
m
edia
g
ateway
that
supports the telephony protocol being offered by the PBX or the telephony
service provider.

The
m
edia
g
ateway converts the “call alert”
to a SIP INVITE transaction and passes that
to the adjacent Mediation Server.

This SIP INVITE contains a range of information including the
telephone numbers of both the calling party and the called party.

The Mediation Server passes this SIP
INVITE to Off
ice Communications Server 2007
,

which performs a “reverse number lookup” (RNL) of the
called
-
party number and converts that to a SIP address (e.g.
,

sip:
user
-
alias@contoso.com
).

This allows
Office Communications Server 2007 to route the call as a normal SIP

transaction.


Office Communications Server 2007 applies routing rules defined by the network administrator and the
user in question, as well as determining if the user is online and available to take telephone calls.

Once
Office Communications Server 200
7 has identified one or more Office Communicator devices or external
PSTN numbers (cell phone, hotel room, etc.) as targets for the SIP INVITE, those devices are put in a
“ringing” state and the user has the option of taking the call on a given device or d
eflecting it to another
device or voice

mail.

Once the user has “picked up” the call, the device in question has voice media (i.e.
,

sound) routed to it by the Mediation Server.

At this point, the Mediation Server signals to the
m
edia
g
ateway that a
n

Office Communicator device has opened a voice channel
,

the caller stops hearing the
Page
27

of
47

ringing tone
,

and the call is connected.

Any Office Communicator device that was “ringing” and was not
“picked up” will receive a SIP CANCEL.

Outbound Call

A call made by
a user of an Office Communicator endpoint to a PSTN number is routed as a SIP INVITE
from the Office Communicator endpoint to Office Communications Server 2007.

It may be that the caller
intended to call another user of an Office Communicator endpoint, but

the routing rules within Office
Communications Server 2007, as well as the “presence” state (i.e.
,

willingness and ability to
communicate) of the
called party
, cause the target of the SIP INVITE to be converted from a SIP address
(e.g.
,

sip:user
-
alias@con
toso.com
) to a telephone number (e.g.
,

sip:+15000100@contoso.com
).

At this
point, Office Communications Server 2007 routes the SIP INVITE to a Mediation Server that provides
coverage for this country/area code.

Mediation Server forwards the SIP INVITE to t
he appropriate
m
edia
g
ateway
, which

turns the SIP INVITE
in
to a traditional telephone call that is routed via a trunk line to the
PSTN.

The
called party

either answers the call or the call is routed to voice

mail.

At that point, the
telephony network signa
ls to the
m
edia
g
ateway that voice media should start to flow
,

and this message
is relayed back to the caller’s Office Communicator endpoint and the call is connected.



Call Forward
and
Transfer

A user of an Office Communicator endpoint has the option of

forwarding calls either on a selective basis
or for all calls.

This call redirection is done by Office Communications Server 2007 substituting a different
SIP address
for
the called party and therefore the media gateway is unaware that the call is being
rerouted.

Page
28

of
47



A user of an Office Communicator endpoint may also transfer a call to another party.

However, the
mechanisms used within Office Communications Server to facilitate transfers (e.g.
,

SIP REFER) are not
uniformly supported across the range of ava
ilable media gateways.

Therefore, Mediation Server executes
transfers by putting the media gateway (and therefore the PSTN caller) “on hold” for a brief moment while
the call is transferred within the network.



Conferenc
e

Escalating a two
-
party call
(where one party is a PSTN caller) to an ad

hoc
,

multi
-
party call is simple and
intuitive for a user of an Office Communicator endpoint.

In simple terms, Office Communicator 2007
establishes a conference on the

Office Communications Server
conference serve
r and transfers the call
in progress to the conference server (see Call Transfer
,

above).

For conference calls involving other
participants
who
are only available on PSTN, the conference server “dials out” to the PSTN via the
Mediation Server as a simple o
utbound call.

Page
29

of
47




Page
30

of
47

Office Communications Server 2007

Co
-
e
xistence Telephony Integration

With the notable exception of a

customer location that has no current telephony infrastructure (such as a
new building or office space),

a customer considering an Office

Communications Server deployment will
already own a PBX
that
is used for PSTN connectivity and intra
-
office extension dialing.

The range of
features described below represents the full set of functions required for a streamlined experience as
described in the Office Communications Server 2007
co
-
existence scenario described above.

Where
these functions are not available in the sce
nario, this will be made clear.

Those who are interested in additional detail can find
Call Flow diagrams for the following features in
Appendix B.

Inbound Call

A user of an Office Communicator endpoint is able to take an inbound PSTN call as per the
m
edia

g
ateway Inbound Call scenario described above.

However, the main difference is that the PBX forks the
call to both the called party’s Office Communicator device(s) and to the PBX extension that is associated
with that user

all of the called party’s endpoi
nts start to “ring
.


The called party has the option of picking
up the call on either the telephone or any of the UC devices.

Once the call has been picked up on one
endpoint, the remaining endpoints stop ringing.

In the case of the call being picked up on

the telephone,
the PBX generates a SIP CANCEL to close the SIP INVITE transaction with the Office Communicator
devices.


When a PBX is deployed alongside the Office Communications Server 2007
s
tand
-
alone scenario, the
call forking mechanism is not invoke
d.

Outbound Call

A

user of an Office Communicator endpoint
is able to place a PSTN call as per the
m
edia
g
ateway
Outbound Call scenario described above; the only difference is that the PBX is acting as the media
gateway to the PSTN.

If the call is made to
another user of an Office Communicator endpoint, Office Communications Server
2007 forks the SIP INVITE to both the called party’s device(s) and to the PBX extension that is associated
with that user

all of the called party’s endpoints start to “ring
.


The

called party has the option of picking
up the call on either the telephone or any of the Office Communicator devices.

(Of course, the device
does not have to be physically adjacent to the phone
;

the user could be “roaming” in a hotel room in a
Page
31

of
47

different c
ountry.)

Once the call has been picked up on one endpoint, the remaining endpoints stop
ringing.

In the case of the call being picked up on an Office Communicator device, Office
Communications Server 2007 generates a SIP CANCEL to close the SIP INVITE tran
saction with the
other devices and the PBX.


When a PBX is deployed alongside the Office Communications Server 2007
s
tand
-
alone scenario, the
call forking mechanism is not invoked.

Call Forward
and
Transfer

Call forwarding works as described in the
m
edia
g
ateway
Call Forward and Transfer
section above.

The
difference is that if the call is forwarded to another user of an Office Communicator endpoint, the call
forking mechanism described above (if available) is initiated.



Call transfer works as described in the
m
edia
g
ateway
Call Forward and Transfer
section above.

The
difference is that if the call is transferred to another user of an Office Communicator endpoint, the call
forking mechanism described above (if available) i
s initiated.

Page
32

of
47



Conferenc
e

In the Office Communications Server 2007
co
-
existence scenario, conference calls are established on the
element that initiates the conference.

If Office Communicator 2007 establishes a conference on the Office
Communications
Server Conferencing Server, telephones are enrolled in the conference via “dial
-
out” as
an outbound call leg as described above.

If a PBX user initiates a PBX conference (e.g.
,

a third
-
party
conference or “meet me” conference)
,

a user of an Office Communic
ator endpoint can join or be “dialed
-
in” to the conference as a normal inbound or outbound call leg as described in the
m
edia
g
ateway
Conference
section above.


Do Not Disturb

If a user of an Office Communicator endpoint sets a “Do Not Disturb” rich prese
nce status, the client will
reject the call with a SIP 480 and the SIP transaction will be terminated.

A SIP 480 will be sent to the PBX
to stop the user’s telephone from ringing and deflect the call to
v
oice

mail.


Page
33

of
47

Migration Paths and Integration Strategi
es


Building the Foundation

There are certain prerequisites for an Office Communications Server deployment that will enable the
migration to telephony integration:

1.

Provid
ing

a single identity and a single directory for the organization by deploying Active
Directory
®

service,
including the required schema extensions
.

2.

Enabl
ing

rich presence and instant messaging for the organization by deploying or migrating to
Office Communica
tions Server 2007
,

including Office Communicator 2007
.

3.

Making a strategic decision on the required deployment scenario in conjunction with a similar
decision on corporate voice

mail
.

The third step is
critical because there
are a range of factors that will

influence this decision, including:



Financial, including current and future operating expenses as well as capital budget



Corporate goals and expected ROI for unified communications deployment



Current technology investments, especially those in telephony e
quipment

The scenario and feature descriptions provided elsewhere in this document will provide an initial guide on
deployment scenarios; however
,
customers are encouraged to fully familiarize themselves with the
available VoIP documentation for Office Com
munications Server 2007

(
visit

http://technet.microsoft.com
)
.

Of particular note are deployment decisions for Microsoft Exchange Server 2007 with Unified Messaging
option:



In the Office Communications Server 200
7
c
o
-
existence scenario, Exchange Server 2007 with
Unified Messaging is only supported as a PBX voice

mail option
because
this scenario assumes
that voice

mail is provided by the PBX.



In the Office Communications Server 2007
s
tand
-
alone scenario, Exchange
Server 2007 with
Unified Messaging is integrated with
Office Communications Server 2007
.

PBX to Office Communications Server 2007 Co
-
existence

The Office Communications Server 2007
co
-
existence scenario requires that the PBX be UC
-
enabled.

The issue of
UC
-
enablement has been discussed in sections above and the options for a given PBX
should be evaluated carefully on a cost/benefit basis.

Once it has been determined whether a PBX can
be UC
-
enabled, customers are then able to evaluate their options
about

u
pgrading their PBX
infrastructure vs. installing media gateways.

(
Note that some PBXs, particularly those that do not support call forking, cannot be integrated
in the
Office Communications Server 2007
c
o
-
existence scenario.

These PBXs can, however, be par
tially
integrated
in
the Office Communications Server 2007
s
tand
-
alone scenario discussed in the next section.
)

A
five
-
track project plan can then run in parallel:

1.

Office Communications Server implementation

Page
34

of
47

2.

PBX UC
-
enablement (if required)

3.

Exchange Server
2007 implementation (if required)

4.

Media gateway deployment (if required)

Once task 1 is complete, users can be provisioned on Office Communications Server 2007 in rich
presence/instant messaging mode as a precursor to linking the PBXs to Office Communicati
ons Server
2007.


PBX to Office Communications Server 2007 Stand
-
A
lone

At face value, this migration path is one of the simplest
. A

three
-
track project plan can run in parallel:

1.

Office Communications Server implementation

2.

Exchange Server 2007 implementatio
n

3.

Media gateway deployment

Once the infrastructure is production
-
ready, users can be provisioned on Office Communications Server
in rich presence/instant messaging mode as a precursor to migrating them from the PBX.

The migration
of users can be initiated
in phases until the PBX has no extensions left on it: the PBX can then be
decommissioned.

(
If the intent is to maintain the PBX for a subset of users
,

clearly the PBX is not
decommissioned and the PBX users remain essentially unaffected.
)

Moving telephone
extensions from a
PBX to Office Communications Server requires that

any

Direct Inward Dial (
DID
)

numbers and trunks are
r
e
-
homed on the media gateway(s) or through a SIP
t
runking
service
provider.

Office Communications Server 2007 Co
-
existence to

Office
Communications Server 2007 Stand
-
A
lone

This migration path is used when Office Communications Server 2007
co
-
existence is used as a stepping
stone to Office Communications Server 2007
s
tand
-
alone.

Office Communicator 2007 users

will already
be
familiar wit
h the paradigm

the only change is that they will start to use Office Communicator
telephone devices and Exchange Server 2007 Unified Messaging instead of PBX phones and voice

mail.

A
two
-
track parallel project plan is required
:

1.

Exchange Server 2007 impleme
ntation

2.

Media gateway deployment (if media gateways were already deployed as part of Office
Communications Server 2007
c
o
-
existence, a carefully managed repurposing of these gateways
is required as their role
is changed
in the network)

Once the full Office

Communications Server 2007
s
tand
-
alone infrastructure is production
-
ready, users
can migrate to Exchange Server 2007 Unified Messaging and their Office Communicator telephone
device in phases until the PBX has no extensions left on it
;

the PBX can then be

decommissioned.

Moving telephone extensions from a PBX to Office Communications Server 2007 requires that
any
DID
numbers and trunks are re
-
homed on the media gateway(s).

Page
35

of
47

Customer Location That Has No Current Telephony Infrastructure
to
Office Communicati
ons Server 2007 Stand
-
A
lone

This migration path is the simplest

one. A

three
-
track project plan can run in parallel:

1.

Office Communications Server implementation

2.

Exchange Server 2007 implementation

3.

Media gateway deployment

Once the infrastructure is product
ion
-
ready, users can be provisioned on Office Communications Server
2007.

Page
36

of
47

Summary
and
Conclusions


After 100 years of development, business telephony is as complex as it is pervasive.

The
Microsoft
u
nified
c
ommunications initiative is designed to combine
20
th
-
c
entury business telephony with 21
st
-
c
entury business communications mechanisms such as:



P
erson
-
centric, context
-
driven calling



R
ich presence



I
nstant messaging



V
ideo calling and conferencing



U
nified messaging



A
d

hoc
,

multi
-
party, multi
-
modal conferencing

Partners are considering the role that their solutions play in the unified communications era, and
Microsoft
telephony integration strategy is fundamentally partner
-
centric
.

Our approach to telephony integration with
Office Communications Server is dependent on the partner ecosystem and partner
qualification
programs
such as
the
Unified Communications

Open Interoperability
Program
.

Microsoft has
invested in broad
partnerships in the telephony market to ensure that cus
tomers can integrate the systems
that
they
depend on today with the systems that they will depend on tomorrow.

Customers have made significant investments in their telephony infrastructure, and we understand that
changes in mission
-
critical systems cannot
be made overnight.
We hope that the reader will now better
understand

the challenges

as well as the

options and solutions that we are offering
,

and that this
paper
will provide the impetus
for our future customers and partners
to further investigate and
ta
ke advantage of

the considerable benefits to be realized from telephony integration with Office Communications Server.

Page
37

of
47

Appendix
A
:

Office Communications Server

Stand
-
A
lone Scenario


Call Flows


Inbound Call

Office Communications Server 2007

R2

takes an inbound call from PSTN

and negotiates

early media.
An
incoming Invite with SDP from the Basic Media Gateway must have a Supported header with the 100rel
option.

The Mediation Server will immediately negotiate early media for that call via a relia
ble provisional
message
.



Page
38

of
47


Outbound Call

Office Communications Server 2007 R2 makes an outbound call to PSTN

and negotiates early media
.




Page
39

of
47

Call Placed on “Hold”

Office Communications Server places a

call in progress on “hold” and takes the call off “hold
.


Note that
this mechanism is used to facilitate all mid
-
call transactions, including Transfer and Escalate to
Conference.

This approach simplifies the Office Communications Server interface to ensur
e the broadest
possible coverage of the
m
edia
g
ateway market.


Page
40

of
47

Appendix
B
:

Office Communications Server

Co
-
e
xistence Scenario


Call Flows

For the purposes of brevity, only an illustrative subset of features and related call fl
ows is provided.

Make a Call

Office Communicator 2007 dials an external phone number.


Page
41

of
47

Answer a Call

Office Communicator calls and the telephone answers
.


Page
42

of
47

Forward

Office Communicator calls,
called party has
set Office Communications Server to “forward always”
and
the far
-
end PBX endpoint answers
.


Page
43

of
47

Transfer

Office Communicator in a call with a telephone initiates a single
-
step transfer to another Office
Communicator

user.


Page
44

of
47

Conference

Office Communicator in a two
-
party call with a telephone escalates to a multi
-
party call with another
telephone user.


Page
45

of
47

Do Not Disturb

Office Communicator calls another Office
Communicator user who has set “Do Not Disturb
.



Page
46

of
47

Glossary

CSTA


Computer Supported Telecommunications Applications

refers to

an abstraction
layer for telecommunications applications that is independent of underlying
protocols.

DID

Direct Inward Dial
ing

ICE

Interactive Connectivity Establishment

is

an emerging IETF standard that deals
with the negotiation of real
-
time media packet traversal across NATs and
firewalls.

IETF

The Internet Engineering Task Force (
www.ietf.org
) is a large, open, international
community of network designers, operators, vendors, and researchers concerned
with the evolution of Internet architecture and the smooth operation of the
Internet.

It is open t
o any interested individual.

IP

Internet Protocol

is

the standard that controls the routing and structure of data
transmitted over the Internet.

Media
g
ateway


A translation device used to connect disparate communications networks.

In this
paper, we use th
is term to mean a device that connects the PSTN or a PBX with
unified communications networks.

NAT

Network Address Translation

is

an IETF standard that defines the separation of
internal or private IP addresses from external or public IP addresses
.

PBX

Private Branch Exchange
,

an enterprise
-
class telephony switch owned and
operated by a company and hosted on its own premises, typically one per office
or branch location.

Some of these switches are operated by
s
ervice
p
roviders on
behalf of enterprises; ho
wever
,

with the advent of VPN, the phys
ical location of
the switch is
becoming less important.

(PABX in some countries
.
)

PSTN

Public Switched Telephone Network
,

a traditional telephone network that
uses
protocols such as SS7, TDM,
and
QSIG.

A PSTN is

a
digital network but not
an
IP
-
based network.

QS
IG



A set of ISDN
-
based protocols used for signaling between PBXs.

Page
47

of
47

RFC

“Request for Comments
,
” an IETF
-
ratified standards document that defines
certain technologies and/or protocols.

E.g.
,

RFC 3261,
which is
the “root” RFC
for a growing range of standards that define the SIP protocol.

ROM


Read Only Memory

refers to

a class of storage media used to store firmware in
computers and similar devices (e.g.
,

m
edia
g
ateways).

RTAudio

A
n adaptive

speech codec that is
designed by Microsoft for real
-
time, two
-
way
VoIP applications, RTAudio is
used
in

Microsoft
unified communications products
such as Microsoft Office Communicator
.

RTP


Real
-
t
ime
Transport
Protocol provides end
-
to
-
end network transport functions
suitable
for applications transmitting real
-
time data, such as audio or video, over
multicast or uni
cast network services. (S
ee RFC 1889)

SIMPLE


The Session Initiation Protocol (SIP) for Instant Messaging and Presence
Leveraging Extensions is a set of extensions t
o the SIP protocol that enables the
sending and receiving of presence and instant messaging
traffic. (S
ee RFCs
3265
and
3428)

SIP


The Session Initiation Protocol is an application
-
layer control (signaling) protocol
for creating, modifying, and terminating

sessions with one or more participants.
These sessions include Internet telephone calls, multimedia distribution
, and
multimedia conferences. (S
ee RFC 3261 et al.)

SRTP

Secure Real
-
Time Protocol

is used to encrypt media packets to facilitate private
conve
rsations.


TCP


Transport Control Protocol defines the transmission of data packets across an IP
network.

TLS

Transport Layer Security

is

a standard
encryption
protocol used to
facilitate more
secure signaling.

UC


Unified Communications

UCG


Unified Communications Group
at

Microsoft

UDP

User Datagram
Protocol

VoIP


Voice over IP

refers to

the use of IP networks to carry telephony traffic as well as
the technology required to facilitate voice traffic on IP networks.