1 / 19

SIP – growing up

SIP – growing up. Henning Schulzrinne Columbia University SIP 2003 – January 2003 Paris, France. Overview. What happened in 2002? standards milestones deployment Outlook for 2003 substantial completion? SIP challenges. What happened in 2002?. New revision of SIP RFCs published

mrinal
Download Presentation

SIP – growing up

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. SIP – growing up Henning Schulzrinne Columbia University SIP 2003 – January 2003 Paris, France

  2. Overview • What happened in 2002? • standards milestones • deployment • Outlook for 2003 • substantial completion? • SIP challenges

  3. What happened in 2002? • New revision of SIP RFCs published • RFC 3261: basic protocol specification • RFC 3262: Reliability of Provisional Responses • RFC 3263: Locating SIP Servers • RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP) • RFC 3265: SIP-specific Event Notification

  4. RFC 3261 • Backward compatible with RFC 2543 – no new version • Major changes: • specification behavior-oriented, not header-oriented • e.g., separation into ‘layers’ • mandate support for UDP and TCP • formal offer/answer model for media negotiation • uses both SRV and NAPTR for server location, load balancing and redundancy • much more complete security considerations • “sips:’’ for secured (TLS) path • PGP removed due to lack of use • Basic authentication removed as unsafe • S/MIME added for protecting message bodies (and headers, via encapsulation) • Route/Record-Route simplified

  5. SIP and 3G wireless networks • In July, 3GPP adopts SIP as signaling protocol for Release5 • increased collaboration between organizations • still somewhat different perspectives:

  6. SIP adoption in 2002 • IBM, Novell support SIMPLE for group communications in the enterprise • but still confusion by Microsoft: MSN Messenger 5.0 (no SIP) vs. Windows Messenger 4.7 (SIP + MSN, but mostly for XP) • AOL backing off from interoperability • IETF adds Jabber to the IM standards confusion • PRIM and APEX fading • 3GPP adopts SIMPLE as IM/presence mechanism for Release6 • commercial services for consumers and businesses • Vonage, Denwa, eStara, … • MCI Worldcom, DeltaThree

  7. Still no cheap (< $100) phones, but getting closer snom 100 ($270), Cisco 7905 ($165), Teledex (but not all SIP yet…) but still not Wal-Mart  video-conferencing equipment still lacking turn-key “IP PBX-in-a-box” available from multiple vendors many good software clients PDA clients emerging despite industry “issues”, robust set of participants at SIP products

  8. SIP standardization in 2002 • Probably point of maximum activity for SIP work • There have been at least (in my collection of 6428 distinct IETF I-Ds)… • 210 distinct I-Ds with –sip– (not counting -00, -01, etc.) • 83 with –sipping– • 34 with –simple– • Current status somewhat difficult to track • not all WG I-Ds are draft-ietf-* • many drafts start as draft-somebody-* • IETF draft tracking is iffy (complete only after WG done) • JAIN activities in 2002: • SIP servlet API • JAIN SIP lite

  9. Other SIP RFCs published in 2002 • DHCP options for SIP servers • The Session Initiation Protocol (SIP) UPDATE Method • Integration of Resource Management and Session Initiation Protocol (SIP) • Internet Media Type message/sipfrag • A Privacy Mechanism for the Session Initiation Protocol (SIP) • Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks • Session Initiation Protocol (SIP) Extension for Instant Messaging • The Reason Header Field for the Session Initiation Protocol (SIP) • Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts • User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals • Session Initiation Protocol for Telephones (SIP-T): Context and Architectures • Short Term Requirements for Network Asserted Identity • Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

  10. Conferencing conference creation – ad-hoc and pre-arranged call leg events  conference membership tracking floor control = SIP events + SOAP Application interaction DTMF control (instead of INFO, complementary to RFC 2833) e.g., KPML for causing HTTP POST on digit combinations User identity via S/MIME Debugging and call history Content indirection Emergency calls Presence and IM: session mode (INVITE-initiated) UPDATE for presence updates is-composing event while typing limit message size delivery confirmation more detailed presence status SIMPLE Java APIs Major SIP standardization items left to do

  11. SIP standardization • After this, mostly into maintenance mode • track bugs and eventually issue RFC 3261bis • Will SIP progress to Draft Standard? • hardly unique: • 883 Proposed Standard RFCs, 99 Draft Standard, 66 Standard • unlikely  too many external dependencies (TLS, S/MIME, SRV, NAPTR, …) • lots of work (interop statements)  too little motivation

  12. Is SIP still simple? • 25 SIP RFCs (+ SDP), 823 pages • and the call flows RFCs aren’t out yet  • RFC 3261 is longest RFC ever • by bytes, RFC 2801 (IOTP) wins by page count • However… • probably only (3GPP) proxy writers need to worry about most of these • can still build a simple user agent in a (long) evening • most effort is likely to be for security: • TLS, digest, S/MIME, AAA, … • DOS protection

  13. What has SIP become? • Session Initiation Protocol – 2 out of 3 words are wrong (or too narrow…) • Plesiosynchronous end-to-end message delivery • with real-time confirmation (unlike email) • but modest rates (unlike RTP) • either as session or stand-alone (“page-mode”) • Rendezvous: find end point via abstract address • Components for specific functionality: • session setup and negotiation: INVITE, UPDATE, OPTIONS, ACK, INFO, BYE, PRACK • event notification sessions: SUBSCRIBE, NOTIFY • page-mode message delivery: MESSAGE • binding management: REGISTER • Transport: from UDP  UDP + TCP  TCP + SCTP + UDP

  14. General VoIP infrastructure • One cannot build a service on SIP alone • Other items still need work: • AAA for SIP, both RADIUS (widely used, but obsolete) and DIAMETER • security infrastructure • how to authenticate to callee? • cheap identities  even PKI mainly helps to identify caller on second call • use OPTION to get callee certificate? • configuration of SIP devices: • configuring by keypad is a pain • configuration by web page doesn’t scale • tftp is insecure and for LAN only • need configuration for identities, protocol parameters

  15. Aside: SIP phone QoS • We measured mouth-to-ear one-way delay of a range of commercial SIP phones and software applications, in a LAN

  16. IP Emergency (911/112) services DHCP 500 W 120th Room 815 MAC  port “911” CDP: port 17, cepsr-7-1 INVITE sip:sos@cs.columbia.edu Location: 500 W 120, Rm. 815 tel:911 500 W 120 jurisdictional directory

  17. SIP security infrastructure • need to store secret in semi-trusted devices • single sign-on? • CINEMA system: • i-button or magnetic swipe card • sets up lines on phone • controls environment • all via SIP events • but phone configuration via screen faking dim lights SIP events add “line” change station

  18. SIP work at Columbia • Location-based services • Event models and filtering • Mesh-based conferencing • End system service creation (CPL extension) • Service discovery

  19. Conclusion • SIP standardization nearing completion • core functionality sufficient to build • 3G mobile system • corporate PBX • but need more operational experience • efforts still telephony-centric, but combinations IM + VoIP emerging • architectural model for “what’s-SIP-good-at” emerging, but different visions

More Related