Multimedia Communication in the Internet SIP: Advanced Topics

1. Multimedia Communication in the InternetSIP: Advanced Topics Dorgham Sisalem Mobile Integrated Services FhG Fokus

2. SIP Service Space

3. What’s the Killer App? • Q: Added-value services expected to be major source of revenues. So what is the killer app? • A: If I saw raw gold on the street I would not tell you either. • It is believed that the convenience of integrated services will be the killer. • Couple of examples follow...

4. Most of IN services may be easily implemented with SIP in proxies/redirect servers/UAs: (Un)conditional call forwarding abbreviated dialing Screening distinctive ringing call distribution call transfer etc. Sometimes, implementation logic may completely differ. Televoting and IVRs likely to be replaced by Web in the long run. Call-waiting is end-device implementation issue with no protocol support. Music-on-hold may be played localy. IN-like Services with SIP The real benefit is those services beyond IN: straight-forward integration with web, email, instant messaging, etc.

5. Call Transfer draft-ietf-sip-cc-transfer • Accomplished using the REFER method. • The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the method. • New header fields: Refer-To, Refer-By. • NOTIFY method used to report on result of referral. • Note: No changes to proxy behavior required. • Variants: • With Consultation Hold (SIP Hold and unattended transfer) • Attended Transfer, I.e., with a short conference

6. Example: Call Transfer Call Flow REFER B To: B Refer-To: C Referred-By: A #1 INVITE C Referred-By: A #3 202 Accept #2 C A #4 200 OK #5 #7 200 ACK #6 NOTIFY (OK) 200 OK media A is having a call with B. A decides to transfer B to C. It sends a “REFER” to B with C’s address. Eventually, A is notified on successful transfer using NOTIFY (#6). B timeline

7. 3rd Party Call Control (3pcc) • 3pcc = Ability of a party to establish a session between other parties. • Examples of use: • a click-to-dial service within a web phone-book • Operator services • Scheduled calls • Design objective: use SIP “as is” • Solution: send “empty INVITES”, and swap replies with SDP ACKs • Controller may issue either its own or other’s party “forged” From address. (Its real identity may be still verified using authentication.) • Controller often called back-2-back user agent • Act as two user agents acting back-2-back • Manipulate messages coming from one agent before sending to the other • Main state information about the two sessions draft-rosenberg-sip-3pcc

8. Example: 3pcc call flow INV w/o SDP #2 200 SDP A1 ACK on-hold #3 B A #4 INV w/o SDP #5 200 SDP B #6 INV SDP B #7 200 SDP A2 #8 200 ACK w/A2’ #1 media ACK #9 draft-rosenberg-sip-3pcc Controller C (e.g., co-located With a web server) timeline

9. Answering Machine #1 INVITE #2 Trying #3 INVITE #4 Ringing #5 CANCEL AM #6 OK #7 INVITE • Old-times behavior: set-up number of rings, plug-in, if you do not answer the machine will • Easy to mimic with SIP: AM acts as a SIP UA; you need to set-up an answer timer, let the answering machine register using your credentials; when an invitation arrives it is forked both to your phone and your answering machine • Added value examples: • Unified messaging: SIP answering machine can turn voice messages into email messages that follow you or comprehensive web-pages (cf. voice navigation) • Programmability allows to play variety of customized prompt messages: • If (caller  friends) then play (“You can reach me at Venice beach or leave a message”) else play (“leave a message please”);

10. Programming SIP Services

11. Programming SIP • Examples • “discard all calls from Monica during my business hours” • “redirect authenticated friends to my cell phone, anyone else to my secretary” • “if busy, return my homepage and redirect to recorder” • Users and third parties may program • SIP follows HTTP programming model • Mechanisms suggested in IETF: CGI, Call Processing Language (CPL), Servlets

