Vo IP — Year 10 Henning Schulzrinne Dept

Vo. IP - Year 10+ Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs. columbia. edu January 11, 2007 Internet 2 Vo. IP

Overview • Vo. IP status • IETF WG status • Deployment-related issues – security – peering – software – ossification – robustness – configuration – NATs Internet 2 Vo. IP 2

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

SIP is PBX/Centrex ready boss/admin features RFC 3261 simultaneous ringing RFC 3261 hold RFC 3264 basic shared lines dialog/reg. package transfer centrex-style features call waiting/multiple calls RFC 3515/Replaces barge-in Join conference RFC 3261/callee caps “Take” Replaces message waiting message summary package Shared-line “privacy” dialog package call forward RFC 3261 divert to admin RFC 3261 call park RFC 3515/Replaces intercom URI convention call pickup Replaces auto attendant RFC 3261/2833 do not disturb RFC 3261 attendant console dialog package call coverage RFC 3261 night service RFC 3261 attendant features from Rohan Mahy’s VON Fall 2003 talk Internet 2 Vo. IP 4

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

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) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) ISUP (3204) sipfrag (3240) Content types Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) Mostly PSTN Core Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) DHCP (3361) DHCPv 6 (3319) Configuration Security & privacy Internet 2 Vo. IP 6

SIP, SIPPING & SIMPLE – 00 drafts includes draft-ietf-*-00 and draft-personal-*-00 Internet 2 Vo. IP 7

RFC publication Internet 2 Vo. IP 8

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’/ Internet 2 Vo. IP 9

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 • Internet 2 Vo. IP Testing and operations – IPv 6 transition – race condition examples – IPv 6 torture tests – SIP offer-answer examples – overload requirements 10

Vo. IP emergency communications emergency call emergency alert (“inverse 911”) dispatch civic coordination Internet 2 Vo. IP 11

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 (Lo. ST) and identifier (sos URN) – working on overall architecture and UA requirements Internet 2 Vo. IP 12

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

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 Internet 2 Vo. IP 14

ECRIT: Lo. ST 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 Lo. ST servers Indicates errors in civic location data debugging – but provides best-effort resolution Supports overlapping service regions Internet 2 Vo. IP 15

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

Lo. ST Architecture G tree guide G G G T 1: . us G broadcast (gossip) T 2: . de resolver seeker 313 Westview Leonia, NJ US T 2 T 1 (. us) (. de) T 3 (. dk) Leonia, NJ sip: psap@leonianj. gov Internet 2 Vo. IP 17

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 Internet 2 Vo. IP 18

SPEERMINT: Peering Network Context Enterprise Provider A Public Peering Function/Federation Entity Location Function Enterprise Provider B (L 5) Service Provider C (L 5) Public (L 3) Service Provider D (L 5) L 3 Peering Point (out of scope) Enterprise Provider E (L 5) Enterprise Provider F Private (L 3) Service Provider G (L 5) Service Provider H (L 5) Private Peering Function/Federation Entity Location Function Sohel. Internet 2 Vo. IP Khan, Ph. D. , Sprint-Nextel 19

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

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) • • Internet 2 Vo. IP Current efforts: – codec control messages – extended RTCP Qo. S reporting – JPEG 2000 – SMPTE (video) sync – TFRC (congestion control) – unequal error protection (ULP) SRTP key management – SRTP = encrypted & authenticated version of RTP 21

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 • Internet 2 Vo. IP 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 22

IETF WG: P 2 P-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 Internet 2 Vo. IP 23

P 2 PSIP: 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 • • Internet 2 Vo. IP 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) 24

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 Vo. IP – Skype model Using an external DHT (Columbia) – using Open. DHT as generic service • used by multiple applications – can provide mapping or pointer to mapping SIP-managed DHT Open. DHT Internet 2 Vo. IP 25

P 2 P-SIP: Implementation in SIPc • Open. DHT – Trusted nodes – Robust – Fast enough (<1 s) • Identity protection – Certificate-based – SIP id == email • P 2 P for Calls, IM, presence, offline message, STUN server discovery and name search Internet 2 Vo. IP 26

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 Internet 2 Vo. IP 27

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 Internet 2 Vo. IP 28

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 Internet 2 Vo. IP 29

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”) Internet 2 Vo. IP 30

Trouble in Standards Land OASIS W 3 C ISO (MPEG) Internet 2 Vo. IP data formats data exchange IETF L 2. 5 -L 7 protocols IEEE L 1 -L 2 Packet. Cable • Proliferation of transition standards: 2. 5 G, 2. 6 G, 3. 5 G, … – true even for emergency calling… Splintering of standardization efforts across SDOs – primary: • IEEE, IETF, W 3 C, OASIS, ISO – architectural: • Packet. Cable, ETSI, 3 GPP 2, OMA, UMA, ATIS, … – specialized: • NENA – operational, marketing: • SIP Forum, IPCC, … 3 GPP • 31

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, IPv 4, IPv 6, 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 Internet 2 Vo. IP 32

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 Internet 2 Vo. IP 33

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 Internet 2 Vo. IP 34

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