Whitepaper: Understanding IBM Lotus Sametime and Unified Telephony

Understanding IBM® Lotus® Sametime®
Unified Telephony

Todd Page
IBM Software Group
ISV and Partner Enablement for Lotus Sametime
Advisory Software Engineer: WPLC.Real-time & Team Collaboration Software

Jeff Reser
IBM Software Group
Product Manager for Unified Communications & Collaboration
IBM BPM Marketing, SOA and WebSphere

November 2008

© Copyright International Business Machines Corporation 2008. All rights reserved.

Abstract: This white paper defines the IBM® Unified Communications and Collaboration
(IBM UC2™) vision of making it easy for you to find, reach, and collaborate with others
through a unified user experience. This strategy is implemented by means of the IBM
Lotus® Sametime® Unified Telephony (SUT) software offering that is designed to make
it easy for you to access and manage telephone communications from inside the Lotus
Sametime or Lotus Notes® client.

We examine the rich set of SUT features and provide an in-depth technical analysis on
how you can add SUT to existing heterogeneous PBX environments without having to
replace legacy telephony equipment. Due to the variation of possible deployment
options, we cover each scenario from a high level, focusing on how each decision
affects the enterprise, down to the individual call flows.

This paper provides supplementary information to other published IBM documents that
further describe Lotus Sametime and the IBM UC2™ vision.

1

Contents
1 Leveraging unified telephony in solutions ............................................................. 2
1.2 IBM’s vision ............................................................................................................. 3
2 Features of IBM Lotus Sametime Unified Telephony .......................................... 3
3 Fundamentals of telephony integration ................................................................. 7
3.1 Providing value to Sametime users........................................................................... 8
4 Architectural overview ............................................................................................ 9
4.1 Telephony application server (TAS)....................................................................... 11
4.2 Telephony control server (TCS) ............................................................................. 12
4.3 Gateway integration ................................................................................................ 13
5 Sizing an SUT environment .................................................................................. 13
5.1 Integrating SUT with a third-party TCSPI adaptor................................................. 15
6 SUT call flows......................................................................................................... 15
6.1 Inbound call flow .................................................................................................... 15
6.2 Outbound call flow ................................................................................................. 17
7 Deploying SUT ....................................................................................................... 18
7.1 Option 1: Repurpose existing numbers to new unified numbers............................ 18
7.1.1 Deployment Option 1 call flows ...................................................................... 19
7.2 Option 2: Configure telephony gateway to use source-based routing ................... 22
7.3 Option 3: Provide everyone a new unified number to replace desktop number.... 25
8 Telephony survivability ......................................................................................... 27
9 Provisioning users .................................................................................................. 27
10 Leveraging Sametime SDKs.................................................................................. 27
10.1 Sametime Connect Web API Toolkit ................................................................... 27
10.2 Sametime Helper Toolkit...................................................................................... 28
10.3 Sametime Unified Telephony REST APIs ........................................................... 28
10.4 Sametime Connect Toolkit ................................................................................... 28
11 Conclusion .............................................................................................................. 29
12 Appendix................................................................................................................. 29
13 Glossary of terms ................................................................................................... 30
14 Resources ................................................................................................................ 31
15 About the authors .................................................................................................. 31

1 Leveraging unified telephony in solutions
The goal in many unified communication solutions today is to leverage IT and telephony
assets to improve collaboration and business processes. The convergence of voice,
video, and data on IP networks is fundamentally transforming the way people work. To
be competitive, enterprises must speed up delivery of products and services, enhance
customer service, and accelerate decision making.

2

Companies are finding that unifying telephone communications with real-time
collaboration tools and integrating these new communications capabilities into business
processes can shorten cycle times and time to market.

Because these new communications capabilities must be part of a comprehensive,
enterprise-wide strategy, IT and telecommunications managers are working together to
identify and implement unified communications solutions that leverage and extend their
existing IT and telephone systems as well as support their longer-term strategies.

1.2 IBM’s vision
The IBM Unified Communications and Collaboration (IBM UC2™) vision is to help clients
become more innovative, responsive, and agile by making it easy for people to find,
reach, and collaborate through a unified user experience. IBM provides the essential
software, services, hardware, and strategic alliances that enterprises need to connect
people to applications, data, and to one another–virtually anytime, anywhere.

IBM Lotus Sametime software includes many communications and collaboration
capabilities out of the box; for example, instant messaging (IM), presence and location
awareness, VoIP voice chat and conference calls, point-to-point video, and Web
conferencing capabilities.

The Sametime software integrates with major office productivity suites from IBM and
Microsoft®, as well as with enterprise applications. It provides an open and extensible
Eclipse-based software platform that IBM Business Partners have used to develop a
wide variety of telephony, video conferencing, and business application extensions to
enhance the value of the software.

2 Features of IBM Lotus Sametime Unified Telephony
IBM Lotus Sametime Unified Telephony (SUT) software is a new offering that is
designed to make it easy to access and manage telephone communications from inside
the Lotus Sametime or Lotus Notes client. The SUT offering extends the value of Lotus
Sametime software as a platform for communications by providing a rich, unified
communication and collaboration experience to users, allowing them to seamlessly and
simply integrate voice, video, and telephony capabilities.

This is particularly beneficial for companies with multiple private branch exchange (PBX)
environments. From a line-of-business perspective, integrating telephony as part of a
company’s unified communications platform can help improve business processes by
improving collaboration and speeding decision making.

However, the telephony environment to be integrated may include tens or even
hundreds of telephone systems as a result of decentralized decisions in divisions,
countries, branch offices, or through acquired companies. Therefore, when implementing
unified communications systems, IT and network managers are looking for solutions that
can leverage and extend these disparate, mixed, multi-vendor communication systems.

On the frontend, SUT enables a unified user experience and includes a unified number
service, integrated soft phone, presence awareness, and sophisticated call

3

management. On the backend, it serves as a middleware layer to simplify connecting
into multiple PBX systems and audio conferencing systems.

Each of the following capabilities of Lotus SUT software is designed to be intuitive and
easy for users to access telephony functionality from within the Sametime client:

Soft phone. Users can initiate and manage phone calls through their PC microphone
and speakers, using the Lotus SUT embedded soft phone (see figure 1).

Figure 1. SUT embedded soft phone

Click-to-call, Click-to-conference. Starting a call is intuitive; people can simply select
names from the Contacts list or QuickFind, enter a phone number, or initiate a call
directly from an instant message within Sametime, Notes, Microsoft® Outlook or
Microsoft Office products.

