1. VoIP: Not your grandmother's phone any more Henning Schulzrinne Dept. of Computer Science, Columbia University, New York (based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and SIMPLE WGs) hgs@cs.columbia.edu Rutgers University April 2009

2. 2 Outline VoIP maturing: vision vs. reality –presence and location-based services –user-programmable services VoIP challenges –scaling –peer-to-peer systems –spam/SPIT –emergency calling The state of SIP standardization, year 11 –developments in 2006 & upcoming highlights –trouble in standards land –interoperability

3. 3 The three Cs of Internet applications communications communitycommerce grossly simplified... research focus what users care about

4. 4 Killer Application Carriers looking for killer application –justify huge infrastructure investment –“video conferencing” (*1950 – †2000) –?–? “There is no killer application” –Network television block buster  YouTube hit –“Army of one” –Users create their own custom applications that are important to them –Little historical evidence that carriers (or equipment vendors) will find that application if it exists Killer app = application that kills the carrier

5. 5 Collaboration in transition intra-organization; small number of systems (meeting rooms) inter-organization multiple technology generations diverse end points proprietary (single- vendor) systems standards-based solutions

6. 6 Evolution of VoIP “amazing – the phone rings” “does it do call transfer?” “How can I make it stop ringing?” 1996-20002000-20032004-2005 catching up with the digital PBX long-distance calling, ca. 1930 going beyond the black phone 2006- “Can it really replace the phone system?” replacing the global phone system

7. 7 IETF VoIP efforts SIP (protocol) SIPPING (usage, requirements) ECRIT (emergency calling) AVT (RTP, SRTP, media) ENUM (E.164 translation) IPTEL (tel URL) SIMPLE (presence) GEOPRIV (geo + privacy) usesmay use uses provides usually used with IETF RAI area MMUSIC (SDP, RTSP, ICE) XCON (conf. control) SPEERMINT (peering) uses SPEECHSC (speech services) SIGTRAN (signaling transport) uses

8. 8 Old vs. new old realitynew ideanew reality service provider ILEC, CLEC email-like, run by enterprise, homes E.164-driven; MSOs, some ILECs, Skype, European SIP providers, Vonage, SunRocket media4 kHz audiowideband audio, video, IM, shared apps, … 4 kHz audio servicesCLASS (CLID, call forwarding, 3-way calling,...) user-created services (web model) presence still CLASS user IDsE.164email-likeE.164 IM handles

9. 9 SIP Overview

10. 10 Internet services – the missing entry Service/deliverysynchronousasynchronous pushinstant messaging presence event notification session setup media-on-demand messaging pulldata retrieval file download remote procedure call peer-to-peer file sharing

11. 11 Filling in the protocol gap Service/deliverysynchronousasynchronous pushSIP RTSP, RTP SMTP pullHTTP ftp SunRPC, Corba, SOAP (not yet standardized)

12. 12 SIP as service enabler Rendezvous protocol –lets users find each other by only knowing a permanent identifier Mobility enabler: –personal mobility one person, multiple terminals –terminal mobility one terminal, multiple IP addresses –session mobility one user, multiple terminals in sequence or in parallel –service mobility services move with user

13. 13 What is SIP? Session Initiation Protocol  protocol that establishes, manages (multimedia) sessions also used for IM, presence & event notification uses SDP to describe multimedia sessions Developed at Columbia U. (with others) Standardized by IETF (RFC 3261-3265 et al) 3GPP (for 3G wireless) PacketCable About 100 companies produce SIP products Microsoft’s Windows Messenger (≥4.7) includes SIP

14. 14 Philosophy Session establishment & event notification Any session type, from audio to circuit emulation Provides application-layer anycast service Provides terminal and session mobility Based on HTTP in syntax, but different in protocol operation Peer-to-peer system, with optional support by proxies –even stateful proxies only keep transaction state, not call (session, dialogue) state –transaction: single request + retransmissions –proxies can be completely stateless

15. 15 Basic SIP message flow

16. 16 SIP trapezoid outbound proxy a@foo.com: 128.59.16.1 registrar 1 st request 2 nd, 3 rd, … request voice traffic RTP destination proxy (identified by SIP URI domain)

17. 17 SIP message format SDP INVITE sip:bob@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 v=0 o=alice 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 v=0 o=bob 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 message body header fields request line request response

