SPHINX

1
SPHINX
IPTS 2000

• A Study in Convergent Telephony

09/11/2000
2
Talk Content and Structure

• Motivation
• Interesting opportunities for protocol
  inter-working and service reuse
• Techniques to achieve convergence and
  inter-operation
• Examples
• Conclusion
• Note Will NOT compare protocols to analyze which
  is better or why

3
Services for Telephony

• Services enhance the end-user experience
• They are good revenue generators
• Permit service providers opportunities for
  differentiation from competitors
• Sticky services lead to greater customer
  loyalty
• New networks need to
• support feature parity with existing ones
• provide new services to attract more customers

4
VoIP Utopia
We dont have this today
Protocol/Access Agnostic Services (VoIP Services)
Services Domain
VoIP Service- related Signaling
Base Domain
VoIP Call Control with VoIP Call Model
VoIP Call Control Protocol
VoIP End-points
5
Real World Systems Today
SIP End-Points
H.323 End-Points
PSTN End-Points
6
Domain dependent service creation

• multitude of access protocols
• different call models or protocol FSMs
• support for diverse service creation environments
• different signaling and service invocation
  mechanisms
• need to re-create existing services for every
  domain? create services in one domain, make them
  accessible everywhere
• focus is on network centric services

7
Convergence

• What is it? The capability for seamless
  interoperation across
• network types
• access mechanisms and protocols
• Results in Seamless Services
• user experience remains the same, invariant
  across access differences

8
Seamless Services

• Example - User A subscribes to the same feature
  on the PSTN and on the VoIP network.
• Seamlessness implies User A gets same end-user
  experience for this feature, in both these
  networks.

9
Convergence and Seamless Services
Note that one can have Seamless Services
without Convergence, by simply re-implementing
the same service again in the new network or
protocol context. For example, user A
subscribes to feature X for PSTN and VoIP.
Feature X is implemented twice, once for PSTN,
again for VoIP, but both implementations give
same end-user experience.
10
Cross-Domain Service Reuse
Re-implementation for every access protocol or
domain costs money. E.g. We have H.323 services
and SIP services, do we need to re-implement
each service twice, once for each domain? Why
not leverage existing services and make these
available to new end-points? ? Need for
convergence. Savings on development, deployment
and infrastructure costs. Reuse Services where
possible, to save money
11
Evolution Architecture (IP)
IWF
Domain-independent Service Reuse PINT
SPIRITS considerations are outside the scope of
this talk.
SIP End-Points
H.323 End-Points
12
Base Domain Signaling

• Messages exchanged between network entities to
  aid the process of call setup, processing and
  tear-down constitute signaling
• H.323 and SIP are protocols that may be used for
  call or session control in IP networks
• H.323 and SIP can both use RTP for bearer
• If call control and media characteristics
  signaling in H.323 and SIP is equivalent it must
  be possible to make SIP-H.323 and H.323-SIP calls

13
Call Models

• A Call Model is a Finite State Machine that
  represents call state succinctly
• Greater number of states in a call model implies
• finer grained call control
• greater opportunity to offer services and thus
  positively impact user experience
• greater complexity, if number of states increase
  beyond reasonable limits

14
Techniques for Convergence in VoIP

• The Sphinx paper studies three general
  techniques
• Call Model Integration
• Call Model Emulation
• State Machine Reuse
• This is a strictly non-exhaustive list, there are
  other methods
• Think of triggers as service accessors

15
Call Model Integration (CMI)

• Run two FSMs in lock-step
• Support service triggers in the FSM from the
  services domain
• Support call processing using the base domain FSM
• Share domain context information between the
  base and services domains

16
CMI Schematic
Services Domain FSM
Base Domain FSM
17
CMI Analysis

• Advantages
• tighter integration of call processing in both
  domains
• clean access to most services from the services
  domain
• Disadvantages
• mapping two FSMs into each other can be hard or
  inexact
• must account for differences in FSM granularity

18
Call Model Emulation (CME)

• Embed service domain triggers into the base
  domain FSM
• Use base domain FSM for call processing
• Triggers fire when services need to be accessed
• Access service domain features appropriately

19
CME schematic
20
CME Analysis

• Advantages
• easy to embed selected triggers into the base FSM
• get quick access to selected services associated
  with those triggers from the services domain