12. Goals • Minimize Time To Market • Implement SIP applications without detailed SIP knowledge • Reduce Lines Of Code by using abstraction functions • Improve Quality Of Service • Avoid software bugs by using abstraction programming interface • E.g.: call.forward (“sip:aa@iptel.org”) works independent of caller’s and callee’s actual state

13. Service Execution Layering CPL scripts CGI Scripts (Perl, Python, C, …) Servlets User Code Java Servlets SIP-CGI CPL Interpreters SIP Messages SIP Actions Protocol stack SIP

14. Call Processing Logic Example Jku’s call processing logic: If ($caller is in {Jane, Bob}) proxy to jku@cell.com else proxy to voicemail@trash.com Jku’s call processing logic: If ($caller ==Jane) play Mozart else play Smetana The call processing logic may be designed using various mechanisms: CPL, SIP-CGI, servlet, proprietary ones. #2 pass invitation to call processing logic #3 return an action #5 #4a INVITE jku@cell #1 INVITE jku #4b INVITE voicemail@trash

15. Where May Signaling Services Live? • Some services have to live in the network: • call distribution • services for dial-up users without always-on IP connectivity • network servers may be located on users’ premises (PBX-like) or operator’s premises (Web-hosting-like, NetCentrex-like) • Some services can be implemented in both places: • forward on busy • Some services work best in end-devices: • distinctive ringing

16. Service Location Examples Source: H. Schulzrinne: “Industrial Strength IP Telephony”

17. SIP Common Gateway Interface (CGI) RFC 3050 • Follows Web-CGI. Unlike Web-CGI, SIP-CGI supports proxying and processes responses as well. • Language-indpendent (Perl, C, ...) • Communicates through input/output and environment variables. • CGI programs unlimited in their power. Drawback: Buggy scripts may affect server behavior easily. • Persistency token (cookie) is passed between SIP server and CGI to keep state across requests and related responses.

18. SIP-CGI I/O • Script input: environment variables (AUTH_TYPE, CONTENT_LENGTH, REQUEST_URI, etc.) and SIP message on stdin • Script output: set of messages consisting of action lines, CGI header fields and SIP header fields on stdout • Action lines: • Generating a response: status line • Proxying: • CGI-PROXY-REQUEST <dest-url> <sip-version> • Additional header fields may be followed – they will be merged with the original request. • Forward response: CGI-FORWARD-RESPONSE <token> <sip-version> • Set cookie for subsequent messages: CGI-SET-COOKIE <token> <sip-version> • Determine if the script should be called for the next message belonging to the same transaction: CGI-AGAIN ("yes" | "no") <sip-version>

19. Call Processing Language • Special-purpose call processing language. • CPL scripts define a decision tree which may result in signaling (proxy, redirect, reject) or non-signaling (mail, log) action. • CPL scripts triggered by SIP messages. • May be used by both SIP and H.323 servers. • Target scenario: users determine call processing logic executed at a server. • Limited languages scope makes sure server’s security will not get compromised. • Portability allows users to move CPL scripts across servers. • Scripts may be manually written, generated using convenient GUI tools, supplied by 3rd parties, ... draft-ietf-iptel-cpl

20. CPL Example <incoming> <address-switch field="origin" subfield="host"> <address subdomain-of="example.com"> <location url="sip:jones@example.com"> <proxy timeout="10"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <sub ref="voicemail" /> </noanswer> <failure> <sub ref="voicemail" /> </failure> </proxy> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming>

21. Example: Creating CPL Scripts iptel.org: CPL Composer

22. JAIN: SIP Servlets and API http://java.sun.com/products/jain/ • JAIN: Java APIs for Integrated Network Framework • Compromise between security and power: still a powerful generic language but security provided by Java “sand-box”. • JAIN is a protocol independent API applicable to almost any signaling (SIP, H.323, PSTN, etc.) • Java servlets are a high-level API building on top of HTTP servlet API (package javax.servlet.sip) • JAIN SIP is a low-level API for complete control over a SIP stack. (package jain.protocol.ip.sip) • Further JAIN Protocol API Specifications: ISUP, MGCP, H.323, etc. • JAIN App API Specs: Call Control • Technology Compatibility Kit (TCK) tests an implementation of the JAIN SIP interfaces for compliance with the JAIN SIP Specification • http://java.sun.com/products/jain/index.html

