1 / 26

SIP Musings

SIP Musings. Henning Schulzrinne SIP Summit – Las Vegas May 8, 2002. Outline. Where is SIP in 2002? challenges: multimedia conferencing binding SIP to other protocols privacy and identity emergency services SIP tenets challenged by the real ($) world. Where in the world is SIP?.

martin-cross
Download Presentation

SIP Musings

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 Musings Henning Schulzrinne SIP Summit – Las Vegas May 8, 2002

  2. Outline • Where is SIP in 2002? • challenges: • multimedia conferencing • binding SIP to other protocols • privacy and identity • emergency services • SIP tenets challenged by the real ($) world

  3. Where in the world is SIP? • SIP as the signaling protocol for future applications • 3GPP • Cable modems (DOCSIS DCS) • IM: AOL interworking (eventually...), Windows Messenger • but: H.323 dominates videoconferencing, trunk replacement • Proprietary protocols dominate for Ethernet phones • Slow uptake of VoIP

  4. How did we get there? • Not quite what we had in mind • initially, for initiating multicast conferencing • in progress since 1992 • still small niche • even the IAB and IESG meet by POTS conference… • then VoIP • written-off equipment (circuit-switched) vs. new equipment (VoIP) • bandwidth is (mostly) not the problem • “can’t get new services if other end is POTS’’  “why use VoIP if I can’t get new services”

  5. How did we get here? • VoIP: avoiding the installed base issue • cable modems – lifeline service • 3GPP – vaporware? • Finally, IM/presence and events • probably, first major application • offers real advantage: interoperable IM • also, new service

  6. SIP developments in 2001/02 • SIP revision (“RFC2543bis”, RFC3261) almost done: • semantically-oriented rewrite • layers: message, transport, transaction, transaction user • SDP extracted into separate draft • UA and proxy have the same state machinery • better Route/Record-Route spec for loose routing • no more Basic authentication • few optional headers (In-Reply-To, Call-Info, Alert-Info, …) • Integration of reliable provisional responses and server features • DNS SRV modifications

  7. SIP developments in 2001/02 • SIP revision backwards compatible • “new” messages work with RFC 2543 implementations • some odd allowed RFC 2543 behavior no longer allowed • CPL finished – merger with iCal • sip-cgi published • IM & presence mostly done, except for IM sessions (over TCP)  separate message stream

  8. SIP developments in 2001/02 • Work continues on staples: • early media (announcements) • resource reservation (COMET) • SIP security • SIP events • User identification: "network asserted identity", privacy • Call transfer and call control • Now three SIP working groups: • SIP for protocol definition and extensions • SIPPING for applications and “vetting” • SIMPLE for IM & presence

  9. Conferencing • SIP designed for (multicast) multimedia conferences • most conferences are small (~5)  central-server ("star") conferences • may be star of stars • single-source multicast (SSM) • need supporting infrastructure: • conference management • user management • floor management • user management

  10. Conferencing • Conference management • create, delete • properties (visibility, duration, ...) • User management • mass invitation • automated and manual user admission • join and leave notification • membership lists • Floor control • request and release floor • re-order queue

  11. Binding SIP to other protocols • SIP not a universal data transport protocol  connect SIP to other protocols via URLs • get more data • Call-Info, Error-Info, Alert-Info • NOTIFY: pointer to message content • obtain configuration information • signed (long) version of SDP • publish data • presence document • buddy lists • CPL, sip-cgi, servlet • conference (user, floor) management

  12. Binding SIP to other protocols • Sometimes needed for address-of-record • REGISTER addresses AOR • sometimes for particular UA only • OPTIONS addresses endpoint(s) • clients need to obtain URIs & set them • service mobility

  13. Identity and privacy • Conflicting goals: • caller may want privacy • callee wants real identity  SIP as telemarketer's dream? • FBI wants CALEA • Traditional "caller-ID" doesn't work well in SIP: • user, not device identity • iffy notion of trusted providers • SIP direct  no need for carrier • Proposal in SIP* WG: • asserted identity without authentication • signed identity based on first-hop authentication

  14. Emergency services • Two types of emergency services: • emergency calls ("911", "112") • emergency notification ("inverse 911") • emergency calls are hard: • PSTN gateway dialing 911 may be located anywhere, far away from IP phone • VPNs  IP address may not reveal network location

  15. Emergency services • Work for both "legacy" PSAPs and IP-based PSAPs • find location of phone based on • street address  geocoding  long/lat • longitude, latitude • find appropriate PSAP for jurisdiction • find ESR (routing number)  call appears like 911 call • convey location

  16. 911 deployment

  17. Emergency notification • notify public officials and citizens of emergencies: • "tornado coming" • "fugitive alert" • current systems are typically single-mode (fax, telex, phone, TV, loudspeaker) • don't scale well • very limited information content • don't reach citizens outside calling area • people at work • hard to authenticate

  18. SIP-based emergency notification • SIP has scalable event notification feature • use for hierarchical notification reflecting civil lines of authority • use XML/WSDL message bodies to semantically describe emergency: • location • type of emergency • instructions • ... • allow automated reaction: • routing to legacy systems (pagers, police radios) • translation

  19. Emergency notification

  20. Domesticating SIP • Temptation to make it look like SIP on the wire, but lacks core SIP design properties • SIP is designed as a common carrier protocol: • content-neutral • application-neutral • plausible deniability in proxies • proxy as minimally aware entities: • pass unknown SIP headers • handle any method • don't touch bodies

  21. SIP design principles • SIP design: • extensibility in all elements  methods, headers, content types • disclosure of message handling to user  Via • user influence over message handling  Require, caller preferences

  22. SIP: mind-changing • "network" services  end-system services • proxies as willing helpers, not service disablers • trusted network or network federations PKI, distributed trust, "tunneled" trust • media-neutrality

  23. 3G: Falling into the WAP trap? • "3G adopts SIP"  "3G adapts SIP" • if just another IP transport, should not need to explicitly do anything • wireless-specific: bandwidth scarcity  compression • overspecified  no need for C/S/P-CSCF as standard  just one of many possible architectures • allow roofed + walled garden with customed characters and "forever wild" national park

  24. The fallacy of topology hiding • "don't reveal server structure" • infinite ways to leak to a determined "spy" • proxies don't reveal IP-layer connectivity or bandwidths • knowing proxy addresses doesn't reveal proxy capacity • security through obscurity? • costs of hiding: • lack of diagnosability of faults • extensibility decreases

  25. SIP doesn’t have to be in a phone sip:lava@cs.columbia.edu

  26. Conclusion • Goal of single world-wide, transport-independent session setup protocol within reach • Danger of non-interoperable islands • repeat of mobile signaling division • ISDN • Need to address operational issues • not signaling load, administrator load • emergency calls • trust & privacy

More Related