VoIP - beyond replicating the limitations of the past

1. VoIP - beyond replicating the limitations of the past Henning Schulzrinne Dept. of Computer Science, Columbia University, New York (based on work in collaboration with IRT students including Salman Baset, Jae Lee, Kundan Singh, Xiaotao Wu, Jonathan Lennox, Vishal Singh & staff, as well as the IETF SIP, GEOPRIV and SIMPLE WGs) hgs@cs.columbia.edu Oracle October 30, 2007

2. Outline • VoIP maturing: vision vs. reality • Advanced VoIP services • user-programmable services • presence and location-based services • peer-to-peer systems • VoIP challenges • scaling • spam/SPIT • emergency calling • complexity & interoperability

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

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. Evolution of VoIP “Can it really replace the phone system?” “How can I make it stop ringing?” long-distance calling, ca. 1930 “does it do call transfer?” replacing the global phone system going beyond the black phone “amazing – the phone rings” catching up with the digital PBX 1996-2000 2000-2003 2004-2005 2006-

6. 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) SIPPING (usage, requirements) SIP (protocol) uses provides IPTEL (tel URL) BLISS (common services) SPEECHSC (speech services) usually used with P2PSIP (peer-to-pper) AVT (RTP, SRTP, media) SIGTRAN (signaling transport) MMUSIC (SDP, RTSP, ICE) IETF RAI area

7. Old vs. new

8. SIP Overview

9. Internet services – the missing entry

10. Filling in the protocol gap

11. 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 SIP as service enabler

12. 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 • Verizon FiOS, Vonage, Yahoo, ...

13. 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

14. Basic SIP message flow

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

16. response request request line INVITE sip:bob@there.com SIP/2.0 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 header fields 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 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 messagebody SIP message format SDP

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

18. 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

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

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

21. SIP – a bi-cultural protocol • multimedia • IM and presence • location-based service • user-created services • decentralized operation • everyone equally suspect • overlap dialing • DTMF carriage • key systems • notion of lines • per-minute billing • early media • ISUP & BICC interoperation • trusted service providers

22. Service Creation

23. Overview • Communication services and where to run the services • Call Processing Language (CPL) • End system services • Programmable – Service creation • Analyzable – Feature interaction handling • Intelligent – Feature learning • Ubiquitous – Context-based services • Implementations

24. Internet Where to run services?

25. Service creation • Tailor a shared infrastructure to individual users • traditionally, only vendors (and sometimes carriers) • learn from web models

26. Call Processing Language (CPL) • XML-based “language” for processing requests • intentionally restricted to branching and subroutines • no variables (may change), no loops • thus, easily represented graphically • and most bugs can be detected statically • termination assured • mostly used for SIP, but protocol-independent • integrates notion of calendaring (time ranges) • structured tree describing actions performed on call setup event • top-level events: incoming and outgoing

27. CPL • Location set stored as implicit global variable • operations can add, filter and delete entries • Switches: • address • language • time, using CALSCH notation (e.g., exported from Outlook) • priority • Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...) • Reject and redirect perform corresponding protocol actions • Supports abstract logging and email operation

28. CPL example

29. <?xml version="1.0" ?> <!DOCTYPE call SYSTEM "cpl.dtd"> <cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming> </cpl> CPL example

30. Service creation environment for CPL and LESS

31. Run services on end systems IPTS ‘00

32. End system service programming • What do we need? • A language and a tool • End system service creation language • Easy to understand • Automatic service creation • Portable • Create once, run on different devices • Easy to manage • Facilitate feature interaction handling • CPL, CCXML, APPEL, SPL…

33. Vibrate my device If the call is from my boss YES YES If I am in a conference For an incoming call NO Reject the call How to represent services? • ECA (event – condition – action) Natural thinking of a decision making – a policy/rule set Using decision trees to represent policy/rule sets (O(logN) execution time) When I am in a conference, I will vibrate my device for my boss’s calls and reject all the other calls.

34. Use LESS effort to create more services • LESS: Language for End System Services • CPL: Call Processing Language (Jonathan, Henning, and myself) • Simplicity • Four kinds of elements: trigger, switch, action, modifier • Tree-like structure, easy for feature interaction analysis • Safety • Type safety: XML-based, no user defined variables • Control flow safety: tree-like structure without back-reference • No direct memory access • Default behavior for every tree branch • Portability • Handle user interactions and media operations • Extensibility • not just new elements, but can apply existing algorithms IEEE ICC’03 RFC3880

35. check the caller switch = ≠ check priority check time switch switch to Bob = ≠ ≠ modifier action action action redirect accept reject LESS elements trigger an incoming call

36. CUTE (Columbia University Telecommunication service Editor)

37. Survey on end user service creation Group1: IRT members, Group2: CS undergraduates, Group3: Other people 85% would like to create their own services, 90% like to use CUTE to create services 90% can correctly create service-1, 65% srv-2, 80% srv-3, 65% easy to understand LESS code

38. What is FI and how to handle it? • Tree merging Incoming call Incoming call Incoming call If time is between 10:00AM and 11:00AM If address is hgs If address is hgs If time is between 10:00AM and 11:00AM = + ring accept ring reject Forward to conf Forward to conf reject Take actions from both scripts. Simply setting precedence rules cannot work.

39. FI handling for LESS • Action conflict tables • Services conflict only if their actions conflict • Tree merging algorithm • Detect and help to resolve • Resolve conflicts ICFI’05 (FIW) JCN

40. Pre-condition and expected results

41. Action conflict table -: no interaction, A: attribute conflict, C: action conflict, E: enabling, R: resource competition

42. Resolving interactions condition decision options with lower risks

43. No idea about services? • Learning burden caused by new services • What and how • Help, not bypass • Causal relationship between call information and call decisions • SIP headers • Different information sources • Examples • Spam filtering, calendar-based services

44. 30*3+10*2+7=117 30*2+3*2+10*3+4*3=108 What (learn from), what (generate), how • Users’ communication history – LESS decision trees – decision tree induction • find switches that can best partition actions • Algorithm • Incremental • Prune • Quality measurement

45. Incremental Tree Induction • Incremental • Incorporating • Transposition • Virtual prune • Direct metrics • Expected number of tests • Leaf counts • Minimum description length • Expected misclassification cost

46. 40 services Each for 300 calls 80% match 10% different way 10% mismatch Simulation

47. Performance IBM ThinkPad, Linux 1GHz PIII Mobile 256MB memory Fast vs. incremental (20 samples) training

48. How to handle service risks? • Identify • Lose connection: reject, redirect, transfer, accept on wrong branch • Lose privacy: accept, call, notify • Lose money: accept, transfer to higher rate endpoint • Lose attention: alert, accept, appliance control • Analyze • Possibility: number of occurrence in the decision tree • Impact: (connection, privacy) > money > attention, customizable • Resolve • Change communication methods • Change communication targets • Reduce overall risk: avoiding high impact risks, though may cause low impact risks • Contingency plan • Backup

49. Presence and event notification

50. Event notification as service enabler • 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