Telephony presence. At a glance, users can see telephone status (for example, on the
phone, off the phone) along with online presence status (Available, Away, In a meeting,
Do not disturb, etc.), making it easy to know whether it is appropriate to initiate a real-
time conversation (see figure 2).

Figure 2. Telephony conference attendee presence is displayed

QuickFind. Simply type a name or number, and Sametime automatically does a type-
ahead search of the enterprise directory (see figure 3).

Figure 3. QuickFind

4

Device management. Users can have a single unified phone number that allows calls to
be routed automatically to virtually any device in almost any location (see figure 4).

Figure 4. Device management

Incoming call management. Users can easily set rules and preferences for where their
calls will go and take action (for example, redirect to a mobile phone). Since Lotus
Sametime software provides inherent presence and location awareness, Lotus SUT
software can automatically set the preferred device based on the user’s availability and
location status (see figure 5).

Figure 5. Define sophisticated yet easy-to-understand rules for incoming call management

Select a status

Select a location Select a person the time
Select Select a Device:
Any registered
phone number or
device

Secondary Rules:
If first option fails,
define second or
third option

5

Incoming call notification. SUT notifies the Sametime client whenever there is an
incoming call, so the user has the opportunity to take the call, deflect it to another
device, or let the call go to voicemail (see figure 6).

Figure 6. Incoming call notification

Unified user experience. The same set of functionalities and user experiences can be
delivered to users, regardless of what type of phone system they are connected to or
whether they use Macintosh, Windows®, or Linux®. Users can access and manage their
communications from inside either a Sametime or a Notes client.

Other key features such as the ability to make a call and access telephony presence is
also included from within Microsoft Outlook, Microsoft Office, and Sharepoint
applications, eliminating the need for extensive training or a separate deployment.

SUT lets users see whether a person is online and available, and they can click-to-
collaborate through an instant message or a live phone call—all from within the context
of any of these applications. In addition, Sametime and SUT software allow
communication and collaboration services to be inserted into the familiar desktop
applications with which users are already familiar—like email or business applications
such as SAP systems.

SUT software provides a unified user experience that combines the immediacy of IM
with telephone capabilities, right on your desktop. You get one external phone number
and the capability to route calls to multiple physical devices, depending on rules you
have personally set. You also get a call experience that combines the visual
collaboration tools of IM and the emotional and social impact of voice communications.

Essentially, a Contacts list has everyone on speed dial; you can see whether colleagues
are available and reach them more reliably and effectively, without needing to look up
their numbers (see figure 7). The ability to dial one number and reach someone on any
device, no matter where they are located, makes communications more effective for
people who are on the move.

6

Figure 7. People on a Contacts list can be easily contacted in numerous ways

To support the client functionality, the backend middleware layer in SUT provides
connectivity to multiple telephone systems [both IP PBX and legacy Time Division
Multiplexing (TDM) phone systems] while delivering the same rich set of capabilities for
supported users through one client, regardless of which telephone system users access.

The middleware enables companies—even if they have not completely migrated to IP
telephony—to deliver the value of unified communications to virtually all users. This is in
contrast to other offerings that (1) require multiple clients for soft phones, or (2) provide
desktop access to telephone features that work only with a specific vendor’s PBX, or (3)
require a full migration to IP telephony before delivering a common set of unified
communications and collaboration capabilities.

3 Fundamentals of telephony integration
Lotus Sametime software’s open unified communications platform is designed to provide
flexibility and options for customers, IBM Business Partners, and corporate IT
developers to extend Sametime software’s native functionality. Sametime software
includes comprehensive software development toolkits (SDKs) to embed real-time
capabilities including presence, IM, and telephony capabilities into business applications
such as e-commerce sites, portals, help desks, and enterprise applications like sales
force automation.

Vendors can use the Sametime Telephony Conferencing Service Provider Interface
(TCSPI) toolkit to integrate with a wide variety of Session Initiation Protocol (SIP) or
legacy PBXs, audio conferencing bridges, and video conferencing solutions.

7

For example, telephony service providers can use the TCSPI toolkit to create server-side
plug-ins that let them hook into their backend PBX systems, to provide telephone call
management and audio controls. The features (for example, click-to-call) are surfaced in
the Sametime Connect and Web conferencing clients to ensure a consistent user
experience.

The Sametime Standard UI provides elements for telephony such as soft phone UI
elements and aggregated presence that can be used by partners and developers. The
Sametime Standard application programming interface (API) provides a publishing
interface to push telephony presence from PBXs to the Sametime Presence server,
allowing telephony presence to be viewable in the client.

Leading providers of telephony and audio/video solutions currently deliver these
integrated capabilities for Lotus Sametime software:

• Click-to-call and call management capabilities. Select one or multiple names
from the Contacts list and initiate a call. You can also receive alerts for incoming
calls, take action (for example, redirect to a mobile phone), and view incoming,
outgoing, and missed calls–all from one desktop.
• Aggregated telephony presence. See whether a contact is currently on the
phone or is available.
• Click-to-conference. Select one or multiple names from the Contacts list and
initiate a conference call.
• Web conferencing integration. Click a button to have the audio feature call you
to join a Web conference. Web conference moderators have sophisticated UI
options to control the telephony, and all participants can visually see who is
speaking.
• Multimedia conferencing plug-ins on the client. Launch an audio or video
conferencing session with one or more participants.
• Unified messaging plug-ins on the client. Receive voicemails and then replay,
delete, or forward them from within your Notes or Sametime client.

3.1 Providing value to Sametime users
Let’s now consider these three basic scenarios for providing value to Sametime software
customers:

Scenario 1. Strategically homogeneous PBX customers, in which the customer is
committed to deploying a largely single-vendor environment.

Scenario 2. Strategically heterogeneous PBX customers, in which the customer has
made a strategic decision to support multiple IP and TDM PBX providers within their
corporate network. Also, the customer has no intention or desire to migrate to a single-
vendor environment in the near future.

Scenario 3. Migrating customers, in which the customer is moving to a particular
vendor’s IP environment and requires the ability to deliver Sametime UC capabilities to
all users before migration is complete.

In Scenario 1, the value propositions could include increased user productivity and
responsiveness with tight integration between Lotus Sametime (presence and

8

collaboration) and the vendor environment (IP telephony, audio conferencing, unified
messaging), providing superior user functionality and experience.

The opportunity to leverage SUT, however, is minimal so long as the vendor plug-ins
can match or exceed SUT capabilities like (1) embedded soft phone, (2) incoming call
management rules based on Sametime availability and location, and (3) incoming
Sametime call alerts that allow users to accept, forward, and deflect calls to other
devices.

