1 / 35

VoIP - Year 10+

VoIP - Year 10+. Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu. Overview. VoIP status IETF WG status Deployment-related issues security peering software ossification robustness configuration NATs. Evolution of VoIP. “how can I make it

aldon
Download Presentation

VoIP - Year 10+

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. SIP is PBX/Centrex ready boss/admin features centrex-style features attendant features from Rohan Mahy’s VON Fall 2003 talk Internet2 VoIP

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

  6. A constellation of SIP RFCs Non-adjacent (3327) Symmetric resp. (3581) Service route (3608) User agent caps (3840) Caller prefs (3841) Request routing Resource mgt. (3312) Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) ISUP (3204) sipfrag (3240) Mostly PSTN Content types Core Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) DHCP (3361) DHCPv6 (3319) Configuration Security & privacy Internet2 VoIP

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

  8. RFC publication 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’/ 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 Internet2 VoIP

  11. VoIP emergency communications emergency call emergency alert (“inverse 911”) dispatch civic coordination 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 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) 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 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 Internet2 VoIP

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

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

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

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

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

  25. 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 SIP-managed DHT OpenDHT 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 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 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 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 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”) 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 data formats W3C ISO (MPEG) data exchange IETF L2.5-L7 protocols IEEE L1-L2 PacketCable 3GPP 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 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 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 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 Internet2 VoIP

More Related