SIP interoperability and SIP interoperability and extensionsextensions

Henning SchulzrinneDept. of Computer Science

Columbia University, New YorkNGN (Boston, MA)November 2004

OutlineOutline

SIP state of affairs SIP extensions and mechanism Common interoperability problems

intentional vs. unintentional How to encourage interoperability

SIP is PBX/Centrex readySIP is PBX/Centrex readycall waiting/multiple calls

RFC 3261

hold RFC 3264

transfer RFC 3515/Replaces

conference RFC 3261/callee caps

message waiting message summary package

call forward RFC 3261

call park RFC 3515/Replaces

call pickup Replaces

do not disturb RFC 3261

call coverage RFC 3261

from Rohan Mahy’s VON Fall 2003 talk

simultaneous ringing

RFC 3261

basic shared lines

dialog/reg. package

barge-in Join

“Take” Replaces

Shared-line “privacy”

dialog package

divert to admin RFC 3261

intercom URI convention

auto attendant RFC 3261/2833

attendant console

dialog package

night service RFC 3261

centr

ex-s

tyle

featu

res

boss/admin features

attendant features

A constellation of SIP RFCsA constellation of SIP RFCs

Resource mgt. (3312)Reliable prov. (3262)INFO (2976)UPDATE (3311)Reason (3326)SIP (3261)

DNS for SIP (3263)Events (3265)REFER (3515)

DHCP (3361)DHCPv6 (3319)

Digest AKA (3310)Privacy (3323)P-Asserted (3325)Agreement (3329)Media auth. (3313)AES (3853)

Non-adjacent (3327)Symmetric resp. (3581)Service route (3608)User agent caps (3840)Caller prefs (3841)

ISUP (3204)sipfrag (3240)

Security & privacy

Configuration

Core

Mostly PSTN

Content types

Request routing

SIP, SIPPING & SIMPLE –00 draftsSIP, SIPPING & SIMPLE –00 drafts

0

10

20

30

40

50

60

70

1999 2000 2001 2002 2003

SIPSIPPINGSIMPLE

includes draft-ietf-*-00 and draft-personal-*-00

When are we going to get When are we going to get there?there? In 2003, 6 SIP + 2 SIPPING RFCs published In 2002, 14 SIP + 4 SIPPING RFCs Currently, 24 SIP + 25 SIPPING + 18

SIMPLE WG Internet Drafts does not count individual drafts likely to be

“promoted” to WG status The .com consultant linear extrapolation

technique®

pessimist 8.5 more years if no new work is added to the queue

optimist 4 more years

SIP: designed for managed SIP: designed for managed extensionsextensions Engineered for managed long-term extensibility:

cannot assume that all implementations implement everything describe what to do with unknown protocol elements registry of header fields indication and discovery of features

New SIP header fields: ignored if unknown

provide more information, don’t change behavior avoid silly x- headers private, limited-users headers (branded with “P-”) most common extension today

New SIP methods rarely done outside standards discovery via OPTIONS request

SIP behavior changes via Require, Proxy-Require, Supported, Unsupported header fields

names behaviors, not fields

How to ensure protocol How to ensure protocol interoperabilityinteroperability Classical Internet approach: pairwise lab

testing Interoperability tests (“plug fests”)

multiple implementation, in various stages of maturity

results (and embarrassment) remain private Certification by neutral third parties

can never be complete Lab tests by consulting and publishing

companies SIP is using all of these

Interoperability effortsInteroperability efforts IETF SIPPING working

group call flow examples for basic

(RFC 3665), telephony (RFC 3666) and services (draft)

SIPit and SIMPLEt held every 6 months 15th instance just completed

ETSI TTCN specs

SIP Forum Certification Working Group

SIPit 14 (Feb. 2004)SIPit 14 (Feb. 2004) 128 attendees from 55 organizations

US, Canada, Israel, Japan, Taiwan, France, Germany, Belgium, UK, Turkey, India, Sweden, Finland, Norway

“The biggest strides between this event and the last were around correct support for TLS. The biggest weakness continues to be proper construction of offers and answers.”

Protocol interoperability Protocol interoperability problemsproblems Three core interoperability problems:

syntactic robustness “You mean you could have a space there?”

often occurs when testing only against common reference implementations

need “stress test” (also for buffer overflows) implementation by protocol example limiting assumptions (e.g., user name format) see “SIP Robustness Testing for Large-Scale Use”,