In this technical approach, vendor plug-ins and connectors provide click-to-call, click-to-
conference, aggregated presence, and integrated voicemail while leveraging the unique
features of the vendor environment.

In Scenario 2, on the other hand, the opportunity to leverage SUT is large and
compelling. Technically, SUT can be used to connect Sametime to all installed PBXs
within the customer network. For vendor-enabled users, you can still add plug-ins, if
appropriate.

Benefits for the customer include allowing global Sametime/UCC deployments to
support regional PBX decisions while providing a competitive advantage in supporting
the migration of users to a vendor’s IP PBX over time, without changing the end-user
interface. SUT also provides a way for vendors to “get in the door” with accounts that
may have been inaccessible in the past.

Finally, in Scenario 3, the opportunity to leverage SUT is also great. Technically, SUT is
used to connect Lotus Sametime to a vendor’s PBX and to legacy TDM as the IP
migration is taking place. Customers who are moving to IPT can achieve wide end-user
value sooner, during the migration rather than at the end. The vendor in this case can
demonstrate return on existing and ongoing investment in IPT, thus avoiding “rip and
replace”.

4 Architectural overview
SUT is a middleware layer that uses open standards and published interfaces to connect
with an existing telephony infrastructure and provide telephony services and events to
the Sametime client. It is designed to provide a highly flexible, scalable, and reliable
system that can integrate with nearly any telephony system.

Figure 8 shows a sample multi-vendor deployment, in which an existing Sametime
environment is represented in yellow, along with the new SUT components in blue.
Starting from the top left-hand corner, you can see the standard Eclipse-based
Sametime Connect clients that can be automatically provisioned with new SUT plug-ins.

These client plug-ins provide a number of enhancements to the existing telephony
capabilities of Sametime Connect 8.0, including an integrated SIP-based soft phone that
enables you to call other PCs or telephone endpoints, using your computer as your
telephone or video device.

Next, you have an existing Sametime 8 server infrastructure that requires very little
change other than a minor server update.

9

Figure 8. Multi-vendor deployment architecture

SAN
Telephony
Application Enterprise Directory
Sametime Sametime 8 Telephony
Server
Connect server
VP VP Application
Server 2 x IBM System x3550
Telephony
Plug-ins

Soft phone Telephony
Control
SIP Telephony
Server
Control
Server 2 x IBM System x3650T

SIP
SIP SIP
PSTN Gateway
SIP Gateway TDM PBX
PBX

PSTN

The pieces in green and grey in figure 8 are the existing components of a telephony
infrastructure that remain unchanged. Additional gateway components may need to be
added, depending on the current telephony infrastructure and what deployment model is
chosen (this topic is covered in the Deploying SUT section below).

Aside from the Sametime server and Connect client, there are two new logical SUT
middleware components that sit between your Sametime server community and
telephony infrastructure:

• The first component is the Telephony Application Server (TAS). It’s
responsible for providing telephony services to Sametime clients, including voice
presence aggregation, call management, a rules engine for call routing, voice
calling and conferencing capabilities.

• The second component is the Telephony Control Server (TCS). It’s a carrier-
grade telephony appliance that’s responsible for connecting to Media Servers,
SIP Conference Bridges, SIP Softswitches, SIP Gateways, and TAS’s. The TCS
provides the unified number facility, also known as a "one-number service", that
lets you have a single telephone number for routing calls to any of your telephony
devices.

TCS is added to the telephony call path and can process calls coming in from various
trunks and/or route calls to various trunks via a numbering plan configuration. This
section provides an in-depth look at the individual components of the TCS and TAS,
along with the full range of SUT integration options inside an existing telephony
infrastructure.

10

4.1 Telephony application server (TAS)
As mentioned above, TAS is responsible for providing telephony services to Sametime
clients and interfacing with several backend communication systems in conjunction with
the TCS component.

The physical TAS server is a container that’s responsible for hosting a number of
different applications. Each application provides core services related to interfacing with
the Sametime client, TCS server, or other applications that leverage the SUT Telephony
SDK (see figure 9).

Figure 9. TAS architecture and functions

The primary responsibilities of TAS include:

• Running all application logic that manages the workflow associated with routing
incoming calls, so that they are always routed to the preferred device.
• Firing all call-related events to the client. So if the Sametime client is online, the
TAS server will send a pop-up that lets you see your preferred device or deflect
the call to another device.
• Providing personal call history records of all calls that you make and receive
• Handling all call control and flow control for audio conferences
• Managing all user and configuration data. Some data is provisioned into the
system as part of the initial configuration, while other data is managed by the
user.
• Providing limited audio conferencing capability. Primary use case is for small ad
hoc meetings, and this capacity is configurable.
• Provisioning remote administrative features

The SIP Registrar on TAS is used by the embedded soft phone to register itself. TAS
servers are deployed with at least one warm standby per cluster and each TAS server

11

monitors a set of up to 15,000 users on the system. Affinity is established when a person
logs onto the Sametime server with an SUT client. Once the Sametime server notifies
TAS of the event, TAS will open a channel to the Connect client that enables the SUT
features.

SUT users can provision as many numbers as they like, and TAS can ring any device–
either simultaneously or selectively–based on rich presence and on user rules that allow
you to determine what device you want to ring according to any combination of time,
location, and presence status.

For example, if your preference is set for the desk phone to ring from 9:00 AM to 5:00
PM, then TAS will instruct the PBX to ring the desk phone. If your presence indicates
that you’re out of the office and not at home, then TAS will ring your cell phone.

4.2 Telephony control server (TCS)
The TCS is installed as an appliance in full duplex mode and runs on specific IBM 3650T
hardware to provide certified carrier-grade reliability. Each pair can host up to 100,000
subscribers. The TCS is responsible for receiving the incoming CSTA requests from
TAS and using the dial plans to route calls to the appropriate device. It also provides the
unified number service and handles all incoming call routing for the unified number.

At a conceptual level, the TCS container is a back-to-back user agent (B2BUA) with a
PBX abstraction layer that allows it to work with TAS (see figure 10).

Figure 10. TCS architecture

PBX Abstraction Layer

SIP B2BUA

PSTN Gateway
Gateway
IP PBX
Non-SIP PBX

PSTN

The IETF standard (RFC 3261) defines a B2BUA as “a logical entity that receives a
request and processes it as a user agent server (UAS).“ The SUT definition of a B2BUA
is a logical entity that sits in the SIP call flow between two endpoints, maintaining state-
full dialogs with each, which allows it to manipulate the call at any time to add value.