18. 18 PSTN vs. Internet Telephony Signaling & Media Signaling Media PSTN: Internet telephony: China Belgian customer, currently visiting US Australia

19. 19 SIP addressing Users identified by SIP or tel URIs –sip:alice@example.com tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) tel URIs  SIP URIs by outbound proxy A person can have any number of SIP URIs The same SIP URI can reach many different phones, in different networks –sequential & parallel forking SIP URIs can be created dynamically: –GRUUs –conferences –device identifiers (sip:foo@128.59.16.15) Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR) tel:110 sip:sos@domain domain  128.59.16.17 via NAPTR + SRV

20. 20 3G Architecture (Registration) visited IM domain home IM domain serving CSCF interrogating proxy interrogating mobility management signaling registration signaling (SIP)_

21. Presence and event notification

22. 22 We need glue! Lots of devices and services –cars –household –environment Generally, stand-alone –e.g., GPS can’t talk to camera Home –home control networks have generally failed cost, complexity Environment –“Internet of things” –tag bus stops, buildings, cars,...

23. 23 Left to do: event notification notify (small) group of users when something of interest happens –presence = change of communications state –email, voicemail alerts –environmental conditions –vehicle status –emergency alerts kludges –HTTP with pending response –inverse HTTP --> doesn’t work with NATs Lots of research (e.g., SIENA) IETF efforts starting –SIP-based –XMPP

24. 24 Context-aware communication context = “the interrelated conditions in which something exists or occurs” anything known about the participants in the (potential) communication relationship both at caller and callee timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)privacy issues similar to location data

25. 25 The role of presence Guess-and-ring –high probability of failure: “telephone tag” inappropriate time (call during meeting) inappropriate media (audio in public place) –current solutions: voice mail  tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned automated call back  rarely used, too inflexible –  most successful calls are now scheduled by email Presence-based –facilitates unscheduled communications –provide recipient-specific information –only contact in real-time if destination is willing and able –appropriately use synchronous vs. asynchronous communication –guide media use (text vs. audio) –predict availability in the near future (timed presence) Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

26. 26 GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface XCAP (rules) INVITE DHCP

27. 27 Presentity and Watchers Bob’s status, location Watchers Invisible Available, Busy, Somewhat available, Invisible wife son external world PUBLISH SUBSCRIBE NOTIFY Bob’s Presentity Watchers Bob’s Presence User Agents (PUA) PC-IM Client R u there ? Bob’s play station Cell Phone BUZZ PUBLISH Bob’s Filters (Rules), PIDF *) Presence Server (PS) *) - PIDF = Presence Information Data Format friend

28. 28 Basic presence Role of presence –initially: “can I send an instant message and expect a response?” –now: “should I use voice or IM? is my call going to interrupt a meeting? is the callee awake?” Yahoo, MSN, Skype presence services: –on-line & off-line useful in modem days – but many people are (technically) on-line 24x7 thus, need to provide more context –+ simple status (“not at my desk”) entered manually  rarely correct does not provide enough context for directing interactive communications

29. 29 Presence data architecture raw presence document create view (compose) privacy filtering draft-ietf-simple-presence-data-model composition policy privacy policy presence sources XCAP (not defined yet) depends on watcher select best source resolve contradictions PUBLISH

30. 30 Presence data architecture candidate presence document watcher filter raw presence document post-processing composition (merging) final presence document difference to previous notification SUBSCRIBE NOTIFY remove data not of interest watcher

31. 31 Presence data model “calendar”“cell”“manual” alice@example.com audio, video, text r42@example.com video person (presentity) (views) services devices

32. 32 Rich presence More information automatically derived from –sensors: physical presence, movement –electronic activity: calendars Rich information: –multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”) –activities, current and planned –surroundings (noise, privacy, vehicle, …) –contact information –composing (typing, recording audio/video IM, …)

33. 33 RPID: rich presence

34. 34 RPID = rich presence Provide watchers with better information about the what, where, how of presentities facilitate appropriate communications: –“wait until end of meeting” –“use text messaging instead of phone call” –“make quick call before flight takes off” designed to be derivable from calendar information –or provided by sensors in the environment allow filtering by “sphere” – the parts of our life –don’t show recreation details to colleagues

