January 17, 2005SIP Summit1 SIP – are we there yet? Henning Schulzrinne (with Kundan Singh)...

January 17, 2005 SIP Summit 1

SIP – are we there yet?

Henning Schulzrinne(with Kundan Singh) Columbia University

Department of Computer [email protected]

(SIP Summit 2005, Honolulu, Hawaii)

supported by


Overview

SIP state of affairs: closing in on “done” Common interoperability problems

intentional vs. unintentional How to encourage interoperability The SIP configuration mess Peer-to-peer SIP


SIP 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 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


An eco system, not just a protocol

SIP

XCAP(config)

RTSP

SIMPLEpolicyRPID

….

SDP

XCON(conferencing)

STUNTURN

RTP

configures

initiates carries

carriescontrols provide addresses


SIP, SIPPING & SIMPLE –00 drafts

0

10

20

30

40

50

60

70

1999 2000 2001 2002 2003 2004

SIPSIPPINGSIMPLE

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


RFC publication

0

2

4

6

8

10

12

14

2001 2002 2003 2004

SIP

SIPPING

SIMPLE


When are we going to get there?

Currently, 14 SIP + 31 SIPPING + 19 SIMPLE WG Internet Drafts = 64 total does not count individual drafts likely to be “promoted” to

WG status

The .com consultant linear extrapolation technique®

pessimist 4 more years if no new work is added to the queue and we can keep up productivity

optimist 3 more years (lots of drafts are in almost-done stage)


How to ensure protocol interoperability

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 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


Protocol interoperability problems

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 interoperability: proprietary protocols

Proprietary protocol Example: Skype quicker evolution – not dependent on IETF “volunteers” with day jobs can do “hacks” without IESG objection:

media over TCP inefficient search bypass routing policies circumvent firewall policies

Can only reverse-engineer only backwards-compatibility problems incentive to force upgrades (see Microsoft Word)

less Metcalfe’s law value


Why is Skype successful? All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience

Software vendor = service provider Didn’t know that you couldn’t do voice quality beyond PSTN

others too focused on PSTN interoperability – why do better voice than PSTN?

Simpler solutions for NAT traversal use TCP if necessary use port 80

Did encryption from the very beginning Kazaa marketing vehicle


Open standard, 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 and interests


Open standard, multiple vendors Example: SIP More than just one application:

Software UAs, proxies, phones, gateways, media servers, test tools, OA&M, …

interoperability problems until product maturity harder to test internally against all (competing) products divergent views and communities in IETF and other SDOs

likely have to support union of requirements emphasis on extensibility, modularity and protocol re-use

temptation to not implement everything security

SIP: generality over efficiency better long-term outcome, but slower


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 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, cont’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 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 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 (+ SDP + RTP)

SIP still more complex due to signaling-data separation

Signaling & Media Signaling & Media

Signaling Signaling

Media

IAX model

SIP, H.323, MCGP model


Does it have to be that complicated?

• highly technical parameters, with differing names• inconsistent conventions for user and realm• made worse by limited end systems (configure by multi-tap)• usually fails with some cryptic error message and no indication which parameter• out-of-box experience not good


Solving the configuration mess Initial development assumed enterprise deployment

pre-configured via tftp or (rarely) DHCP not suitable for residential use, except if box is shipped pathetic security – password accessible to anybody who knows

MAC address of phone Short term

adopt simple default conventions should only need SIP URI (AoR), display name and password

realm = URI outbound proxy = domain

provide and expose error feedback not “authentication failure” but “realm not recognized – change to user@domain format”

use DNS NAPTR and SRV for STUN server


Solving the configuration mess – longer term

IETF efforts on configuration management retrieve via HTTP (+ TLS) change notification via SIP event notification problem of configuring initial secret remains probably need embedded public keys

Still need better diagnostics one-way voice issues authentication failures


VoIP end system configuration

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 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


Server-based vs peer-to-peer

Server-based Cost: maintenance, configuration Central points of failures Managed SIP infrastructure Controlled infrastructure (e.g., DNS)

Peer-to-peer Robust: no central dependency Self organizing, no configuration Scalability ?

C

C

C

C

C

S

P

P

P

P

P


P2P-SIP

Differences to proprietary Skype architecture Robust and efficient lookup using DHT Interoperability

DHT algorithm uses SIP protocol messages Hybrid architecture

First try DNS NAPTR/SRV if no SIP server there, then lookup in SIP+P2P

Unlike file-sharing applications Data storage, caching, delay, reliability

Disadvantages Lookup delay and security


P2P-SIPBackground: DHT (Chord)

Identifier circle Keys assigned to successor Evenly distributed keys and nodes Finger table: logN

ith finger points to first node that succeeds n by at least 2i-1

Stabilization for join/leave

1

8

14

21

32

38

58

47

10

2430

54

38

42

Key node

8+1 = 9 14

8+2 = 10 14

8+4 = 12 14

8+8 = 16 21

8+16=24 32

8+32=40 42


P2P-SIPDesign Alternatives

65a1fc

d13da3

d4213f

d462bad467c4

d471f1

d46a1c

Route(d46a1c)

18

14

21

3238

58

47

10

24 30

54

38

42

Use DHT in server farm

Use DHT for all clients; But some are resource limited

Use DHT among super-nodes

servers

clients

1

10

2430

54

38


P2P-SIPNode architecture: registrar, proxy, user agent

DHT communication using SIP REGISTER Known node: sip:[email protected] Unknown node: sip:[email protected] User: sip:[email protected]

User interface (buddy list, etc.)

SIPICE RTP/RTCP

Codecs

Audio devicesDHT (Chord)

On startup

Discover

User location

Multicast REGPeer found/Detect NAT

REGREG, INVITE,MESSAGE

Signup,Find buddies

JoinFind

Leave

On resetSignout,transfer

IM,call


P2P-SIPImplementation

sippeer: C++, Linux, Chord Nodes join and form the DHT Node failure is detected and

DHT updated Registrations transferred on

node shutdown only need extension for

avoiding outbound proxy confusion

Co-located “classical” UA can use sippeer service with a P2P “adaptor” (built)

1

11

9

30

26

31

15

29

25

19

31

26


Conclusion

SIP is now a mature protocol, with a surrounding eco system

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

Out-of-box experience needs work Can do peer-to-peer SIP without significant protocol

extensions – complementary, does not replace existing model

Date post:	21-Dec-2015
Category:	Documents
View:	214 times
Download:	1 times

January 17, 2005SIP Summit1 SIP – are we there yet? Henning Schulzrinne (with Kundan Singh)...

Documents