12

SUT can thus provide sophisticated call handling with straightforward SIP signaling. The
TCS can maintain SIP trunks to any number of PBXs and Gateways, based on the
appropriate IETF standards.

For example, suppose Sam’s desk phone is connected to the IP PBX, and Valerie’s
phone is connected to the TDM PBX. If Sam uses his Sametime client to initiate a call to
Valerie in which they both take the call on their desk phone, the TCS acts as a B2BUA
by taking Sam’s request and establishing one call leg to Sam’s desk phone and a
second call leg to Valerie’s desk phone. The TCS does this while handling the complete
signaling between both ends of the call from the time it is established until the call is
terminated.

B2BUA’s inherent “two-call-legs approach” allows SUT to provide PBX-like functions that
operate homogenously across any vendor’s PBX and facilitate an integrated
heterogeneous UC2 solution. To provide this B2BUA functionality across the enterprise,
the TCS server maintains a SIP signaling path between the telephony service
equipment.

The SIP trunks are established to other equipment via configuration settings on the TCS
that allow SUT to process incoming calls from various trunks and/or route calls to
various trunks according to the numbering plan configuration. Each trunk is configured
as a SIP end point.

4.3 Gateway integration
The central premise of SUT is that legacy and disparate PBX equipment doesn’t need to
be replaced in order for enterprises to take advantage of unified communications. The
TCS uses SIP signaling to connect with every PBX. So in a legacy or TDM-based
environment, one of the keys to providing a unified experience is using one or more
gateways to act as translation services between telecommunication infrastructure
components that use different protocols.

In an SUT environment, gateways provide IP connectivity to legacy PBX systems, as
well as public switched telephone network (PSTN) access to IP-based PBX. They also
play a key role in connecting SUT to any non-SIP-enabled devices. These devices can
be various telecommunications equipment including PBXs, gateways to PBXs, or
gateways to PSTN.

IBM does not provide gateways and these components must be obtained from third-
party vendors. Gateway selection should be based on what equipment the TCS will
connect with and what capacity (number of active call-legs) it will support. IBM has an
active validation program and is continually updating the list of tested gateways.

5 Sizing an SUT environment
TCS sizing is quite straightforward since each duplex pair can host up to 100,000
people. TAS sizing is more dynamic since it can be configured as either a full TAS or a
media-only server. The full TAS contains all the functional elements and is the
configuration used for the smallest SUT deployments. Each full TAS server can handle
up to 15,000 people, and each provisioned user is assigned to a particular TAS. TAS

13

servers are always deployed with at least one standby server per cluster to provide
redundancy.

To improve SUT scalability characteristics, specialized TAS node configurations can be
installed as media-only servers. This configuration lets the administrator create
additional conferencing capacity by installing media-only TAS’s on dedicated hardware,
while the application logic and SIP Proxy Registrar run on the full TAS’s.

Figure 11 shows a large SUT deployment of 200,000 people. A deployment of this size
would require two TCS pairs, with each pair hosting up to 100,000 people. Additionally, a
full TAS has been configured for every 15,000 people and contains a minimum of one
standby node per TAS group.

Figure 11. Large SUT deployment
SAN

Sametime V TAS TAS TAS
P
Server MS AL
AL SPR
SPR

V
P TCS
SI TCS
P

Sametime SI SI
P P
Clients

Gatewa
y
Vendor 1
Existing Sametime Deployment
IP-PBX
Sametime Unified Telephony
SIP
SPR SIP Proxy / Registrar
PSTN
AL Application Logic
Vendor 2
MS Media Server TDM-PBX

Full TAS’ are deployed in an N + 1 configuration so that each cluster provides at least
one running TAS server in standby node for failover. In the event that a TAS node fails,
the warm standby picks up the program files and application data from the Storage Area
Network (SAN), makes an exact replica of the TAS node that failed, and takes over
providing the services of the failed node.

The figure depicts four media-only TAS’s that are dedicated to providing conferencing
services. Connections to the conferencing services hosted on the media-only TAS’s are
load balanced, and these resources can be shared by both groups of full TAS’s. This
centralized SUT configuration allows companies to easily scale their conferencing
resources by adding capacity directly where it is needed.

14

5.1 Integrating SUT with a third-party TCSPI adaptor
The TCSPI is a Java™-based interface that allows a third party to integrate an audio-
conferencing product or service with Sametime. It was originally created to add
telephony-based audio to a Web conference by associating an audio conference and
call control into the Sametime Web Conference UI. Over time, the TCSPI was adapted
to provide support for click-to-call from the Connect Client and, although the end-user
experience is a point-to-point call, there is an audio conference under the hood.

When SUT is deployed in an environment with an existing TCSPI adaptor, the telephony
services on the Sametime client will be handled by SUT rather than the TCSPI. This
design provides improvements including true point-to-point calls, along with incoming
and outgoing call control, click-to-conference, telephony presence, and unified number
service.

The audio conferencing services used by Sametime Web Conferencing will continue to
be provided by the existing third-party TCSPI integration, as originally intended.

6 SUT call flows
There are several deployment options available when rolling out SUT, but the basic call
flows between the TCS, TAS, and the Sametime environment are the same, regardless
of which deployment option is chosen. In all cases, SUT is added to the call path and
provides a unified number service that can reach any number of devices.

In all cases, the call flows are identical from the time they hit the TCS until released by
the TCS. The only variations in the call routing scenarios occur below the TCS level and
are dependent on the deployment option.

Since a significant number of the steps in each call flow occur at the TCS level or above,
we start by examining the generic parts of the inbound and outbound call flows that
occur between the TCS and TAS and TAS and the Sametime environment.

Once the generic call flows have been covered, the next section will detail the three SUT
deployment options available and discuss the call flow differences below the TCS.

6.1 Inbound call flow
Figure 12 depicts the generic inbound call flow. Step 1 (right-middle part of the figure)
shows an incoming call to a person’s unified number. The next step that’s always taken
by TCS is to send a request to TAS so that it can determine how to route the call (Step
2).

15

Figure 12. Generic Inbound call flow

Incoming Call to Soft Phone

3. Incoming call 6. TAS tells TCS
5. Decision is alert sent to how to route
returned online person the call
to TAS
2. TCS alerts TAS
Sametime TAS and awaits
VP TAS
Server instructions

VP
TCS 1. Incoming call
to person’s
7. Call is set up Unified
SIP to
Sametime softphone SIP SIP
Number

