1. January 17, 2005SIP Summit1 SIP – are we there yet? Henning Schulzrinne (with Kundan Singh) Columbia University Department of Computer Science hgs@cs.columbia.edu (SIP Summit 2005, Honolulu, Hawaii) supported by

2. January 17, 2005SIP Summit2 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

3. January 17, 2005SIP Summit3 SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringingRFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy”dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

4. January 17, 2005SIP Summit4 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

5. January 17, 2005SIP Summit5 An eco system, not just a protocol SIP XCAP (config) RTSP SIMPLE policy RPID …. SDP XCON (conferencing) STUN TURN RTP configures initiatescarries controls provide addresses

6. January 17, 2005SIP Summit6 SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

7. January 17, 2005SIP Summit7 RFC publication

8. January 17, 2005SIP Summit8 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)

9. January 17, 2005SIP Summit9 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

10. January 17, 2005SIP Summit10 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 15 th instance just completed ETSI TTCN specs SIP Forum Certification Working Group

11. January 17, 2005SIP Summit11 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

12. January 17, 2005SIP Summit12 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

13. January 17, 2005SIP Summit13 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

14. January 17, 2005SIP Summit14 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

15. January 17, 2005SIP Summit15 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

16. January 17, 2005SIP Summit16 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)

17. January 17, 2005SIP Summit17 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

18. January 17, 2005SIP Summit18 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

19. January 17, 2005SIP Summit19 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

20. January 17, 2005SIP Summit20 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 IAX model SIP, H.323, MCGP model

21. January 17, 2005SIP Summit21 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

22. January 17, 2005SIP Summit22 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

23. January 17, 2005SIP Summit23 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

24. January 17, 2005SIP Summit24 VoIP end system configuration AOR MAC address registrar address STUN/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

25. January 17, 2005SIP Summit25 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

26. January 17, 2005SIP Summit26 NAT 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 … and then a miracle occurred

27. January 17, 2005SIP Summit27 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

28. January 17, 2005SIP Summit28 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

29. January 17, 2005SIP Summit29 P2P-SIP Background: DHT (Chord) Identifier circle Keys assigned to successor Evenly distributed keys and nodes Finger table: logN i th finger points to first node that succeeds n by at least 2 i-1 Stabilization for join/leave 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Keynode 8+1 = 914 8+2 = 1014 8+4 = 1214 8+8 = 1621 8+16=2432 8+32=4042

30. January 17, 2005SIP Summit30 P2P-SIP Design Alternatives 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) 1 8 14 21 32 38 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 24 30 54 38

31. January 17, 2005SIP Summit31 P2P-SIP Node architecture: registrar, proxy, user agent DHT communication using SIP REGISTER Known node: sip:15@192.2.1.3 Unknown node: sip:17@sippeer.net User: sip:alice@example.com User interface (buddy list, etc.)SIPICERTP/RTCPCodecsAudio devicesDHT (Chord) On startup DiscoverUser location Multicast REGPeer found/ Detect NAT REG REG, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Signout, transfer IM, call

32. January 17, 2005SIP Summit32 P2P-SIP Implementation 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

33. January 17, 2005SIP Summit33 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