35. 35 CIPID: Contact Information More long-term identification of contacts Elements: –card – contact Information –home page –icon – to represent user –map – pointer to map for user –sound – presentity is available

36. 36 The role of presence for call routing Two modes: –watcher uses presence information to select suitable contacts advisory – caller may not adhere to suggestions and still call when you’re in a meeting –user call routing policy informed by presence likely less flexible – machine intelligence “if activities indicate meeting, route to tuple indicating assistant” “try most-recently-active contact first” (seq. forking) LESS translate RPID CPL PA PUBLISH NOTIFY INVITE

37. 37 Presence and privacy All presence data, particularly location, is highly sensitive Basic location object (PIDF-LO) describes –distribution (binary) –retention duration Policy rules for more detailed access control –who can subscribe to my presence –who can see what when <gml:Point gml:id="point1“ srsName="epsg:4326"> 37:46:30N 122:25:10W no 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z

38. 38 Privacy policy relationships geopriv-specificpresence-specific common policy RPIDCIPID future

39. 39 Privacy rules Conditions –identity, sphere –time of day –current location –identity as or + Actions –watcher confirmation Transformations –include information –reduced accuracy User gets maximum of permissions across all matching rules –privacy-safe composition: removal of a rule can only reduce privileges Extendable to new presence data –rich presence –biological sensors –mood sensors

40. 40 Example rules document user@example.com allow sip mailto true bare

41. 41 Creating and manipulating rules Uploaded in whole or part via XCAP XML not user-visible Web or application UI, similar to mail filtering Can also be location-dependent –“if at home, colleagues don’t get presence information” Possibly implementation-defined “privacy levels”

42. Location-based services

43. 43 Location-based services Finding services based on location –physical services (stores, restaurants, ATMs, …) –electronic services (media I/O, printer, display, …) –not covered here Using location to improve (network) services –communication incoming communications changes based on where I am –configuration devices in room adapt to their current users –awareness others are (selectively) made aware of my location –security proximity grants temporary access to local resources

44. 44 Location-based SIP services Location-aware inbound routing –do not forward call if time at callee location is [11 pm, 8 am] –only forward time-for-lunch if destination is on campus –do not ring phone if I’m in a theater outbound call routing –contact nearest emergency call center –send delivery@pizza.com to nearest branchdelivery@pizza.com location-based events –subscribe to locations, not people –Alice has entered the meeting room –subscriber may be device in room  our lab stereo changes CDs for each person that enters the room

45. 45 Location delivery DHCP HTTP GPS HELD LLDP-MED wire map

46. 46 Location-based service language false true NOTIFY action alert conditions proximity occupancy time IM actions alert message log call transfer join events incoming outgoing notify message subscription

47. 47 Program location-based services

48. 48

49. 49 *) - Verizon Service Assurance Business Intelligence Toolkit Application: Verizon SABIT PALS SABIT = web-based mobile employee productivity management system PALS - Presence-Aware Location-Based Service –Advanced communication services based on aggregation of presence information –Enhanced vehicle management system Presence/availability information of a user is combined with the location information (of the vehicle) to achieve an integrated communication environment –“only call when vehicle is stopped”

50. 50 SABIT PALS Solution Integrates: Status and diagnostic information of the vehicle Mobile employee’s location data obtained from a GPS device in a vehicle Mobile employee’s presence information data obtained from his/her cell-phone Laptop-based IM/VoIP soft client

51. 51 GPS EVDO WiFi VZ Data/Real Time VZ VPN Field Tech Laptop-Connect via WiFi or Ethernet Components of PALS architecture Integrated In-Vehicle Device (IIVD – Vehicle Events) SABIT System HTTP-SIP Gateway (LBS Presence User Agent) Media Server Watcher or Supervisor Application Presence Server (PS)

52. 52 SABIT PALS Architecture PUBLISH Presence Server NOTIFY DB MSC/HLR SUBSCRIBE Watcher SABIT System Mobile Employee’s status is relayed through multiple devices EVDO GPS SIP Proxy Systems View DB HTTP/ SIP Gateway HTTP Location from vehicle PUBLISH Media Server Gateway SABIT Supervisor “sees” mobile employees via the web-interface

53. 53 SABIT PALS Supervisor Application

54. 54 Communications Webpage

