18th TF-Mobility Meeting 2 December 2008, Utrecht Project SIP - infrastructure – authentication...

18th TF-Mobility Meeting 2 December 2008, Utrecht

Project SIP - infrastructure – authentication – client

Project SIP

multimedia communication in academic community

infrastructure – authentication – client

Danijel Matek, Dubravko Penezić, Davor Jovanović

SRCE, University Computing Centre

University of Zagreb

[email protected], [email protected], [email protected]

1



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

2



Session Initiation Protocol

IETF standard application-layer control (signaling) protocol serving “only” for establishing, controlling and terminating of a session, is not 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

3



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, …

4



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).

5



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)

6



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

7



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

8



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 …

9



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

10



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.

11



Infrastructure - Authentication - scenario #1 - Srce SIP client

Authentication flow:

1. User enters its credentials into SIP client which than contacts servletby HTTPS request2. Servlet sends credentials to AA infrastructure and waits for answer3. If response is positive it generates a token and sends it to the SIPdatabase and to the client. Except from token, servlet calculates HA1 and HA1b MD5 hashes and also stores them into SIP database.4. Client then authenticates itself with SIP registrar server with receivedtoken (it fully follows SIP authentication process)5. SIP registrar looks into SIP database for a password (token) ORalready computed HA1 hash (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

12



Infrastructure - Authentication - scenario #2 - other SIP clients

1. Users visit web page (by HTTPS request) where they enter their credentials

2. Servlet generates a token and also sends it into SIP database3. Users copy token into their clients (Xlite, Eyebeam, SIP

Communicator, …)

1. 2.

13



Infrastructure - Authentication - scenario #1 and #2 - comparisonScenario #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.

14



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 is not, 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 …

15



Client - current development status

16

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

field for entering URI

Redial button

Answer button

Call Forward button

OnHold button

Cancel button

DoNotDisturb button

DTMF enabled dialpad

Online/offline button

Volume slider



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)



Client - advantages over other SIP clients

21

Built in AAI support Zero configuration (codecs if needed) Total transparency, user does not 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 does not 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)



Client - future work

22

file transfer built in audio and video conference capability client to web audio and video streaming (e-learning) localization capabilities whiteboard capability …



Infrastrucutre and client - implementation challenges

Infrastructure:

o SECURITY

o scalability

o decentralized infrastructure, load balancing, failover

o peering, …

Client:

o 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

o intuitive and easy to use interface

o core with full SIP support

o modular architecture, …

23



Thank you

Questions...

[email protected], [email protected], [email protected]

24

18th TF-Mobility Meeting 2 December 2008, Utrecht Project SIP - infrastructure – authentication...

Documents

Transcript of 18th TF-Mobility Meeting 2 December 2008, Utrecht Project SIP - infrastructure – authentication...