23. JAIN Components • JAIN SIP Events: Within the API, SIP messages are encapsulated as Message objects that are passed between the JAIN SIP Provider and the JAIN SIP Listener. • JAIN SIP Provider: Within the API, the JAIN SIP Provider is defined as the entity that provides an application access to the services of the SIP stack. • JAIN SIP Listener: Within the API, the JAIN SIP Listener is defined as the entity that uses the services provided by the JAIN SIP Provider.  

24. SipListener processRequest processResponse Process Timeout SipProvider sendResponse sendRequest addSIPListener SipURL Message addHeader getBodyAsBytes removeViaHeaders Request setRouteHeaders Response setStatusCode JAIN Classes and Methods Note: methods shown here are only subsets of all available method!

25. Call Processing Tradeoffs • Generality versus security • multipurpose programming languages provide a huge service space • but also a huge vulnerability space • Performance versus portability • portable languages (CPL) need to be interpreted • higher processing delay • portability needed if services deployed at multiple servers or end-devices (e.g. if stored at USIMs)

26. Which Service Creation Method Should I Use? • choice of appropriate service creation mechanism depends on deployment scenario • where the service is executed (operator’s proxy vs. user’s end-device) • by whom the service is maintained (user vs. administrator) • demanded service logic • Scenario #1: A SIP site administrator wants to allow customers to define their personalized call forwarding preferences • CPL is chosen for best security • Web CPL editor is provided for user convenience • Scenario #2: A SIP site administrator wants to define an access control list for protecting a PSTN gateway pool • Call processing logic depends on authentication data and call destinations -> CPL is not sufficient (no authentication switch) -> CGI or Servlets • Scenario #3: An enterprise SIP proxy used for 3-rd party apps • Servlets used for generality and portability

27. Other Work • There seems to be a huge interest in creating call control APIs. Other efforts include: • Parlay • TAPI • JTAPI • CTI • ...

28. SIP and Mobility

29. SIP and Mobility • Solutions space by layers • Application layer: SIP-based mobility support • drawback: application specific, needs to be re-implemented for every application • IP layer: Mobile-IP • drawback: IPv4 triangle routing, nobody knows when IPv6 happens • lower layers • current cell phone networks • wireless IP (WaveLANs ?)

30. SIP and Terminal Mobility • Terminal can move between subnetworks • Realised today with GSM and wireless LAN • Issues to consider: • Handoff performance • Redirection authentication • Mobile hosts (MH) inform their home proxy about their new locations using REGISTER • Mid-call mobility (Session mobility) is dealt with using reINVITE

31. SIP and Terminal Mobility #1 #2 REGISTER REGISTER Home Network HP Cell 2 Signalling FP Cell 1 Visited Network

32. SIP and Terminal Mobility #1 #2 #3 #4 INVITE INVITE INVITE Home Network HP Cell 2 Signalling Data FP Cell 1 Visited Network

33. SIP and Terminal Mobility #3 #2 #1 #3 #4 reINVITE REGISTER REGISTER Home Network HP Cell 2 Signalling Data FP Cell 1 Visited Network

34. SIP and Terminal Mobility #3 #2 #3 #4 reINVITE REGISTER REGISTER Home Network HP Cell 2 Signalling Data FP Cell 1 Visited Network

35. SIP and Personal Mobility • Person uses different Devices and possibly address • REGISTER binds a person to a device • Proxy and redirect translate address to location and device • Issues to consider: • Authentication: finger print, IR, password .. • Binding different addresses to single person: LDAP ..

