1. Internet2 VoIP January 11, 2007 VoIP - Year 10+ Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

2. Internet2 VoIP 2 Overview VoIP status IETF WG status Deployment-related issues –security –peering –software –ossification –robustness –configuration –NATs

3. Internet2 VoIP 3 Evolution of VoIP “amazing – the phone rings” “does it do call transfer?” “how can I make it stop ringing?” 1996-2000 2000-20032004- catching up with the digital PBX long-distance calling, ca. 1930 going beyond the black phone

4. Internet2 VoIP 4 SIP is PBX/Centrex ready call waiting/multiple callsRFC 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

5. Internet2 VoIP 5 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

6. Internet2 VoIP 6 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

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

8. Internet2 VoIP 8 RFC publication

9. Internet2 VoIP 9 IETF WG: SIP ~ 44 SIP-related RFCs published 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 see http://tools.ietf.org/wg/sip’/

10. Internet2 VoIP 10 IETF WG: SIPPING 31 RFCs published 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

11. Internet2 VoIP 11 VoIP emergency communications emergency call dispatch civic coordination emergency alert (“inverse 911”)

12. Internet2 VoIP 12 IETF ECRIT working group Emergency Contact Resolution with Internet Technologies Solve four major pieces of the puzzle: –location conveyance (with SIP & GEOPRIV) –emergency call identification –mapping geo and civic caller locations to PSAP URI –discovery of local and visited emergency dial string Not solving –location discovery --> GEOPRIV –inter-PSAP communication and coordination –citizen notification Current status: –finishing general and security requirements –agreement on mapping protocol (LoST) and identifier (sos URN) –working on overall architecture and UA requirements

13. Internet2 VoIP 13 ECRIT: Options for location delivery GPS L2: LLDP-MED (standardized version of CDP + location data) –periodic per-port broadcast of configuration information –currently implementing CDP L3: DHCP for –geospatial (RFC 3825) –civic (RFC 4676) L7: proposals for retrievals: HELD, RELO, LCP, SIP, … –for own IP address –by IP address –by MAC address –by identifier (conveyed by DHCP or PPP)

14. Internet2 VoIP 14 ECRIT: Finding the correct PSAP Which PSAP should the e-call go to? –Usually to the PSAP that serves the geographic area –Sometimes to a backup PSAP –If no location, then ‘default’ PSAP

15. Internet2 VoIP 15 ECRIT: LoST Functionality Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping protocols Civic as well as geospatial queries –civic address validation Recursive and iterative resolution Fully distributed and hierarchical deployment –can be split by any geographic or civic boundary –same civic region can span multiple LoST servers Indicates errors in civic location data  debugging –but provides best-effort resolution Supports overlapping service regions

16. Internet2 VoIP 16 LoST: Location-to-URL Mapping cluster serves VSP 2 NY US NJ US Bergen County NJ US 123 Broad Ave Leonia Bergen County NJ US cluster serving VSP 1 replicate root information search referral root nodes Leonia NJ US sip:psap@leonianj.gov VSP 1 LoST

17. Internet2 VoIP 17 LoST Architecture T1 (.us) T2 (.de) T3 (.dk) G G G G G broadcast (gossip) T1:.us T2:.de resolver seeker 313 Westview Leonia, NJ US Leonia, NJ  sip:psap@leonianj.gov tree guide

18. Internet2 VoIP 18 SPEERMINT: Session interconnect E.164 number SIP URI host name IP address MAC address peer discovery ENUM lookup of NAPTR in DNS aka call routing data (CRD)  derived from ENUM record service location (lookup of NAPTR and SRV) in DNS lookup of A and AAAA in DNS addressing and session establishment routing protocols, ARP, …

19. Internet2 VoIP 19 SPEERMINT: Peering Network Context Public (L3) Private (L3) L3 Peering Point (out of scope) Enterprise Provider A (L5) Enterprise Provider B (L5) Service Provider C (L5) Service Provider D (L5) Enterprise Provider E (L5) Service Provider G (L5) Enterprise Provider F (L5) Service Provider H (L5) Public Peering Function/Federation Entity Location Function Sohel Khan, Ph.D., Sprint-Nextel Private Peering Function/Federation Entity Location Function

20. Internet2 VoIP 20 SPEERMINT: Reference peering architecture Enables media paths interconnection between endpoints MF SF Enables discovery of SF or exchanges policy/parameters to be used by SF OF Enables discovery of the SF or OF LF PurposeRef. Security QF Negotiates and reserves bandwidth resources, as well as polices/provides measurements for media paths SIP Service Provider Y SIP Service Provider X OF SF MF QF AF Security Sohel Khan, Ph.D., Sprint-Nextel LF Enables discovery of endpoints, assists in discovery and exchange of parameters to be used with the MF AF Application Function: TBD or deleted