55. 55 Roadmap Introduction Presence Location-based services Server scaling P2P SIP Standardization and interoperability

56. 56 SIP server overload Proxies will return 503 --> retry elsewhere Just adds more load Retransmissions exacerbate the problem overloaded INVITE 503 Springsteen tickets!! earthquake vote for your favorite…

57. 57 Avalanche restart Large number of terminals all start at once Typically, after power outage Overwhelms registrar Possible loss of registrations due to retransmission time-out #300,000 #1 reboot after power outage REGISTER

58. 58 Overload control Current discussion in design team Feedback control: rate-based or window-based Avoid congestion collapse Deal with multiple upstream sources capacity goodput offered load

59. 59 Coordinated Overload Control Architecture Coordinated overload control with explicit feedback ietf-hilt draft model Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end hop-by-hop feedback is generally believed to be more feasible

60. 60 Scaling servers & TCP Need TCP –TLS support: customer privacy, theft of service, … particularly for WiFi –many SIP messages now exceed reasonable UDP size (fragmentation) e.g., INVITE for IMS: 1182 bytes Concern: UA support –improving: 82% of systems at recent SIPit’19 had TCP support –only 45% support TLS Concern: TCP (and TLS) much less efficient than UDP –running series of tests to identify differences –difference mainly in connection setup cost message splitting (may need pre- parsing or incremental parsers) thread count (one per socket?) Our model: –300,000 customers/servers 0.1 Erlang, 180 sec/call –600,000 BHCA --> 167 req/sec –300,000 registrations --> 83 req/sec –$0.001/subscriber

61. 61 SIP server measurements Initial INVITE measurements –OpenSER –400 calls/sec for TCP –roughly 260 calls/sec for TLS sipd REGISTER test Kumiko Ono, Charles Shen, Erich Nahum TCP

62. 62 Roadmap Introduction Presence Location-based services Server scaling P2P SIP Standardization and interoperability

63. 63 LAN P2P SIP Why? –no infrastructure available: emergency coordination –don’t want to set up infrastructure: small companies –Skype envy :-) P2P technology for –user location only modest impact on expenses but makes signaling encryption cheap –NAT traversal matters for relaying –services (conferencing, …) how prevalent? New IETF working group formed –likely, multiple DHTs –common control and look-up protocol? P2P provider A P2P provider B p2p network traditional provider DNS zeroconf generic DHT service

64. 64 P2P SIP -- components Multicast-DNS (zeroconf) SIP enhancements for LAN –announce UAs and their capabilities Client-P2P protocol –GET, PUT mappings –mapping: proxy or UA P2P protocol –get routing table, join, leave, … –independent of DHT? –replaces DNS for SIP, not proxy

65. 65 Zeroconf: solution for bootstrapping Three requirements for zero configuration networks: 1)IP address assignment without a DHCP server 2)Host name resolution without a DNS server 3)Local service discovery without any rendezvous server Solutions and implementations: –RFC3927: Link-local addressing standard for 1) –DNS-SD/mDNS: Apple’s protocol for 2) & 3) –Bonjour: DNS-SD/mDNS implementation by Apple –Avahi: DNS-SD/mDNS implementation for Linux and BSD

66. 66 DNS-SD/mDNS overview DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR: _daap._tcp.local. PTR Tom’s Music._daap._tcp.local. _daap._tcp.local. PTR Joe’s Music._daap._tcp.local. Tom’s Music._daap._tcp.local. SRV 0 0 3689 Toms-machine.local. Tom’s Music._daap._tcp.local. TXT "Version=196613" "iTSh Version=196608" "Machine ID=6070CABB0585" "Password=true” Toms-machine.local. A 160.39.225.12 Multicast DNS (mDNS) –Run by every host in a local link –Queries & answers are sent via multicast –All record names end in “.local.” 1:n mapping

67. 67 z2z: Zeroconf-to-Zeroconf interconnection rendezvous point - OpenDHT z2z Import/export services Zeroconf subnet A z2z Import/export services Zeroconf subnet B

68. 68 Demo: global iTunes sharing Exporting iTunes shares under key “columbia”: $ z2z --export:opendht _daap._tcp --key “columbia” Importing services stored under key “columbia”: $ z2z --import:opendht --key “columbia”

