SIP: Ready to Deploy Jonathan Rosenberg Chief Scientist.

SIP: Ready to Deploy

Jonathan Rosenberg

Chief Scientist

www.dynamicsoft.comdynamicsoft Inc.

C O N N E C T I N G T H E W O R L D W I T H A P P L I C A T I O N S

Overview Need for Differentiation

SIP Is a Tool for Differentiation Combined services

Programmability

Extensibility

Deployable Momentum

Interoperability results

IETF standards process



What Is The Reality? Toll-bypass Has Been the Primary Motivation

Cheap long distance Service transparency

Cost Differentials Are Rapidly Disappearing Long distance is now at 5 cents a minute Partial flat rate plans are being rolled out Canadian service providers have moved to a complete flat rate structure

Service Transparency Is Far Away QoS issues 911, 1000 features in the 5ESS Huge existing penetration of the phone in US and worldwide



The Question Of Customer Value

IP Telephony Service Isn’t Cheaper, Better or Different, Why Purchase It?



The Big Answer IP Telephony Brings Together Disparate Services -

Innovative Services Created by Combining Other IP Applications, Such as Web, Email, Chat and Presence, with Voice

The Killer App for VoIP Lives Within These Combined Services



Combined Services Enable Provider Differentiation Combined Services Yield the

Feature Exponentiation Effect The number of possible features grows

exponentially with the set of applications combined to provide those features

With Many Feature Possibilities, Service Provider Differentiation Becomes a Reality

Voice Voice +Web

Voice +Web +Email

Voice +Web +

Email +Presence



Requirements for Enabling Combined Services Needs to Work Among Heterogeneous Devices

PC access

Traditional PSTN access

Stand-alone IP phone access

Needs to Work Among Heterogeneity of Capabilities Some devices have web

Some devices have email

Some devices have no video



Requirements for Enabling Combined Services Needs to Integrate Seamlessly with Web and Email

Should understand http and mailto URLs

Should be able to carry web pages

Should be able to start calls by clicking on hyperlinks

Should be able to carry Java applets

Should be able to work with email naming and routing facilities



Programmability Key Requirements Rapid Service Deployment Is Critical

Should Be as Easy to Create a New Phone Service as Building a Web Page Compare PSTN service deployment cycles with Web service

deployment cycles

Should Be Accessible to All Service providers

Enterprise administrators

End users



Key Requirements Focus Simple Protocol Models

Simple APIs

Open APIs

Open Access to Service Plane



Solution: Session Initiation Protocol (SIP) Heterogeneity of capabilities

solved: MIME

MIME = Multipurpose Internet Mail Extensions

Used to support transfer of different content in email and web

Defines numerous headers for indication and negotiation of content

Allows clients to indicate types supported in SIP messages

Web pages Java applets JPEGs

PSTNGateway

Proxy

INVAccept: text/html, application/sdp

INVAccept: application/sdp

Contact: sip:[email protected]

Contact: http://www.bus.com



Solution: SIP Heterogeneity of Devices Solved: Implementation

Flexibility SIP specification defines several levels of implementation

Minimal Basic Firewall-friendly Redirection Negotiation Authentication

Required headers at each level defined



Solution: SIP continued

Minimal Implementation Is Interoperable and Thin Known implementations in standalone phones < 128K

Full Implementation Is More Complex but Extremely Powerful



SIP Integration with Web and Email SIP Works Very Well with Web and Email

Three Fundamental Reasons MIME

URIs

DNS



SIP and MIME SIP Uses MIME for Body Transport

Allows access to vast registry of MIME types

Allows usage of numerous encoding and compression techniques

Allows usage of basic negotiation capabilities

SIP Allows Web Pages, Pictures and Documents to Be Carried

Can Even Use Multi-part for Several Bodies Per Message



SIP and URIs URI

Uniform Resource Identifier - generalization of familiar URL

SIP “Addresses” Are URLs Specifies SIP URL format, similar to mailto

SIP Allows Any URI Wherever SIP URL Can Be Placed

Applications Can redirect to web page as easily as PC phone

Can redirect to complex http URLs to provide web server with data



SIP and DNS Email is Routed in Part, Based on DNS Procedures

SIP Uses Nearly Identical Procedures

SIP Allows Email Address to be Valid SIP Address

Implications Can completely leverage existing email routing systems

Forwarding of SIP requests to email is trivial

Save space on the business card



Programmability of SIP SIP Has a Simple Architecture

Request-response

Proxies

SIP Architecture Parallels Web

Result Numerous SIP APIs under development in standards

JAIN SIP servlets XML-based Call Processing Language (CPL)

Can leverage existing web programmability tools Common Gateway Interface (CGI)



SIP Momentum Vendors and Operators are Now Choosing SIP

Softswitches (MGC), gateways, endpoints, application servers

SIP-based networks and services (MCI, Level(3), AT&T)

SIP in The Pulver Report “If you are responsible for building products in the VON industry, you

will be making a major mistake if your plans for 2000/2001 don't include support for SIP”

Jeff Pulver Oct 21, 1999



SIP Momentum continued

SIP Working Group Created in the IETF Chaired by dynamicsoft

19 Submissions at the first meeting

Interim meeting was held before the first meeting to discuss cable protocols (DCS)

Other Standards Bodies are Endorsing SIP ETSI Tiphon, traditionally H.323 only, now working on SIP

IMTC has a SIP group, and is now working on SIP-H.323 interop



SIP Bake-Off Update

Mar Apr Aug Dec

100

50

0

Nu

mb

er

of

Att

en

de

es

Ericsson

SIP AcceptedBy IETF

8 Companies

16 Companies

33 Companies



December ‘99 Bake-off Results 33 Vendors, Over 100 People

Most Major Equipment Vendors

Complex Call Scenario Completed 7 Different vendors dynamicsoft was the only

commercial vendor capable of executing main proxy function

Call scenario included: Proxy-Authorization TCP to UDP CANCEL Record Route Reverse BYE

Proxy 1

TCP

UserAgent 1

UserAgent 2

UserAgent 3

UserAgent 4

Proxy 3

Proxy 2



IETF Standards Process IETF Process Built for Interoperability

Three Phases of an RFC Proposed standard - believed to work

SIP is proposed standard

Draft standard - known implementations

Must demonstrate interop on all features

Unused features discarded

Standard - widely deployed



Summary IP Telephony Must Provide Differentiation

Critical Requirements for Differentiation Defined Interoperability with existing IP apps

Handles heterogeneity

Programmable

SIP Meets These Requirements

SIP Has Momentum, Acceptance and Interoperability

Ready to Deploy!



Information Resource Jonathan Rosenberg

[email protected]

+1 732.741.7244

SIP: Ready to Deploy Jonathan Rosenberg Chief Scientist.

Documents

t i o n s requirements

t i o n s solution

t i o n s combined services

t i o n s sip integration

t i o n s key requirements

t i o n s overview need

combined services slide

service plane slide