Clients
SIP
IP-PBX Telephony
Gateway
4. Person sees 8. Call is completed
pop-up and 9. Voice flows
between soft SIP through gateway
requests join
on softphone phone and PSTN
gateway

The TAS uses the set of incoming call rules to determine which device should be dialed.
In addition, if the user is online and has not turned off alerts, the TAS sends a trigger to
the client to pop up such an alert. Once TAS has determined the device, it returns the
information back to the TCS server, where it will set up the call to the appropriate device.

In Step 3, the callee has a rule to route calls to his soft phone. Since the person is
online, TAS sends a pop-up call alert, and in Step 4 (lower-left corner) the callee
receives a screen pop-up identifying the incoming call and providing options to answer
the soft phone, or take the call on any number of devices, or route to voicemail.

In this case, the callee uses the screen pop-up to answer the call on the computer and,
in Step 7, TCS uses this endpoint information from TAS to set up a call leg to the soft
phone. In Step 8, the call is completed through the gateway, and the voice flows
between the soft phone and the gateway.

Again, the call flows above the TCS will be the same for each deployment scenario. In
each case, TCS asks TAS how to route the call, and TAS uses the set of incoming call
rules to determine which device should be dialed. In addition, if the user is online and
has not turned off alerts, the TAS sends a trigger to the client to pop up such an alert.
People can elect to concurrently ring their preferred device and send the screen popup
or always send the screen popup first when they are online.

16

6.2 Outbound call flow
The outbound call flow is similar to the inbound call flow in that all the interaction above
the TCS is independent of the deployment scenario. SUT is only aware of outbound calls
initiated from the Sametime client, as depicted in figure 13.