First International Workshop on Software Quality (SOQA)

semantic assumptions “I didn’t expect this error”

mutually incompatible extensions expect extension to make something work

Protocol interoperabilityProtocol interoperability Proprietary protocol

Example: Skype Can only reverse-engineer only backwards-compatibility

problems incentive to force upgrades (see Microsoft Word)

quicker evolution, but limited product selection less Metcalfe’s law value

Open standard, but dominant vendor Example: H.323 doesn’t matter what the standard says NetMeeting and H.323 test with Microsoft implementation limits feature evolution to dominant vendor speed

Open standard, multiple large and many small vendors Example: SIP hardware vs. software, UA vs. proxy, phones vs. gateways interoperability problems until product maturity harder to test internally against all (competing) products better long-term outcome, but slower

Why SIP extensions?Why SIP extensions? Good interoperability in basic call setup Extensions are sometimes indications

where work is needed or “I didn’t know this existed”

unfortunately, no good SIP Roadmap document some “wrong protocol, buddy” some “I don’t have the resources to

participate in standardization” currently, 68 SIP/SIPPING/SIMPLE I-Ds 26 SIP RFCs (+ 13 SIPPING RFCs)

SIP proprietary extensionsSIP proprietary extensions Examples based on

informal email survey Shared line support to

emulate key systems: not dialogs, but state of

AORs see SIMPLE

TCAP over SIP for LNP general: pick up

information along the way

Auto-answer support (intercom)

Caller-indicated ringing preferences

visual ringing Billing and dialing

plan Tone for charged vs.

free calls Caller name

identification added by proxies

P-Asserted-Identity extension

Call routing diagnostics

SIP proprietary extensions, SIP proprietary extensions, cont’dcont’d “upgrade your endpoint!” Caller time zone NAT support

STUN servers not widely available – no incentive

some use simple HTTP query (just needs cgi-bin) probably biggest advantage that Skype has

many, make SIP work well in old world on phone look-alikes

reason given: local interest only takes too long to standardize

SIP – a bi-cultural protocolSIP – a bi-cultural protocol

• overlap dialing• DTMF carriage• key systems• notion of lines• per-minute billing• early media• ISUP & BICC interoperation• trusted service providers

• multimedia• IM and presence• location-based service• user-created services• decentralized operation• everyone equally suspect

The SIP complexity fallacyThe SIP complexity fallacy IAX (for example) is simpler

than SIP but you could build the IAX

functionality in SIP at just about the same complexity:

no proxies no codec negotiation no distributed services

Difficulty: extracting those simple pieces from 269 pages of specification

SIP still more complex due to signaling-data separation

Signaling & Media Signaling & Media

Signaling Signaling

Media

IAX model

SIP, H.323, MCGP model

Operational complexityOperational complexity SIP design user only need

to know their SIP address (AOR) and a registration secret

familiar to users from web login

Not: outbound proxy STUN server registrar address backup server addresses Digest authentication user

name media port range tftp and HTTP server for

image updates …

Configuration failures hard to diagnose

Bad “out of the box” experience

Made worse by limited UI of end systems

Misleading or inconsistent terminology

“communication server” “user name”

Can’t have a manually configured configuration server

VoIP end system VoIP end system configurationconfiguration

AOR

MACaddress

registrar addressSTUN/TURN – local and global

general configuration document(media, UI, protocol behavior, …)

geographical location (for 911)outbound proxy

DNS

SIP SUBSCRIBE/NOTIFY

DHCP

that’s all it should take

NAT and VPN troublesNAT and VPN troubles Unplanned transition from

Internet = one global address space to clouds (“realms”) of unknown scope

Can’t know without help whether directly reachable

Any number of concentric spaces There is no universally

workable NAT solution always problems with inbound

calls may need to maintain and refresh

permanent connections to globally routable entity

may need relay agent for media (TURN)

?

?

?

home NAT

ISP NAT

Internet

NAT solutionsNAT solutions

well-defined NAT behavior allow informed deployment decisions

avoid “evil” NATs

NAT boxes with built-in address discovery and allocation

find STUN and TURN servers easily

IPv6

ConclusionConclusion

SIP is a mature protocol Almost all of the core features

necessary for common services are RFCs or well-baked Internet drafts

Interoperability more difficult in a multi-vendor environment

On-going efforts in multiple forums to improve interoperability