69. 69 How z2z works (exporting) OpenDHT z2z Send browse request (i.e., PTR query) for service type: _daap._tcp 1) Tom’s Music. _daap._tcp.local Joe’s Music. _daap._tcp.local Send resolve request (i.e., SRV, A, and TXT query) for each service 2) 160.39.225.12 Tom’s Computer Password=true …… 160.39.225.13 Joe’s Computer Password=false …… Export them by putting into OpenDHT 3) put: key= z2z._daap._tcp.columbia value= Tom’s Music 160.39.225.12:3689 Password=true ……

70. 70 How z2z works (importing) OpenDHT z2z Issue get call into OpenDHT 1) Add “A” record into mDNS 2) Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS) 3) get: key=z2z._daap._tcp.columbia value=Tom’s Music 160.39.225.12:3689 …… value=Joe’s Music …… mDNS “A” record for 160.39.225.12 Tom’s Music._daap._tcp.local _remote-160.39.225.12.local ……

71. 71 z2z implementation C++ Prototype using xmlrpc-c for OpenDHT access –Proof of concept –Porting problem due to Bonjour and Cygwin incompatibility z2z v1.0 released –Rewritten in Java from scratch –Open-source (BSD license) –Available in SourceForge (https://sourceforge.net/projects/z2z)https://sourceforge.net/projects/z2z Paper describing design and implementation detail –z2z: Discovering Zeroconf Services Beyond Local Link Lee, Schulzrinne, Kellerer, and Despotovic –Submitted to IEEE Globecom’07 Workshop on Service Discovery

72. 72 Zeroconf for SIP Enable SIP communication when proxy and registrar are not available –Good use case for z2z –Fill in the gap of P2P-SIP effort: local & small scale (10s to 100s) high mobility avoid construction of DHT Internet Draft published and presented at IETF-68 –SIP URI Service Discovery using DNS-SD Lee, Schulzrinne, Kellerer, and Despotovic http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01

73. 73 SIP URI advertisement Example _sipuri._udp.local. PTR sip:bob@a.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local. sip:bob@a.com._sipuri._udp.local. SRV 0 0 5060 bobs-host.local. sip:bob@a.com._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:bob@bobs-host.local. Service instance name: Instance.Service.Domain –Instance = ( SIP-URI / SIPS-URI ) [ SP description ] –Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp” –E.g.) sip:bob@example.com - PDA._sipuri._udp.local. Contact TXT record attribute –Similar to Contact SIP header except: It contains only a single URI Non-SIP URIs are not allowed –UA capabilities advertised via field parameters (RFC3840)

74. Peer-to-Peer Protocol (P2PP) Salman Abdul Baset, Henning Schulzrinne Columbia University

75. 75 Overview Objective: key  (opaque) data –distributed data structure with O(log N) or O(1) [rarely] Practical issues in peer-to-peer systems Peer-to-peer systems –file sharing –VoIP –streaming P2PSIP architecture Peer-to-peer protocol (P2PP) P2PP design issues Implementation

76. 76 Practical issues in peer-to-peer systems Bootstrap / service discovery NAT and firewall traversal TCP or UDP? Routing-table management Operation during churn Availability and replication Identity and trust management

77. 77 Peer-to-peer systems File sharing VoIPStreaming Low Medium High NAT Data size Performance impact / requirement Service discovery Replication

78. 78 P2PSIP: Concepts Decentralized SIP –Replace SIP proxy and registrar with p2p endpoints Supernode architecture –P2PSIP peers participate in the p2p overlay –P2PSIP clients use peers to locate users and resources

79. 79 P2PSIP architecture SIP P2PSTUN TLS / SSL A peer in P2PSIP NAT A client alice@example.com bob@example.com [ Bootstrap / authentication server ] Overlay1 Overlay2

80. 80 Peer-to-Peer Protocol (P2PP) P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management. Goals –A protocol to potentially implement any structured or unstructured protocol. –Not dependent on a single DHT or p2p protocol Not a new DHT! It is hard! –Too many structured and unstructured p2p protocols –Too many design choices! Lets consider DHTs

81. 81 DHTs DHTGeometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table) Chord Accordion Ring Modulo numeric difference Successor listFinger table Tapestry, Pastry, Bamboo Hybrid = Tree + Ring Prefix match. If fails, then modulo numeric difference Leaf-set (Pastry)Routing table KademliaXORXOR of two IDsNoneRouting table

