SIP-Summit-2004.ppt

2,289 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,289
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SIP-Summit-2004.ppt

  1. 1. SIP in 2004 – The Challenge of Being a Successful Protocol Henning Schulzrinne Columbia University
  2. 2. Outline <ul><li>Successes: </li></ul><ul><ul><li>hardware </li></ul></ul><ul><ul><li>3GPP </li></ul></ul><ul><ul><li>residential VOIP </li></ul></ul><ul><ul><li>sip.edu </li></ul></ul><ul><ul><li>PTT </li></ul></ul><ul><li>Standardization </li></ul><ul><ul><li>80/20 rule </li></ul></ul><ul><li>Challenges ahead: </li></ul><ul><ul><li>A cross-cultural protocol </li></ul></ul><ul><ul><li>Perception and reality of complexity </li></ul></ul><ul><ul><li>NAT and firewall issues </li></ul></ul><ul><ul><li>Large-scale mixed-vendor deployment </li></ul></ul><ul><ul><li>Inter-domain deployment </li></ul></ul><ul><ul><li>SIP spam </li></ul></ul><ul><li>Opportunities </li></ul><ul><ul><li>Improving the user experience beyond PSTN </li></ul></ul>
  3. 3. (Early) Adulthood <ul><li>“ fully developed and mature” </li></ul><ul><ul><li>Not quite yet, but no longer a teenager </li></ul></ul><ul><ul><li>probably need another 6 years to be grown up… </li></ul></ul><ul><li>Responsibilities: </li></ul><ul><ul><li>Dealing with elderly relatives  POTS </li></ul></ul><ul><ul><li>Financial issues  payments, RADIUS </li></ul></ul><ul><ul><li>Family emergencies  911 </li></ul></ul>
  4. 4. SIP products beyond $600 office phones <ul><li>Finally, basic IP phones below $100 </li></ul><ul><li>802.11 phones </li></ul><ul><li>video conferencing </li></ul><ul><li>speakerphones </li></ul>$65
  5. 5. SIP deployments – landline <ul><li>Consumer broadband: </li></ul><ul><ul><li>Vonage (165,000 lines), Packet8, … buckets of minutes or unlimited long-distance </li></ul></ul><ul><ul><ul><li>SIP invisible, but it just works </li></ul></ul></ul><ul><ul><li>Time-Warner: “Time Warner Cable, the second-largest US cable group, will [in 2004] roll out a national internet-based telephone service.” </li></ul></ul><ul><ul><li>AT&T: “The long-distance giant plans to offer VoIP-enabled services to 1 million consumers in the next two years, beginning with a roll-out in major cities across the U.S. in the first quarter of 2004.” </li></ul></ul><ul><ul><li>Verizon </li></ul></ul><ul><li>MCI Advantage (for business) </li></ul><ul><li>Focused on hosted SIP services, rather than just SIP termination </li></ul><ul><li>Few midsize-to-large companies still considering traditional circuit-switched PBX for replacement </li></ul>
  6. 6. SIP deployments – wireless <ul><li>Usage for controlling new push-to-talk services </li></ul><ul><ul><li>not user-visible, but may emerge from hiding </li></ul></ul><ul><ul><li>first step to presence-enabled voice services </li></ul></ul><ul><li>Sprint PCS Readylink service </li></ul><ul><ul><li>“ first commercial deployment of SIP by a wireless carrier” </li></ul></ul><ul><li>3G (R5) services much slower in coming </li></ul>
  7. 7. Deployment example: SIP.edu <ul><li>Deploy SIP and VoIP across Internet2 educational institutions </li></ul><ul><li>Transition E.164  SIP URIs </li></ul><ul><li>But don’t wait for VoIP end system deployment </li></ul>“ +1-617-637-8562, come here. I need you!” (from slides by Ben Teitelbaum) A. G. Bell did not say:
  8. 8. SIP.edu Architecture (Phase 1) SIP Proxy SIP-PBX Gateway PBX INVITE (sip:bob@bigu.edu) INVITE (sip:12345@gw.bigu.edu) DNS SRV query sip.udp.bigu.edu telephoneNumber where mail=”bob” PRI / CAS bigu.edu SIP User Agent Bob's Phone © Ben Teitelbaum, with permission DNS Campus Directory
  9. 9. SIP.edu Architecture (Phase 2) INVITE (sip:bob@bigu.edu) DNS SRV query sip.udp.bigu.edu bigu.edu SIP User Agent If Bob has registered, ring his SIP phone; Else, call his extension through the PBX. REGISTER (Contact: 207.75.164.131) INVITE (sip:bob@207.75.164.131) Bob's SIP Phone © Ben Teitelbaum, with permission DNS location DB SIP Proxy SIP Registrar
  10. 10. SIP.edu growth http://voip.internet2.edu/SIP.edu/ e.g., sip:hgs10@columbia.edu  +1 212 939 7042
  11. 11. Overview <ul><li>SIP in 2003 </li></ul><ul><ul><li>Standardization – a long, hard slog </li></ul></ul><ul><ul><li>Filling in the product palette </li></ul></ul><ul><ul><ul><li>finally, cheap phones </li></ul></ul></ul><ul><ul><li>VoIP (and SIP) over WiFi (802.11) </li></ul></ul><ul><ul><li>Real deployments </li></ul></ul><ul><ul><ul><li>commercial (wireless, consumer, enterprise) </li></ul></ul></ul><ul><ul><ul><li>Embedded (push-to-talk) </li></ul></ul></ul><ul><ul><ul><li>Internet2 </li></ul></ul></ul><ul><ul><li>SIP as a brand: SIPphone, SIPura, SIPtele, SIPquest, SIPCPE, … </li></ul></ul><ul><li>SIP in 2004 </li></ul><ul><ul><li>Large-scale consumer usage </li></ul></ul><ul><ul><li>How much regulation for VoIP? </li></ul></ul><ul><ul><li>Emergency calling </li></ul></ul><ul><ul><li>Standardized IM & presence </li></ul></ul><ul><ul><li>Better auto-configuration </li></ul></ul>
  12. 12. Major RFCs published recently <ul><li>Third-party call control (RFC 3275) </li></ul><ul><ul><li>allows non-media entity to control sessions </li></ul></ul><ul><li>Event package for registrations (RFC 3680) </li></ul><ul><li>Security mechanism agreement (RFC 3329) </li></ul><ul><ul><li>negotiate algorithms with next hop </li></ul></ul><ul><li>Requirements for resource priority (RFC 3487) </li></ul><ul><ul><li>prioritization of calls in military networks and emergencies </li></ul></ul><ul><li>REFER method (RFC 3515) </li></ul><ul><ul><li>call transfer </li></ul></ul><ul><li>DHCPv6 for SIP (RFC 3319) </li></ul><ul><ul><li>automatic outbound proxy configuration </li></ul></ul><ul><li>Proxy-to-proxy extensions for PacketCable (RFC 3603) </li></ul><ul><li>Symmetric response routing (RFC 3581) </li></ul><ul><ul><li>improved NAT interaction </li></ul></ul>
  13. 13. Major RFCs published <ul><li>Service route discovery (RFC 3806) </li></ul><ul><ul><li>REGISTER returns “preloaded route” to be used by UA for services </li></ul></ul><ul><li>SIP and SDP compression (RFC 3485/3486) </li></ul><ul><ul><li>compress SIP headers and body via dynamic dictionary </li></ul></ul><ul><li>Call flows (RFC 3665/3666) </li></ul><ul><ul><li>explain behavior by example </li></ul></ul><ul><ul><li>useful for testing common cases </li></ul></ul><ul><ul><li>not a spec replacement </li></ul></ul><ul><li>Summary: except for REFER, mostly relevant to subsets of SIP developer community </li></ul><ul><ul><li>PacketCable </li></ul></ul><ul><ul><li>3G </li></ul></ul><ul><ul><li>Military, emergency response </li></ul></ul>
  14. 14. RFCs in the pipeline <ul><li>Ready & done, but typically waiting for normative references </li></ul><ul><li>Examples: </li></ul><ul><ul><li>message waiting indication </li></ul></ul><ul><ul><li>caller preferences </li></ul></ul><ul><ul><li>CPL </li></ul></ul><ul><ul><li>user agent capabilities </li></ul></ul><ul><ul><li>ENUM for SIP </li></ul></ul><ul><ul><li>H.323 interworking requirements </li></ul></ul><ul><ul><li>presence – events, CPIM, watcher info, … </li></ul></ul>
  15. 15. When are we going to get there? <ul><li>In 2003, 6 SIP + 2 SIPPING RFCs published </li></ul><ul><li>In 2002, 14 SIP + 4 SIPPING RFCs </li></ul><ul><li>Currently, 20 SIP + 24 SIPPING + 22 SIMPLE WG Internet Drafts </li></ul><ul><ul><li>does not count individual drafts likely to be “promoted” to WG status </li></ul></ul><ul><li>The .com consultant linear extrapolation technique ® </li></ul><ul><ul><li>pessimist  8.5 more years if no new work is added to the queue </li></ul></ul><ul><ul><li>optimist  4 more years </li></ul></ul>
  16. 16. SIP is PBX/Centrex ready from Rohan Mahy’s VON Fall 2003 talk centrex-style features boss/admin features attendant features RFC 3261 call coverage RFC 3261 do not disturb Replaces call pickup RFC 3515/Replaces call park RFC 3261 call forward message summary package message waiting RFC 3261/callee caps conference RFC 3515/Replaces transfer RFC 3264 hold RFC 3261 call waiting/multiple calls URI convention intercom RFC 3261 night service dialog package attendant console RFC 3261/2833 auto attendant RFC 3261 divert to admin dialog package Shared-line “privacy” Replaces “ Take” Join barge-in dialog/reg. package basic shared lines RFC 3261 simultaneous ringing
  17. 17. SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00
  18. 18. SIPit 14 (Feb. 2004) <ul><li>128 attendees from 55 organizations </li></ul><ul><ul><li>US, Canada, Israel, Japan, Taiwan, France, Germany, Belgium, UK, Turkey, India, Sweden, Finland, Norway </li></ul></ul><ul><li>“ The biggest strides between this event and the last were around correct support for TLS. The biggest weakness continues to be proper construction of offers and answers.” </li></ul>
  19. 19. SIP proprietary extensions <ul><li>Good interoperability in basic call setup </li></ul><ul><li>Indications where work is needed </li></ul><ul><ul><li>or “I didn’t know this existed” </li></ul></ul><ul><ul><li>some “wrong protocol, buddy” </li></ul></ul><ul><ul><li>currently, 68 SIP/SIPPING/SIMPLE I-Ds </li></ul></ul><ul><ul><li>22 SIP RFCs </li></ul></ul><ul><li>Based on informal email survey </li></ul><ul><li>Shared line support to emulate key systems: </li></ul><ul><ul><li>not dialogs, but state of AORs </li></ul></ul><ul><ul><li>see SIMPLE </li></ul></ul><ul><li>TCAP over SIP </li></ul><ul><ul><li>for LNP </li></ul></ul><ul><ul><li>general: pick up information along the way </li></ul></ul><ul><li>Auto-answer support (intercom) </li></ul><ul><li>Caller-indicated ringing preferences </li></ul><ul><li>Caller name identification added by proxies </li></ul><ul><li>Caller time zone </li></ul><ul><li>NAT support </li></ul><ul><ul><li>STUN servers not widely available – no incentive </li></ul></ul><ul><ul><ul><li>some use simple HTTP query (just needs cgi-bin) </li></ul></ul></ul><ul><ul><li>probably biggest advantage that Skype has </li></ul></ul><ul><li> make SIP work well in old world on phone look-alikes </li></ul>
  20. 20. Competition <ul><li>Old competition: H.323  no longer active development </li></ul><ul><ul><li>but still in wide use (including CallManager) </li></ul></ul><ul><li>New competition: </li></ul><ul><ul><li>IAX </li></ul></ul><ul><ul><li>Skype </li></ul></ul><ul><ul><li>Cisco SCCP (Skinny) ~ MGCP </li></ul></ul><ul><ul><li>Jabber (IM) </li></ul></ul><ul><li>Usually, dominated by single company </li></ul><ul><ul><li>faster (fewer “what is a tuple discussions”…) </li></ul></ul><ul><ul><li>concentrated company resources  usually make-or-break for company </li></ul></ul><ul><ul><li>H.323 = Microsoft NetMeeting compatible </li></ul></ul><ul><li>tend to favor efficiency over generality and protocol niceties (internationalization, congestion control, XML, …) </li></ul><ul><li>had NAT story from very beginning </li></ul><ul><ul><li>Skype NAT solution appears to be technically similar to STUN </li></ul></ul><ul><li>Limited focus, e.g.,: </li></ul><ul><ul><li>silo model </li></ul></ul><ul><ul><ul><li>audio only (IAX) </li></ul></ul></ul><ul><ul><ul><li>for Jabber, classical IM/presence focused </li></ul></ul></ul><ul><ul><li>no capability negotiation </li></ul></ul><ul><ul><li>no proxy support </li></ul></ul><ul><ul><li>limited security support </li></ul></ul><ul><ul><li>limited services </li></ul></ul><ul><ul><ul><li>call forwarding, transfer, early media, … </li></ul></ul></ul><ul><li>Unpublished protocols </li></ul><ul><ul><li>“ trust us, we wouldn’t do anything stupid, would we?” </li></ul></ul><ul><ul><li>hard to get protocol eco system </li></ul></ul><ul><ul><ul><li>variety of end systems </li></ul></ul></ul><ul><ul><ul><li>diagnostics and protocol analyzers </li></ul></ul></ul>
  21. 21. SIP – a bi-cultural protocol <ul><li>overlap dialing </li></ul><ul><li>DTMF carriage </li></ul><ul><li>key systems </li></ul><ul><li>notion of lines </li></ul><ul><li>per-minute billing </li></ul><ul><li>early media </li></ul><ul><li>ISUP & BICC interoperation </li></ul><ul><li>trusted service providers </li></ul><ul><li>multimedia </li></ul><ul><li>IM and presence </li></ul><ul><li>location-based service </li></ul><ul><li>user-created services </li></ul><ul><li>decentralized operation </li></ul><ul><li>everyone equally suspect </li></ul>
  22. 22. The SIP complexity fallacy <ul><li>IAX (for example) is simpler than SIP </li></ul><ul><li>but you could build the IAX functionality in SIP at just about the same complexity: </li></ul><ul><ul><li>no proxies </li></ul></ul><ul><ul><li>no codec negotiation </li></ul></ul><ul><ul><li>no distributed services </li></ul></ul><ul><li>Difficulty: extracting those simple pieces from 269 pages of specification  </li></ul><ul><li>SIP still more complex due to signaling-data separation </li></ul>Signaling & Media Signaling & Media Signaling Signaling Media IAX model SIP, H.323, MCGP model
  23. 23. Operational complexity <ul><li>SIP design  user only need to know their SIP address (AOR) and a registration secret </li></ul><ul><ul><li>familiar to users from web login </li></ul></ul><ul><li>Not: </li></ul><ul><ul><li>outbound proxy </li></ul></ul><ul><ul><li>STUN server </li></ul></ul><ul><ul><li>registrar address </li></ul></ul><ul><ul><li>backup server addresses </li></ul></ul><ul><ul><li>Digest authentication user name </li></ul></ul><ul><ul><li>media port range </li></ul></ul><ul><ul><li>tftp and HTTP server for image updates </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Configuration failures hard to diagnose </li></ul><ul><li>Bad “out of the box” experience </li></ul><ul><li>Made worse by limited UI of end systems </li></ul><ul><li>Misleading or inconsistent terminology </li></ul><ul><ul><li>“ communication server” </li></ul></ul><ul><ul><li>“ user name” </li></ul></ul><ul><li>Can’t have a manually configured configuration server </li></ul>
  24. 24. VoIP end system configuration AOR MAC address registrar address STUN/TURN – local and global general configuration document (media, UI, protocol behavior, …) geographical location (for 911) outbound proxy DNS SIP SUBSCRIBE/NOTIFY DHCP that’s all it should take
  25. 25. NAT and VPN troubles <ul><li>Unplanned transition from Internet = one global address space to clouds (“realms”) of unknown scope </li></ul><ul><ul><li>Can’t know without help whether directly reachable </li></ul></ul><ul><ul><li>Any number of concentric spaces </li></ul></ul><ul><li>There is no universally workable NAT solution </li></ul><ul><ul><li>always problems with inbound calls </li></ul></ul><ul><ul><li>may need to maintain and refresh permanent connections to globally routable entity </li></ul></ul><ul><ul><li>may need relay agent for media (TURN) </li></ul></ul>? ? ? home NAT ISP NAT Internet
  26. 26. NAT solutions well-defined NAT behavior  allow informed deployment decisions avoid “evil” NATs NAT boxes with built-in address discovery and allocation find STUN and TURN servers easily IPv6
  27. 27. SIP spam <ul><li>Threats: </li></ul><ul><ul><li>unsolicited (multimedia) calls </li></ul></ul><ul><ul><li>presence authorization requests </li></ul></ul><ul><ul><li>IMs (“spim”) </li></ul></ul><ul><li>Could be worse than email and phone telemarketing: </li></ul><ul><ul><li>immediate interruption </li></ul></ul><ul><ul><li>“ the death of distance”  aluminum siding at 2 am, direct from China </li></ul></ul><ul><ul><li>do-not-call list and CAN-SPAM may not apply </li></ul></ul><ul><li>Not a SIP problem – Applies to other systems as well </li></ul><ul><li>Spam mechanisms have limited applicability </li></ul><ul><ul><li>can’t do content analysis (Bayesian filtering) </li></ul></ul><ul><ul><ul><li>even for IM  attention grabbed after first “Hello” message </li></ul></ul></ul><ul><ul><li>human reachability measures </li></ul></ul><ul><ul><ul><li>interfere with real-time nature </li></ul></ul></ul>
  28. 28. SIP spam solutions – some options <ul><li>Failure of content-based  identity-based </li></ul><ul><li>global, personal PKI  tried and failed </li></ul><ul><ul><li>economics, liability </li></ul></ul><ul><ul><li>to scale, must be cheap and easy to get  cheap and easy for spammers, too </li></ul></ul><ul><ul><li>hard to install on end systems </li></ul></ul><ul><li>But domain-level authentication works </li></ul><ul><ul><li>TLS certificates </li></ul></ul><ul><ul><li>orders of magnitude fewer servers than phones </li></ul></ul><ul><li>Other server ID alternatives: </li></ul><ul><ul><li>DNS  certificate server </li></ul></ul><ul><ul><li>SPF  SRV records for domain servers </li></ul></ul><ul><li>Increase value of identity: </li></ul><ul><ul><li>social networks </li></ul></ul><ul><ul><li>bonding and warranties </li></ul></ul><ul><ul><li>identity policy (“we card”) </li></ul></ul><ul><ul><li>verifiable location information </li></ul></ul><ul><ul><ul><li>stranded relative from payphone vs. </li></ul></ul></ul><ul><ul><ul><li>former rebel leader from Namibia </li></ul></ul></ul>outbound proxy example.com From: alice@example.com shared secret (Digest) verify example.com
  29. 29. Conclusion <ul><li>SIP making the transition from lab to field </li></ul><ul><ul><li>push-to-talk </li></ul></ul><ul><ul><li>residential VoIP </li></ul></ul><ul><ul><li>some enterprise deployments </li></ul></ul><ul><li>Bi-cultural  complexity, delay </li></ul><ul><li>Challenges operational, less protocol </li></ul><ul><ul><li>configuration </li></ul></ul><ul><ul><li>911 </li></ul></ul><ul><ul><li>spam </li></ul></ul>

×