Project SIP multimedia communication in academic community infrastructure – authentication – client Danijel Matek, Dubra

1. Project SIP multimedia communication in academic community infrastructure – authentication – client Danijel Matek, Dubravko Penezić, Davor Jovanović SRCE, University Computing Centre University of Zagreb dmatek@srce.hr, dpenezic@srce.hr,djovanovic@srce.hr

2. Reasons for starting the project • providing basic services for multimedia communications in real-time (basic audio, video, IM communication and presence) and, in the following phases, advanced services such as online teaching and learning, student counseling, access and sharing of classroom-related multimedia, collaboration and idea sharing, etc. • establishing the system for multimedia communication over which we will have complete control - AA, SIP infrastructure (proxy, register, redirect servers, media servers, PSTN gateways,…) and freedom in implementation of new services and features in endpoints (SIP soft client) - as opposed to expensive commercial solutions over which we could never have complete control

3. Session Initiation Protocol • IETF standard application-layer control (signaling) protocol serving“only” for establishing, controlling and terminating of a session, isnot interested in type of communication between endpoints (clients) and is an open standard replacement for the ITU's H.323 • the above statement gives us possibilities to implement various services in the client (audio, video, instant messaging, file transfer, desktop/ application sharing, …) and these communications will be successful if both or more clients support these functionalities without need for central infrastructure to know what kind of communication exists between clients (it is interested only in signalization) • request-response plaintext protocol, developed from HTTP and SMTP protocols and can be “easily” combined with other Internet protocols

4. Initial phase of the project - Requirements • Infrastructure: • SIP based • authentication process compatible with AA infrastructure AAI@EduHr • multidomain • secure • scalable • LDAP integration • PSTN connectivity • Client: • integration with Web based services and Java applications • platform independent • modular architecture • audio/video/IM, presence, conference, …

5. Initial phase of the project - Testing • getting familiar with details of SIP protocol - principles, functionalities … • testing free solutions: SIP proxies, clients, SIP based media servers (voicemail, conference, …), PSTN gateways • testing possibilities of using existing infrastructure for purposes of SIP infrastructure (e.g. AA infrastructure, LDAP, POTS,…) • testing possibilities of implementation in existing services (e.g. in some web based services and other applications) After the testing phase and obtained initial ideas as well as spotted flaws/problems, the report was made which included certain guidelines and demands set on the central infrastructure and endpoints (SIP client).

6. Initial phase of the project - Report • Infrastructure: • after the testing finished, SIP Express Router proved to be the best solution as a central point of infrastructure along with other solutions from iptel.org (SEMS, RTPProxy, SERWeb), and Asterisk (Digium) as PSTN gateway • incompatibility of authentication process of SIP protocol with AA infrastructure AAI@EduHr • Client: • nonexistance of a client that could meet our future needs to implement advanced services (besides e.g. SIP Communicator that could, in one part, satisfy first phase of the project but it would also require considerable modifications)

7. Initial phase of the project - Decision • Infrastructure: • SER (SIP Express Router) - registrar, proxy, redirect server • SEMS (SIP Express Media Server) - voicemail, conference… • RTPProxy - proxy server for RTP streams • SERWeb - WWW management interface for SER • Asterisk - PSTN gateway (and for other services such as voicemail, conference, etc if required …) • Servlet as interstep in authentication process for generating tokens • Client: • Sun Java platform - development • Java Media Framework (JMF) - multimedia features • JAIN SIP - SIP stack

8. Infrastructure - SIP • SER#1 handles all REGISTER requests (and replicates to SER#2), all INVITE requests, forwards IM and presence related stuff to SER#2, it implements TLS, NAT traversal (forwarding to RTPProxy when necessary), forwarding to PSTN GW, forwarding to voicemail • SER#2 handles all MESSAGE (instant messaging, online/offline) and presence (SUBSCRIBE, PUBLISH, NOTIFY) requests • SEMS, RTPProxy and PSTN GW - media handling

9. Infrastructure - SIP • multidomain • LDAP queries for user data like phone number and email address • PSTN calls - domain dependent • forwarding to PSTN when user is unavailable, busy or has call forwarding enabled • forwarding to voicemail on no answer • storing instant messages when user is offline for later delivery • privacy rules - whitelists and blacklists for instant messaging and presence (availability online/offline) • accounting • features enabled in combination with our client • …

10. Infrastructure - Authentication - incompatibility • SIP implements HTTP digest authentication as authentication model. By its specification it requires users password to be stored in cleartext OR to have computed HA1 (MD5 hash of username:realm:password) stored in database. • Tests of HTTP digest authentication in client-SER-freeradius (cleartext passwords) scenario were successful, but: • X AAI@EduHr infrastructure keeps user password as SHA1 hash, • X Adding another field (HA1) into AA infrastructure would enlarge database and complicate authentication mechanisms

