The State of SIP Application Development

2. The State of SIP Application Development Brian Schwarz VP – Engineering RedSky Technologies, Inc.

3. Agenda • What is a SIP Application? • Survey of standards applying to presence and location • Case study – A SIP Application that supports NG911 (SIP calls with location) • Challenges we encountered and how we resolved these

4. What is a SIP Application? • Leverages the capabilities of SIP, but provides value-added services beyond the delivery of the call • Examples: • Call Recording • Unified Communications (UC) • UC with presence and location • Call Center control

5. RedSky’s SIP Application • Receives a SIP call without any location data • Uses the content of the SIP INVITE to determine the location of the calling device • Adds location information either by reference (through a URI) or by value (in a PIDF-LO) to the SIP INVITE • Sends the call out, now with embedded location data that can be used to route the call to the appropriate PSAP (911 call center)

6. Presence Standards • SIMPLE (SIP Extensions for Presence) • Supported by Microsoft (and others) • http://www.ietf.org/html.charters/simple-charter.html • Tight integration with SIP, so presence additions are “seamless” to the existing voice protocols • XMPP (Jabber) • Supported by Google (and others) • http://www.xmpp.org • Better for “chat only” messaging

7. Location Standards • MLP • Mobile Location Protocol • Widely used in existing mobile wireless infrastructure • Supported by OMG (Object Management Group) • XML-based, only allows geo-coded location • HELD/PIDF-LO • “HTTP Enabled Location Delivery” & “Presence Information Data Format-Location Object” • Supported by the IETF (Internet Engineering Task Force) • Allows geo-located and civic addressing schemes

8. Case Study – NG911

9. Challenges to SIP Apps: B2BUA vs Proxy • Proxy is simpler to develop and test than a B2BUA • “Real” function of the RedSky LIS is as a proxy – we’re not changing the original SIP content • Only way to implement additions to the INVITE body is through a B2BUA • The B2BUA takes on additional requirements in terms of callback routing • Standards say that the FROM address out of the B2BUA should be the address of the B2BUA. How do we route a dropped call back to the originating device?

10. Challenge: Choosing the right SIP stack • Roll your own • Longer development time and interop requirements • “Flexibility” in implementing the standards with regard to content • Open Source (i.e. JAIN) • Better development time, but still requires “app” infrastructure • SipServlets (i.e. GlassFish, BEA) • Fast development, focusing only on the application content • Reduced control over the SIP content

11. Challenge: SIP capabilities abstract data • SIP abstracts the actual device making the call • Location Determination – loss of MAC address • Port-level discovery uses SNMP queries to the BRIDGE MIB on network switches, matching the MAC address to a port • SIP doesn’t communicate the MAC address – how to do port-level discovery? • Shared line • Multiple devices can share the same SIP URI • When dialing 911 – which device made the call?

12. Challenge: SIP Data • Even if SIP entities (i.e. clients, proxies and B2BUAs) can interoperate, the content of the SIP data can be crucial to an application • Requires careful design of the data content within the SIP messaging to ensure the application will function properly

13. Questions?