• Disadvantages
• only limited set of services accessible from the
  services domain
• does not really model call processing from the
  services domain

21
State Machine Reuse (SMR)

• Build a state machine for one protocol or domain
  (say, services domain)
• support other protocol interfaces to this one
  state machine
• assumes that the two protocols in question are
  semantically close, and have reasonably similar
  state machines.

22
SMR Schematic
23
SMR Analysis

• Advantages
• seamlessly interoperates different protocols
• provides clean access to most services from the
  services domain
• Disadvantages
• can be very hard to do, depends on semantic
  closeness of the protocols and call models or
  FSMs under consideration
• may be inexact

24
Server Interface Modification (SIM)

• change the interface on the server in the
  services domain to support base domain
  protocols for service access
• effectively embeds protocol convertor in the
  servers request/response path
• similar to the move towards supporting TCAP/IP
  (Sigtran) in addition to TCAP/SS7 in IN

25
SIM Schematic
26
SIM Analysis

• Advantages
• requires very little work on the call processing
  entity
• Disadvantages
• requires the server in the services domain to
  implement appropriate interfaces
• services accessible may be limited by the
  protocol used

27
Converged Services Architecture for VoIP
IN Call Model
IN Call Model
SIP-PSTN GW
H.323-PSTN GW
H.323 GK
SIP Server
H.323 GK
SIP Server
SIP Client
H.323 Client
General Network System Architecture
28
Sphinx Paper Examples - I

• H.323/SIP to IN inter-working
• demonstrates how SIP and H.323 end-points can
  access IN services transparently
• calls for support for TCAP/IP interfaces on H.323
  gatekeepers and SIP servers
• description indicates how CMI, CME or State
  Machine Reuse techniques can be used to achieve
  this

29
Sphinx Paper Examples - II

• SIP to H.323 Inter-working
• explores how these protocols can be made to
  inter-operate
• uses the notion of semantic closeness between
  protocol messages to drive the discussion
• states some assumptions for easy inter-working
  for e.g. H.323 used with fastStart

30
Sphinx Paper Examples - III

• SIP-H.323 calls, changes to media characteristics
  after call setup
• depicts how changes to media characteristics to
  already established call legs may take place
  (e.g. codec changes etc.)
• these changes may be initiated by either the
  H.323 or the SIP end-point.

31
Issues and Future Work

• Billing and related considerations have to be
  worked
• Multi-party multimedia VoIP conference calls
  accessing IN features
• H.323 to SIP inter-working when the fastStart
  feature is not supported
• Addressing feature interactions, both
• inter-domain, and
• intra-domain
• Taxonomy of various efforts on convergence

32
Conclusions/Messages

• Reuse services where possible to save on
  redevelopment costs by leveraging existing
  infrastructure
• Use convergence to reach large customer base
  quickly
• Relatively easy to inter-work semantically close
  signaling protocols that use the same bearer

33
Thank You
34
Backup Slides
35
SIP-H.323 Inter-working Example
36
SIP-H.323 Inter-working Example
37
IN BCSM - O_BCSM
IN CS-2 Call State Machine
38
IN BCSM - T_BCSM
IN CS-2 Call State Machine
39
SIP/H.323-IN Inter-working Example
40
INSeCT Prototype - I
IN Services for Converged Telephony
Note Netmeeting is a registered trademark of
Microsoft Corporation Elemedia is a registered
trademark of Lucent Technologies
41
INSeCT Prototype - II
Note The API supported by elemedia is defined
from the endpoint perspective. Mapping
of the IN Call Model States to the elemdia
Gatekeeper FSM.
42
Conclusions

• The heart and soul of convergence is
  interoperability of PSTN/IN and IP services
• The combination of PSTN voice and IP-based
  service creation capabilities leads to new hybrid
  services and revenue opportunities
• Open, Internet-based interfaces and service
  capabilities lead to higher growth revenue
  generating services

43
Errata
Call flows in the paper, in particular, figures
2 (b,e,f,g) and figures 3 (c,d) depict an ACK
after the BYE-200 OK message sequence for SIP.
This is incorrect. No ACK follows this message
exchange. From RFC 2543 bis The ACK request
confirms that the client has received a final
response to an INVITE request.
BYE
200 OK
ACK
BYE
200 OK
ACK
44
Thank You