21. Internet2 VoIP 21 IETF WG: AVT Audio and video transport –media transport: RTP & SRTP –encapsulating media within RTP “RTP payload formats” One of the longest-running working groups in the IETF –59 RFCs (not counting those replaced) Current efforts: –codec control messages –extended RTCP QoS reporting –JPEG 2000 –SMPTE (video) sync –TFRC (congestion control) –unequal error protection (ULP) SRTP key management –SRTP = encrypted & authenticated version of RTP

22. Internet2 VoIP 22 IETF WG: MMUSIC Original home of SIP Now mainly deals with SDP Efforts to replace SDP with SDPng apparently failed –SDPng: XML-based, more structure Offer-answer model Discussions on better discovery of end point capabilities NAT traversal story: –alternative network addresses in SDP –permanent outbound TCP connections from UA to proxy –discover end point addresses IP addresses are no longer globally unique - -> multiple addresses depending on context STUN –configure media relay STUN with TURN functionality

23. Internet2 VoIP 23 IETF WG: P2P-SIP Several BOF sessions, now likely to become IETF working group Provide peer-to-peer model for SIP-based interactive communications –based on distributed hash table (DHT) as replacement for DNS and possibly SIP registrar –(1) protocol for constructing DHT hopefully, independent of DHT algorithm –(2) protocol for accessing DHT nodes get/put/delete key-value pairs

24. Internet2 VoIP 24 P2PSIP: Applications & Motivation Small stand-alone networks –2-50 –SOHO, events, emergency coordination –may not have access to Internet infrastructure Corporate size networks –50-1000 –single administrator Global-scale networks –1000-100 million –consumer applications –serious trust issues Motivation –no need to pay for servers users are kind enough to pay! –SIP proxy less of issue 1 server/100,000 users? –but also: media relay for NAT traversal media bridge for conferencing Issues –trust - members may abuse system or actively subvert it –reliability –monitoring and control (SOX, HIPAA)

25. Internet2 VoIP 25 SIP-managed DHT OpenDHT Three basic approaches Full distribution and search –similar to Bonjour –scales to small, local networks DHT built using SIP –see Kundan/Schulzrinne and Cao/Bryan/Lowekamp –dedicated to VoIP –Skype model Using an external DHT (Columbia) –using OpenDHT as generic service used by multiple applications –can provide mapping or pointer to mapping

26. Internet2 VoIP 26 P2P-SIP: Implementation in SIPc OpenDHT –Trusted nodes –Robust –Fast enough (<1s) Identity protection –Certificate-based –SIP id == email P2P for Calls, IM, presence, offline message, STUN server discovery and name search

27. Internet2 VoIP 27 Open issues: NATs NATs fundamentally change the nature of the Internet –no longer a single, global address space –cannot deploy new transport protocols (e.g., SCTP, DCCP) –more like old UUNET model (decvax!wustl!columbia) except that there’s no path, just mappings another analogy: ATM and MPLS label rewriting NAT behavior unspecified and implicit –what part of incoming packet is used for mapping just destination address & port or protocol and source address? –how long is the binding maintained? some hotel NATs time out active TCP connections after a few seconds can’t easily discover timeout --> need high-frequency refresh --> possibly high REGISTER load –other random “optimizations” BEHAVE WG to define NAT behavioral guidelines

28. Internet2 VoIP 28 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

29. Internet2 VoIP 29 Open issues: Configuration Ideally, should only need a user name and some credential –password, USB key, host identity (MAC address), … More than DHCP: device needs to get –SIP-level information (outbound proxy, timers) –policy information (“sorry, no video”) Multiple sources of configuration information –local network (hotel proxy) –voice service provider (off-network) Configuration information may change Needs to allow no-touch deployment of thousands of devices SIP configuration framework –has been languishing for years –currently being rewritten to reduce complexity

30. Internet2 VoIP 30 Open issues: summary Basic interoperability is generally good –call setup/teardown –transfer Advanced features less so –e.g., bridged call appearance Configuration too painful –“out of the box experience” Unreliable (98 to 99.5% instead of 99.999%): –BGP disruptions –NAT problems –local interference –hard to tell what went wrong --> can’t prevent repeated problems (“dentist problems”)

31. Internet2 VoIP 31 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

32. Internet2 VoIP 32 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

33. Internet2 VoIP 33 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

34. Internet2 VoIP 34 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

35. Internet2 VoIP 35 Conclusion Core standards for media and signaling are finished –can build PBX-equivalent devices and services on a large scale see BT, FiOS, Vonage Lots of decent server implementations (various vendors; SER, openSER, Asterisk) –but lack of good soft clients for major OS platforms Ossification of Internet requires application complexity –kludge around NATs, lack of QoS –lack of credential infrastructure Intersection with policy and business models –NGN, 3G: maintain voice as high-value monopoly service Not a protocol engineering effort, systems engineering