Figure 13. Outbound call flow
3. TAS determines devices
(in this example, soft
Click-to-Call: Soft Phone to PSTN phone for caller, and
cell phone for called
* - Signaling simplified

2. Request is
sent to
Sametime TAS VP
over TAS
Server TAS 4. TAS tells
TCS to set
up the call

VP
TCS 6. Call is set
5. Call is set up to cell
up to phone via
SIP
Sametime softphone SIP SIP
gateway
Clients
SIP
IP-PBX Telephony
Gateway
1. User initiates 7. Voice flows
click-to-call between soft
phone and SIP
to a co-
worker gateway PSTN

In this case, a person uses the Sametime client to initiate a call from the Contact list to a
co-worker. The request is sent to the TAS, which determines the callee’s routing rules
and then passes the TCS both endpoints needed to set up the call.

The TCS then creates one call leg to the desk phone of the caller and another call leg to
the callee’s cell phone. Once both people answer the call, the media flows between the
desktop phone of the caller and the cell phone of the callee.

Conference. To escalate a two-party call to a multi-party conference, the Sametime
client provides a simple interface for adding people. Once additional persons are added
to the call, SUT creates a conference on the TAS and transfers the call already in
progress to the conference server. The TCS then generates one or more call legs to
invite the additional callees to the conference.

See the Appendix for call flow diagrams of the inbound and outbound call flows.

17

7 Deploying SUT
SUT users must be reachable by a single unified number that, if dialed, will reach users’
routing rules and their preferred device. Deciding how user’s numbers are transitioned is
one of the main factors that determine how SUT will be deployed.

This section examines the three possible deployment options, along with the main
benefits, drawbacks, and logistics of each option. We also examine a more detailed
inbound call-routing flow to help illustrate out how each decision affects the call routing
behavior. The deployment options are as follows:

(1) Repurpose old desktop numbers to new unified numbers
(2) Add a new telephony gateway between the carrier and the PBX
(3) Provide everyone with a new unified number that replaces the desktop number

Regardless of what deployment model is used or what existing telephony hardware is in
place, the end-user experience and level of functionality remain the same.

7.1 Option 1: Repurpose existing numbers to new unified
numbers
Under this option, the existing enterprise desktop number becomes the new unified
number. New numbers must then be provisioned for each person on their existing PBX
to a number that is known only by the PBX.

For example, let’s say Sam’s original desktop number was 323-1000. Once SUT is
deployed, the original number will become the unified number, and dialing it will now
allow someone to reach Sam on his preferred device. This means that calls that were
previously routed to his desktop phone, Sam can now take on his cell phone, voicemail,
home phone, or any other endpoint that he chooses.

Since Sam’s existing number is used for the unified number, Sam would need to be
provisioned with a new number on the existing PBX, and this number will only be used
for routing purposes. Calls that the existing PBX would normally handle by routing to
Sam’s published desk phone must now be routed to the TCS.

Since the existing PBX already had routing rules and numbering plans configured to
route calls, the existing PBX must be re-numbered. For example, the new number on the
existing PBX might be changed to 626-1000, but this number is only for internal routing
by the existing PBX, and Sam doesn’t need to know that his number has changed.

SUT can show the unified number as the assigned desk phone number on the device,
even though the actual number used to route the call might be new, so this change
doesn’t necessarily need to be communicated to SUT users.

The benefits of this option include keeping arrangements with carriers and all existing
phone numbers. The user collateral remains unchanged, while the desk phone would
receive a new number.

18

The drawback of this option is that a significant number of changes must be made to the
existing PBXs. The changes that must be made to the numbering plan depend on what
type of PBX is involved. Once the original desktop enterprise number becomes the
unified number, the existing PBX must be configured to route these calls to the TCS. In
this scenario, the PBX would have a rule, so that any calls coming in for prefix 323 would
be routed to TCS, and calls routed to prefix 626 would be routed to the desk phone.

7.1.1 Deployment Option 1 call flows
Inbound call to IP PBX
As described above in Section 6, SUT call flows, the signaling flow at the TCS level and
above is the same, regardless of deployment option. Therefore, figure 14 is the same as
what we saw in figure 12, except that the signaling Steps 3-7 occurring at or above the
TCS level have been removed for simplicity.

Figure 14. Deployment Option 1: Inbound call flow to IP PBX

Sametime VP
TAS
Server TAS

2.Call routed
VP to SUT for
TCS processing

Sametime 3. Call is linked SIP
SIP between desk
Clients phone and PSTN Telephony 1. Incoming call to
IP PBX user’s Unified
Gateway Number
(example 323-1000)

SIP SIP
4. Media flows
between PSTN
phone and
PSTN

In Step 1 there is an incoming call from the PSTN to a person’s unified number of 323-
1000, and in Step 2 the call is routed to the TCS. Remember that, under deployment
Option 1, the IP PBX has been renumbered so that calls to the 323 prefix are always
routed from the PBX to TCS. Again, the steps above the TCS level have been removed,
but in this scenario the callee has elected to take the call on his desk phone.

In Step 3, TCS routes the call to the IP PBX, and the PBX then dials Sam’s desk phone,
which has been renumbered to 626-1000. In Step 4, Sam answers his phone, and the
media flows between phone and PSTN.

Inbound call to TDM PBX
The call flow is similar to that of the IP PBX, but in this case, a third-party gateway sits
between the TCS and the TDM PBX to translate messages to SIP (see figure 15). In

19

Step 1 there is an incoming call to a unified number, and the PBX has again been
configured to route these calls to SUT. In Step 3, TCS sets up the call leg to the PBX via
the gateway and, once the call is answered, the media flows between the phone and the
PSTN.

Figure 15. Deployment Option 1: Inbound call flow to TDM PBX

TCS
2.Call routed
SIP to SUT for
processing

1. Incoming call
3. Call is linked Gateway
to person’s
between desk
Unified
phone and
Number
PSTN

PSTN

TDM PBX

4. Media flows
between
phone and
PSTN

Outbound call to PSTN
The outbound call scenario from the soft phone to the PSTN is the same as the generic
outbound call flow we saw in figure 13. This scenario doesn’t change between the
different deployment options.

Internal call from soft phone to TDM desk phone
In this scenario as shown in figure 16, a person initiates a call from their Sametime
contact list to a coworker, and the coworker chooses to take the call on the desk phone
(see figure 16).

Step 3 has been simplified in the diagram, but TAS will go through its normal logic of
determining the callee’s preferred device and, in this case, it’s a desk phone attached to
a TDM PBX. Once both call legs have been determined in Step 4, TAS tells TCS how to
set up the call. In Steps 5 and 6, TCS uses its B2BUA capability to set up both legs of
the call and, once connected, the voice flows between the soft phone and gateway.

20

Figure 16. Deployment Option 1: Internal call flow from soft phone to TDM desk phone

(in this example, soft
phone for caller, and
desk phone for callee
2. Request is
sent to
Sametime TAS
TAS 4. TAS tells
VP TAS
Server TCS to set
up the call

VP 6. Call is set
TCS up to
desk
SIP phone via
Sametime SIP SIP gateway
Clients
SIP
IP-PBX
Telephony
Gateway
1. Person initiates
5. Call leg is set
click-to-call SIP 7. Voice flows
up to soft
to a co- between soft
phone
worker phone and TDM PBX
gateway

Internal Click-to-Call: IP desk phone to a TDM desk phone
In this scenario, a person initiates a Click-to-Call from their Sametime Contacts list to a
coworker, but the caller elects to take the call on the IP desk phone rather than on the
soft phone. All the steps are identical to the previous scenario, with the exception of Step
5; here the call leg is set up to the IP PBX rather than the softphone by sending the
number 626-1000 to the PBX. Figure 17 shows the difference between Step 5 in the two
internal scenarios.

21

Figure 17. Deployment Option 1: Internal Click-to-Call: IP desk phone to a TDM desk phone

(in this example, desk

2. Request is
sent to
Sametime TAS
TAS 4. TAS tells
Server
VP TAS TCS to set
up the call

VP
TCS 6. Call leg is set
up to desk
SIP phone via
gateway
Sametime SIP SIP
Clients
SIP
IP-PBX Telephony
Gateway
1. User initiates
click-to-call 5. Call leg is set
SIP
to a co- up to
desktop TDM PBX
phone

7. Media flows
between
phone and

7.2 Option 2: Configure telephony gateway to use source-based
routing
Under this option, a new telephony gateway that acts as a source-based router is added
into the incoming call flow. A source-based router is a gateway that has been configured
to route calls based on the source of the incoming call. For example, in an SUT
environment, this gateway is configured so that any incoming call it receives from TCS is
routed to the PBX, and incoming calls from any other source are routed to the TCS.

Using this source-based routing deployment option, the existing desktop numbers
become the new unified numbers, just like in the first deployment option. However, the
key difference between these two options is that no changes to the existing PBX are
required, as is the case in deployment Option 1. There is also no need to modify
arrangements with carriers or change user collateral; SUT will continue to show the
unified number as the assigned desk phone.

The disadvantage of this option is the potential loss of reliability, as this gateway is
critical to the call path and could potentially add a point of failure or require additional
infrastructure.

22


Going back to the Sam example, we’ll examine another incoming call diagram from the
PSTN (see figure 18), to differentiate between the call flows in the first two deployment
options.

Figure 18. Deployment Option 2: Inbound call flow to IP PBX via gateway

3. Call is set up
to desktop TCS
phone thru
gateway
2. Call is routed
to TCS
4. Gateway rules
route calls
from TCS to
PBX SIP

IP-PBX SIP Telephony
Gateway
SIP
1. Incoming call
to person’s
Unified
Number

9. Voice flows PSTN
between
8. Call is completed phone and
through gateway gateway

Using the source-based routing deployment option, a call comes into the PSTN for
Sam’s unified number and is routed to the gateway. Then, per the rule that all calls not
from the TCS are routed to the TCS, the gateway passes this call on to the TCS. At this
point, TCS performs its normal operation to work with the TAS server, to determine the
person’s preferred device (as detailed in Section 6 above). In this case, the preferred
device is the desktop phone.

In Step 3, the TCS routes the call to the gateway, where the rule is applied to route all
calls to the IP PBX that come from the TCS to prefix 323. Since the PBX has not been
renumbered, Sam’s original desktop number of 323-1000 remains unchanged on the
existing PBX, and the PBX sets up the call to the desktop phone. Once the call is
answered and completed through the gateway, the media flows directly between the
phone and the PSTN.

23

Inbound call to TDM PBX
The call flows are the same for an IP PBX or TDM PBX, so another inbound diagram is
not included here.

outbound call flow in figure 13. This scenario doesn’t change between the different
deployment options.

Internal call from soft phone to a TDM desk phone
The internal call from soft phone to a TDM desk phone is the same as shown in figure
16.

In this scenario, a person initiates a Click-to-Call from their Sametime Contacts list, but
the caller elects to take the call on their IP desk phone rather than on the soft phone, as
in the last scenario.

The call flows between deployment option 1 and option 2 are slightly different in this
scenario. For example, in Step 5 of this scenario in deployment option 1 (figure 17), the
TCS interacts directly with the IP PBX. Under deployment option 2 (see step 5 in figure
19), the TCS always routes calls through the source-based router to the IP PBX rather
than communicating directly with the IP PBX. This route from the TCS through the
gateway to the PBX is based on the source-based route.


2. Request is
sent to
Sametime TAS
TAS 4. TAS tells
Server
VP TAS TCS to set
up the call

VP TCS 6. Call leg is
set up to
SIP desk phone
Sametime SIP SIP
via

Clients
SIP
IP-PBX Telephony
Gateway
1. User initiates
click-to-call 5. Call leg is
to a co- set up to
desktop SIP TDM PBX
phone

7. Media flows
between
phone and

24

7.3 Option 3: Provide everyone a new unified number to replace
desktop number
Under this deployment option, a block of numbers is purchased from a carrier, and all
SUT users are provided with a new number that also serves as the unified number. The
new numbers are provisioned directly on the TCS so that incoming calls to the unified
number are routed directly to SUT.

The benefits of this option are that no changes are required to the existing PBX(s), nor is
there a need to add specialized gateway equipment to re-route the call flow.

The disadvantages of this option are that new numbers must be purchased from a
carrier, user collateral must be re-printed (business cards, letterheads, etc.), and the
corporate directory must be updated with new numbers.


Under this deployment scenario, let’s suppose Sam’s new number from the carrier is
626-1000, and his old number is 323-1000. In Step 1 of figure 20, incoming calls to the
unified number (626-1000) are routed to the TCS for its normal processing, to determine
the preferred device.

Figure 20. Deployment Option 3: Inbound call flow to IP PBX

Sametime VP
TAS
Server TAS
2.Call routed
to SUT for
processing
VP
SIP TCS

Sametime SIP

Clients 1. Incoming call to
4. Call is completed
user’s Unified
through gateway Number
IP PBX (example 323-1000)
PSTN
3. Call is setup to Gateway
desktop phone

PSTN
5. Media flows
SIP SIP between
phone and
PSTN

In Step 3, TCS sets up the call to the existing PBX, the call is completed through the
gateway, and the media flows between phone and PSTN. If figure 20 included a legacy
PBX rather than an IP PBX, the call path would include a third-party gateway between
the TCS and the TDM PBX.

25

outbound call flow back in figure13. This scenario doesn’t change between the different
deployment options.

Internal call from soft phone to a TDM desk phone
The internal call from soft phone to a TDM desk phone is the same as was shown in
figure 16.

In this scenario, a person initiates a Click-to-Call from their Sametime Contacts list, but
the caller elects to take the call on the IP desk phone rather than on the soft phone (see
figure 21). This call flow is the same as deployment option 1, in which the TCS sets up
the call leg to the IP phone directly with the IP PBX.

In this case, TCS calls 323-1000, the number that the PBX routes to the phone. The call
routing is different than deployment option 2, in which interaction between the IP PBX
and the TCS is always routed though a gateway.



2. Request is
sent to
Sametime TAS
TAS 4. TAS tells
Server
VP TAS TCS to set
up the call

VP
TCS 6. Call leg is set
up to desk
SIP phone via
gateway
Sametime SIP SIP
Clients
SIP
IP-PBX Telephony
Gateway
1. User initiates
click-to-call 5. Call leg is set
SIP
to a co- up to
worker desktop TDM PBX
phone
7. Media flows
between
phone and
gateway

26

8 Telephony survivability
The TCS is certified to provide 5-9s of carrier-grade reliability when installed as a duplex
pair. The TAS also has a standby mode for recovery. Because the TAS is an application-
level component and not a telephony component, it is held to a lesser survivability
specification. In the absence of a TAS, the TCS will route calls to the user’s default
telephony device.

9 Provisioning users
Provisioning is the process of adding users and routing rules to the SUT solution. The
provisioning component has been designed to automate the process of populating user
and device data into SUT, and it can be configured to initially provision all or just a
subset of people. Once a user has been provisioned, SUT can be configured to allow
automatic updates as the user’s directory information changes.

For example, each person is provisioned with a set of telephone numbers extracted from
the enterprise directory. Each number corresponds to a device, so when Sam is
provisioned, the provisioning application reads the directory and extracts his office
phone, cell phone, and home phone and ties these devices to Sam’s unified number.

If any of Sam’s telephone numbers for these devices changes in the directory, the
provisioning application can be configured to run in real-time or on a schedule to pick up
the changes.

The provisioning component is built by use of the Tivoli® Directory Integrator (TDI), and
this tool is bundled as part of the product, to allow for customizations. The provisioning
can be fully automated for standard configurations, and the customer has the option to
build their own customized provisioning solution to meet their specific business needs.

10 Leveraging Sametime SDKs
SUT includes a number of new APIs that business partners and customers can use to
integrate communication functions directly within business applications—a process
commonly referred to as "communications-enabled business processes,” or CEBP.

Lotus Sametime provides several SDKs designed to allow access to the telephony
services provided by SUT along with the presence, instant messaging, video, and
integration into either Web or installed applications. This section provides an overview
on how to leverage the Sametime SDKs to embed real-time functionality into different
applications.

10.1 Sametime Connect Web API Toolkit
If you want to add SUT functionality to a Web application, this toolkit provides an
external interface to basic functionality of the Sametime Client. It lets Web developers
Sametime-enable their Web pages and applications with "livenames." Specifically, Web-
based applications that integrate the Connect Web API are essentially able to proxy the

27

functionality of the locally running Sametime Client (managing contacts, starting chats or
telephone calls, and providing Sametime and telephony presence status).

The Connect Web API Toolkit was introduced with Lotus Sametime 8.0.1 and has been
enhanced for SUT to extend click-to-call semantics, so that users can call phone
numbers and start a call directly from a livename. The WebKit extended-status plug-in
has been enhanced so that each livename displays Lotus Sametime and telephony
presence.

10.2 Sametime Helper Toolkit
This toolkit provides a Microsoft Windows native and Java object-oriented external
interface to the Sametime Client so that functionality can be embedded in native
business applications.

Applications that integrate the Sametime Helper API are essentially able to proxy the
functionality of the locally running Sametime Client (managing contacts, starting chats or
telephone calls, and providing Sametime and telephony presence status).

10.3 Sametime Unified Telephony REST APIs
The SUT Representational State Transfer (REST) APIs are designed to provide click-to-
call capabilities that can be embedded within applications. This toolkit is similar to the
Sametime Web API Toolkit in that they both allow you to use REST APIs to initiate a
click to call. The main difference is that the Web API Toolkit depends on a Sametime
client to be running on the desktop, whereas the SUT REST APIs can be used without a
Sametime client being present.

Both toolkits also share the same REST signature, and there are methods available that
allow a developer to write applications that switch between using the local and remote
APIs, depending on the situation. So when a Sametime client is present on the desktop,
the application will use the local APIs and provide a slightly richer experience, but when
the Sametime client is not available, the remote APIs will be used.

SUT REST APIs are implemented as a servlet running in the WebSphere Application
Server container on the TAS. The Call API handles either a person’s contact ID or a list
of phone numbers, and call commands are handled by the TAS server on which the user
is provisioned.

10.4 Sametime Connect Toolkit
Lotus Sametime Connect technology is built on the Eclipse-based IBM Lotus Expeditor
platform. It leverages the Eclipse plug-in framework to provide developers with
extensibility features that go far beyond those available in previous releases. The
Sametime Connect Toolkit offers APIs to build Eclipse plug-ins that extend the
capabilities of Lotus Sametime Connect to integrate your own applications.

SUT exposes two new client-side extension points for the Telephony QuickFind feature
and the CallAction UI element, and third parties can develop a client plug-in that extends
the functionality of these components.

28

11 Conclusion
Unifying telephone communications with real-time collaboration tools and integrating
these new communications and collaboration capabilities into business processes can
help enterprises build more competitive business models, improve the speed and
efficiency of business processes, reduce cycle times, and improve customer service.

IBM Lotus Sametime Unified Telephony software helps enterprises extract more value
from existing investments in telephony infrastructure (both VoIP and legacy systems)
and unified communication and collaboration solutions.

The value of a customer’s investment in a vendor’s PBX is expanded via leveraging and
interoperating with SUT by:

• simplifying integration of telephony and collaboration in multi-vendor and multi-
generation PBX environments
• improving the business case for an IP upgrade by enabling a staged “non-forklift”
migration path to newer IP telephony and unified communications
• encouraging the use of under-utilized PBX features

By explaining the IBM UC2 strategy and the SUT product, we hope that you will better
understand the benefits of using SUT to provide a unified communications user
experience that leverages your existing telephony infrastructure.

12 Appendix
SIP flow diagrams for the inbound and outbound call flows covered in Section 6.

Incoming Call: PSTN to Soft Phone
Sametime SUT SUT PSTN PSTN
Client TAS TCS Gateway Phone

Dial Unified Number

INVITE (Offer SDP)

Incoming Call Alert 100 TRYING

Incoming Call Alert 183 Sess Prog (Ring SDP)

Accept Call RING BACK

Accept Call

INVITE (Offer SDP)

INVITE (Offer SDP)

100 TRYING

180 RINGING 100 TRYING

200 OK (Answ er SDP) 180 RINGING

200 OK (Answ er SDP) 180 RINGING

ACK 200 OK (Answ er SDP)

ACK ACK

VOICE

29

Click-to-Call: Soft Phone to PSTN
Sametime SUT SUT PSTN PSTN
Client TAS TCS Gateway Phone

C2C User

CSTA makeCall

INVITE (no SDP)

INVITE (no SDP)

100 TRYING

180 RINGING 100 TRYING

200 OK (Offer SDP) 180 RINGING

200 OK (Offer SDP)

INVITE (Offer SDP)

100 TRYING

183 Sess Prog (Ring SDP) Phone Rings

ACK (Answ er SDP)

ACK (Answ er SDP)

RING BACK

Phone Answ ered

200 OK (Answ er SDP)

ACK

VOICE

13 Glossary of terms

Term Definition

B2BUA A logical entity that sits in the SIP call flow between two endpoints,
maintaining state-full dialogs with each, allowing it to manipulate
the call at any time to add value. This allows SUT to provide
sophisticated call handling with straight forward SIP signaling

ITU-T recommendation that defines the format of telephone
numbers. E.164 numbers can have a maximum of fifteen digits and
E.164
are usually written with a + prefix.

Provisioning The automation of all the steps required to manage (set up, amend,
and revoke) user or system access entitlements or data relative to
electronically published services.

SIP Session Initiation Protocol is an application-layer control
(signaling) protocol for creating, modifying, and terminating
sessions with one or more participants.

30

SIP Trunk Virtual circuits that connect SIP devices.

TAS Telephony Application Server is where the Sametime Presence and
Communication server applications execute.

TCS Telephony Control Server is where the HiPath 8000 (ONS Server)
executes.

TDI The Tivoli Directory Integrator synchronizes and exchanges
information between applications or directory sources.

VP Virtual Places is the protocol used in the Sametime server.

14 Resources
Learn
• Refer to IBM’s UC2 strategy:
http://www-01.ibm.com/software/lotus/unified-communications/

• Refer to IBM Lotus Sametime family of products, including Lotus Sametime
Unified Telephony software:
http://www-01.ibm.com/software/lotus/sametime/

• Read the developerWorks® Lotus article, “The IBM Lotus Sametime V8 family:
Extending the IBM unified communications and collaboration strategy”

• Read the developerWorks Lotus article, “Bring real-time collaboration to the next
level with IBM Lotus Sametime Advanced 8.0”

• Refer to IBM Converged Communications Services:
http://www-935.ibm.com/services/us/index.wss/home

• Refer to System i IP Telephony solutions:
http://www-03.ibm.com/systems/i/advantages/

Get products and technologies
• Download the IBM Lotus Sametime Software Development Kit (SDK) from
developerWorks Lotus.
• Download the trial version of IBM Lotus Sametime.

Discuss
• Participate in the discussion forum.

15 About the authors
Todd Page is an Advisory Software Engineer and provides technical enablement
services to ISVs and IBM business partners who are integrating with the Sametime
platform. Todd has also co-authored a whitepaper on using SIP with Lotus Sametime.

31

Jeff Reser is Product Manager for Unified Communications & Collaboration and is
responsible for the strategy and direction of the Sametime open platform as well as
Sametime Mobile. Jeff works extensively with partners who create integrated UC²
solutions based on Sametime technology across heterogeneous environments. Prior to
his role with UC², Jeff was in the Mobile & Wireless group and was responsible for
driving UC technology to smartphones, PDAs, and other mobile devices.

**************
Trademarks
IBM, Lotus, Notes, Sametime, and Tivoli, trademarks or registered trademarks of IBM
Corporation in the United States, other countries, or both.

Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States,
other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

32

Whitepaper: Understanding IBM Lotus Sametime and Unified Telephony

More Related Content

Viewers also liked (20)

Similar to Whitepaper: Understanding IBM Lotus Sametime and Unified Telephony (20)

Recently uploaded (20)

Whitepaper: Understanding IBM Lotus Sametime and Unified Telephony