36. SIP and Service Mobility • Use same services from different locations and devices • Speed dial, address book, media preferences, call handling • Services located at home server • RECORD-ROUTE home proxy to force calls to be processed by home servers • Services located at end systems • retrieve with REGISTER • Issues to consider • Services need to be device independent: standardised service description (CPL) .. • User recognition and authentication

37. SIP and Mobile-IP • Mobile-IP is a well established standard for mobile communication in the Internet • Allow hosts to be reached under the same address regardless of location • Mobile hosts register a care-of-address with home agent • Correspondent nodes (CN) send data to home agent • Home agent tunnels traffic to care-of-address • MH sends traffic directly to CN • Triangular routing increases delay • Tunnelling increases bandwidth consumption

38. Mobile-IP (Registration) #2 #1 Registration Registration Home Network HA Cell 1 FA Cell 2 Visited Network

39. Mobile-IP (Communication) #1 #2 #3 #4 #5 #6 #7 Home Network HA Cell 1 Signalling Data FA Cell 2 Visited Network

40. SIP and Mobile-IPv6 • IPv6 is especially interesting for mobile Internet • Mobile-IPv6 uses Binding updates similar to SIP registration and reinvitations to avoids triangular routing • Use routing header option to avoid tunnelling • Could be a solution for providing a unified protocol for mobile data and voice communication??

41. SIP Robustness

42. Robust Protocol Design • Robustness determined by state maintenance model • Amount of state in SIP Servers minimized • servers may be stateless (SL) or maintain transaction state (TS) or session state (SS) • The less state the more robustness; failure of a SL or TS proxy does not affect existing sessions • transactional state is needed to enable services such as forking/forward-on-busy or if SIP runs over TCP • session state may be needed for maintaining firewalls or generating failure-resistant CDRs; keep-alive possible using re-INVITEs and session timer • SIP INVITEs convey full signaling state • Subsequent messages may take different path

43. DNS for Failure Recovery & Load Balancing • Unavailable SIP servers can be dealt with using DNS in the same way as mail servers are: • DNS servers maintain multiple prioritized SRV entries • callers initiate calls to high-priority server; if unavailable, they proceed to lower-priority server • Load balancing can be accomplished similarly • DNS servers maintain multiple SRV entries with equal priority • Phone do not support this very often these days • a random pick is chosen out of the server list • Notes on DNS • it’s good do have multiple DNS servers for each zone of authority; • DNS may be a pain ...

44. Other Load Balancing Methods • A front-end proxy may dispatch calls to a proxy farm • Load-balancing NAT may be used • Call processing logic may be off-loaded to end-devices

45. SIP and QoS Control

46. QoS: SIP and QoS Control draft-ietf-sip-manyfolks-resource • SIP DOES NOT provide QoS support. • QoS is coupled with SIP through the notion of preconditions. • Objective is to ensure that resources are made available before the phone rings. • Invitations might indicate in SDP that QoS assurance is mandatory. • Call setup should only proceed after satisfying the preconditions • SIP extended method (UPDATE) indicates the success or failure of the preconditions. • “confirm” attribute in SDP tells the other party to indicate met preconditions. If both parties send “confirm”, session originator sends UPDATE last.

47. SIP and QoS Control #10 #8 #7 #6 #4 #11 #5 #9 #2 183 Progress m=audio 49170 RTP/AVP 0 a=qos:mandatory send confirm #3 INVITE sip:Callee@example.com m=audio 49170 RTP/AVP 0 a=qos:mandatory sendrecv confirm #1 INVITE sip:Callee@support.example.com m=audio 49170 RTP/AVP 0 a=qos:mandatory sendrecv confirm PRACK 183 Progress m=audio 49170 RTP/AVP 0 a=qos:mandatory send confirm ACK 200 OK (INVITE) 200 OK (UPDATE) UPDATE Reserve Media stream Caller@sip.com Callee@support.example.com Proxy