82. 82 Kademlia XOR Finger table Parallel requests Recursive routingPastry Bamboo Chord Successor Modulo addition Prefix-match Leaf-set Routing-table stabilization Lookup correctness Lookup performance Proximity neighbor selection Proximity route selection Routing-table size Strict vs. surrogate routing OneHop Bootstrapping Updating routing-table from lookup requests Tapestry Ring Tree Hybrid Reactive recovery Periodic recovery Accordion Routing-table exploration

83. 83 How to design P2PP? Structured –Identify commonalities in DHTs Routing table (finger table) Neighbor table (successor list, leaf-set) –Separate core routing mechanisms from from DHT-independent issues. Unstructured –may not always find all keys Incorporate mechanisms for –discovery –NAT / firewall traversal –churn, identity and trust management –request routing (recursive / iterative / parallel)

84. 84 Parallel requests Recursive routing Routing-table stabilization Proximity neighbor selection Proximity route selection Bootstrapping Reactive vs. periodic recovery DHT-independent Kademlia XOR Pastry BambooChord Modulo addition Prefix-match OneHop Tapestry Ring Tree Hybrid DHT-specific Accordion Finger table / routing table Successor / leaf-set Lookup correctness Lookup performance Routing-table size Strict vs. surrogate routing Updating routing-table from lookup requests DHT-specific Not restricted to one DHT Routing-table exploration Geometry How to design P2PP?

85. 85 Chord (Strict routing-table management) Neighbor table (successor) Node x+2 i x+2 i+1 x+2 i+2 x+2 i+3 id=x Routing table Immediately succeeds routing-table id

86. 86 Peer-to-Peer Protocol (P2PP) A binary protocol Geared towards IP telephony but equally applicable to file sharing, streaming, and p2p-VoD Multiple DHT and unstructured p2p protocol support Application API NAT traversal –using STUN, TURN and ICE –ICE encoding in P2PP Request routing –recursive, iterative, parallel –per message Supports hierarchy (super nodes [peers], ordinary nodes [clients]) Reliable or unreliable transport (TCP or UDP)

87. 87 Peer-to-Peer Protocol (P2PP) Security –DTLS, TLS, signatures Multiple hash function support –SHA1, SHA256, MD4, MD5 Diagnostics –churn rate, messages sent/received Node capabilities –bw determination, CPU utilization, number of neighbors, mobility

88. 88 Join JPBSP5P7 1. Query 2. 200 P5, P30, P2P-Options 4. Join 9. 200 N(P9, P15) 5. Join 7. 200 P9 JP (P10) 8. Join 6. 200 N(P9, P15) 10. Transfer 11. 200 3+. STUN (ICE candidate gathering)

89. 89 Call establishment P1P3P5P7 1. Lookup-Peer (P7) 5. 200 (P7 Peer-Info) 2. Lookup-Peer (P7) 3. Lookup-Peer (P7) 4. 200 (P7 Peer-Info) 6. 200 (P7 Peer-Info) 7. INVITE 8. 200 Ok 9. ACK Media

90. 90 Implementation Chord, Kademlia, Bamboo (in-progress) SHA1, SHA256, MD5, MD4 Windows, Linux Integrated with OpenWengo (VoIP phone) Available for download (Linux + Windows) http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html

91. 91 Implementation Transport / timers Node BigInt Parser / encoder UDPTCP Transactions ClientBootstrapChordPeerKadPeerOtherPeer Sys insert (key, value, callback) callback (resp) lookup (key, callback) Routing table Neighbor table Distance

92. 92 Screen snapshot Alice and Bob are part of Kademlia network Alice calls Bob The lookup is performed using P2PP Call is established using SIP

93. 93 P2P summary P2P techniques now becoming mainstream –motivated by low opex, ease of deployment –building block, rather than application Many operational issues –interconnection: z2z –local peering: Bonjour for SIP –start-up and recovery: cf. Skype failure P2PP: Common platform protocol –application-neutral –extensible mechanism

94. 94 Roadmap Introduction Presence Location-based services Server scaling P2P SIP Standardization and interoperability

95. 95 SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

96. 96 RFC publication

