SIP in wireless applications Henning Schulzrinne Dept. of Computer Science Columbia University

Overview New developments presence and IM  location-based services identity management Standardization status Issues complexity integration spam Resources

New developments: presence, location-based services, IM Old ring-and-hope (or ring-and-annoy) model is obsolete Presence and event notification model: human availability environmental events (alarms) business events (e.g., machine malfunction) Mobile devices as prime sources of presence information: recent device use: outbound calls answered calls unanswered calls location information (from Phase II 911) including motion (driving) longer term: activity information

GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface XCAP (rules) INVITE DHCP

The role of presence for call routing Two modes: watcher uses presence information to select suitable contacts advisory – caller may not adhere to suggestions and still call when you’re in a meeting user call routing policy informed by presence likely less flexible – machine intelligence “if activities indicate meeting, route to tuple indicating assistant” “try most-recently-active contact first” (seq. forking) LESS translate RPID CPL PA PUBLISH NOTIFY INVITE

RPID: rich presence

New developments: location- based services My lab working on language for end- system services (LESS), including location-based services User (or administrator) creates services Designed to be portable across devices Java APIs  alternatives with different trade-offs

Service creation

SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringing RFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy” dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

A constellation of SIP RFCs Resource mgt. (3312) Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) DHCP (3361) DHCPv6 (3319) Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) Non-adjacent (3327) Symmetric resp. (3581) Service route (3608) User agent caps (3840) Caller prefs (3841) ISUP (3204) sipfrag (3240) Security & privacy Configuration Core Mostly PSTN Content types Request routing

An eco system, not just a protocol SIP XCAP (config) RTSP SIMPLE policy RPID …. SDP XCON (conferencing) STUN TURN RTP configures initiatescarries controls provide addresses

SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

RFC publication

When are we going to get there? Currently, 14 SIP + 33 SIPPING + 17 SIMPLE WG Internet Drafts = 64 total does not count individual drafts likely to be “promoted” to WG status The.com consultant linear extrapolation technique ® pessimist  4 more years if no new work is added to the queue and we can keep up productivity optimist  3 more years (lots of drafts are in almost-done stage)

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

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

Issues for SIP in 3GPP/3GPP2 Complexity 14+ messages PSTN-based worldview somewhat peculiar notions of scaling may be able to combine multiple logical elements Cross-carrier roaming Integration with non-3G systems e.g., seamless integration with enterprise SIP systems or landline service providers separation of bearer and identity possibly share same mobile device Service creation by non-carriers e.g., vertical applications

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

SIP network architecture Scalability requirement depends on role GW MG IP network PSTN SIP/PSTN SIP/MGC Carrier network ISP Cybercafe IP PSTN GW PBX IP phones PSTN phones T1 PRI/BRI

Reliability and scalability Analysis, simulation and measurement proposal When is stateless proxy stage needed What are the optimal values for S,B,P for required scalability (1-10 million BHCA) and reliability (99.999%) using commodity hardware MasterSlaveMasterSlave s1 s2 s3 a1 a2 b1 b2 S=3 B=2 P=1+1 ex = R + P REGISTER+ INVITE, etc  r,  p ss /B R s M s R p M p

Scaling example

Scaling and reliability No single point of failure Geographical redundancy Can use commodity servers to build 6- nines system: Each cluster with 3 servers with 99% uptime (3 days/year outage)  % availability Scalable to roughly 10 million BHCA 5ESS: 4 m BHCA

Software Resources Lots of commercial and open-source components, e.g., proxies iptel.org (OSS), sipd, … application servers Ubiquity, Broadsoft SIP stacks reSIProcate (OSS), Hughes, RADvision, various Java stacks SIP test tools sipsak, SIP Forum test suite (SFTF)

Why is Skype successful? All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience Software vendor = service provider Didn’t know that you couldn’t do voice quality beyond PSTN others too focused on PSTN interoperability – why do better voice than PSTN? Simpler solutions for NAT traversal use TCP if necessary use port 80 Did encryption from the very beginning Kazaa marketing vehicle