11. Infrastructure - Authentication- solution √ We introduced an interstep in authentication process by implementing servlet which checks users credentials and if authentication is OK it generates a token which than sends into SIP database and to the SIP client. √ Another useful feature of this solution is that after this first authentication, clients perform REGISTER (expire value every 1 hour - SIP default) with a token and not with AAI password.

12. Infrastructure- Authentication- scenario #1 - Srce SIP client Authentication flow: 1. User enters its credentials into SIP client which than contacts servlet by HTTPS request 2. Servlet sends credentials to AA infrastructure and waits for answer 3. If response is positive it generates a token and sends it to the SIP database and to the client. Except fromtoken, servlet calculates HA1 and HA1b MD5 hashesand alsostores them into SIP database. 4. Client then authenticates itself with SIP registrar server with received token (it fully follows SIP authentication process) 5. SIP registrar looks into SIP database for a password (token) OR already computed HA1hash (we implemented this method) 6. If compared values (client and SER generated) are the same, SER sends OK response to the client and client is authenticated and gets registered

13. Infrastructure- Authentication- scenario #2 - other SIP clients 1. 2. • Users visit web page (by HTTPS request)where they enter their credentials • Servlet generates a token and also sends it into SIP database • Users copy token into their clients (Xlite, Eyebeam, SIP Communicator, …)

14. Infrastructure- Authentication- scenario #1 and #2 - comparison • Scenario #1 • Authentication is done automatically on a client level. Users are unaware of authentication interstep • New token is generated every time users start the client (OTP like), or could even be changed on every REGISTER (1 hour) • Once user is removed from AA infrastructure it is also unable to login into SIP infrastructure • Of course, it requires development of our own SIP client. • Scenario #2 • Because of user convenience, once generated and stored token is used forever. • Useful when using some other SIP clients. As we already decided to develop our own client (due to some other features) first solution was an obvious choice.

15. Client • Reasons for development of the client: • integrating some of the clients features into web pages, e.g. presence so users could see who is online and who isnot, or making audio/video/IM communication from web page • developing features and services that we find useful, integrating them into infrastructure and making client and infrastructure homogenous • usage on various devices e.g. mobile phones, PDAs, student information machines on colleges, … as long as they support Java • having full control over the client as all users would use the same and latest version • no need for configuring the client as users always download preconfigured client depending on their institution infrastructure • …

16. Client - current development status • core of the client is realized as a framework around which we can develop various layouts • currently realized as standalone application (WebStart technology) • fully made according to SIP (and other protocols) RFC recommendations • audio, video and instant messaging communication • presence • TLS • NAT traversal solutions (STUN, ICE) • runs on MS Windows/Linux/MacOS • modular architecture • compatible with AAI@EduHr infrastructure

17. Main communication tab our (sending) video window start sending our video remote (receiving) video window status box Volume slider Online/offline button field for entering URI Redial button OnHold button DTMF enabled dialpad Answer button Cancel button Call Forward button DoNotDisturb button

18. Contacts, presence and IM tab user offline user online received/sent IM field IM typing field

19. Configuration tab (most of options will not be visible to regular users as they will be preconfigured) Authentication Proxy settings RTP port range STUN servers Audio/video codecs list (can be changed by user)

20. Log tab(list of finished operations from the moment we statred the client)

21. Client - advantages over other SIP clients • Built in AAI support • Zero configuration (codecs if needed) • Total transparency, user doesnot need to know anything about the underlying infrastructure • Ease of deployment, one click on the link on a web page and the client is installed and up and running • Can be integrated into a web page as java applet • Multi-Platform support • Client doesnot store any user information on a host machine • Can be installed on a less privileged accounts (suitable for Internet cafes) • Automatic updates (web start feature) • Advanced click to dial feature (automatic downloading/installing/calling)

22. Client - future work • file transfer • built in audio and video conference capability • client to web audio and video streaming (e-learning) • localization capabilities • whiteboardcapability • …

23. Infrastrucutre and client - implementation challenges • Infrastructure: • SECURITY • scalability • decentralized infrastructure, load balancing, failover • peering, … • Client: • problems with JMF • rather old, support for few modern audio and video codecs • DSP (digital sound processing) support • not distributed along with Java • circular dependencies between libraries • intuitive and easy to use interface • core with full SIP support • modular architecture, …

24. Thank you Questions... dmatek@srce.hr, dpenezic@srce.hr,djovanovic@srce.hr