97. 97 IETF WG: SIP in 2006 & 2007 ~ 44 SIP-related RFCs published in 2006 –BFCP, conferencing –SDP revision –rich presence Activities: –hitchhiker’s guide –infrastructure: GRUUs (random identifiers) URI lists XCAP configuration SIP MIB –services: rejecting anonymous requests consent framework location conveyance session policy –security: end-to-middle security certificates SAML sips clarification –NAT: connection re-use SIP outbound ICE (in MMUSIC) see http://tools.ietf.org/wg/sip’/

98. 98 IETF WG: SIPPING 31 RFCs published in 2006 Policy –media policy –SBC functions Services –service examples –call transfer –configuration framework –spam and spit –text-over-IP –transcoding Testing and operations –IPv6 transition –race condition examples –IPv6 torture tests –SIP offer-answer examples –overload requirements –configuration –voice quality reporting

99. 99 Interoperability Generally no interoperability problems for basic SIP functionality –basic call, digest registration (mostly...), call transfer, voice mail Weaker in advanced scenarios and backward compatibility –handling TCP, TLS –NAT support (symmetric RTP, ICE, STUN,...) –multipart bodies –SIP torture tests –call transfer, call pick-up –video and voice codec interoperability (H.264, anything beyond G.711) SIPit useful, but no equivalent of WiFi certification –most implementations still single-vendor (enterprise, carrier) or vendor- supplied (VSP) –SFTF (test framework) still limited Need profiles to guide implementers SIPREAL BOF at IETF 70?

100. 100 Trouble in Standards Land Proliferation of transition standards: 2.5G, 2.6G, 3.5G, … –true even for emergency calling… Splintering of standardization efforts across SDOs –primary: IEEE, IETF, W3C, OASIS, ISO –architectural: PacketCable, ETSI, 3GPP, 3GPP2, OMA, UMA, ATIS, … –specialized: NENA –operational, marketing: SIP Forum, IPCC, … OASIS IEEE IETF W3C ISO (MPEG) L2.5-L7 protocols data exchange data formats L1-L2 3GPP PacketCable

101. 101 IETF issues SIP WGs: small number (dozen?) of core authors (80/20) –some now becoming managers… –or moving to other topics IETF: research  engineering  maintenance –many groups are essentially maintaining standards written a decade (or two) ago DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP constrained by design choices made long ago –often dealing with transition to hostile & “random” network –network ossification Stale IETF leadership –often from core equipment vendors, not software vendors or carriers fair amount of not-invented-here syndrome late to recognize wide usage of XML and web standards late to deal with NATs security tends to be per-protocol (silo) –some efforts such as SAML and SASL tendency to re-invent the wheel in each group

102. 102 IETF issue: timeliness Most drafts spend lots of time in 90%- complete state –lack of energy (moved on to new -00) –optimizers vs. satisfiers multiple choices that have non- commensurate trade-offs Notorious examples: –SIP request history: Feb. 2002 – May 2005 (RFC 4244) –Session timers: Feb. 1999 – May 2005 (RFC 4028) –Resource priority: Feb. 2001 – Feb 2006 (RFC 4412) New framework/requirements phase adds 1-2 years of delay Three bursts of activity/year, with silence in-between –occasional interim meetings IETF meetings are often not productive –most topics gets 5-10 minutes  lack context, focus on minutiae –no background  same people as on mailing list –5 people discuss, 195 people read email No formal issue tracking –some WGs use tools, haphazardly Gets worse over time: –dependencies increase, sometimes undiscovered –backwards compatibility issues –more background needed to contribute

103. 103 IETF issues: timeliness WG chairs run meetings, but are not managing WG progress –very little control of deadlines e.g., all SIMPLE deadlines are probably a year behind –little push to come to working group last call (WGLC) –limited timeliness accountability of authors and editors –chairs often provide limited editorial feedback IESG review can get stuck in long feedback loop –author – AD – WG chairs –sometimes lack of accountability (AD-authored documents) RFC editor often takes 6+ months to process document –dependencies; IANA; editor queue; author delays –e.g., session timer: Aug. 2004 – May 2005

104. 104 Conclusion Even after 10+ years, VoIP mostly still “cheaper calls” New services and models: –(rich) presence –location-based services –user-programmable services –P2P SIP Scaling to carrier-scale and under duress Current standardization processes slow and complexity- inducing