18th TF-Mobility Meeting 2 December 2008, Utrecht Project SIP - infrastructure – authentication...
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
2
Transcript of 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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
18
Contacts, presence and IM tab
user offline
user online
received/sent IM field
IM typing field
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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)
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
20
Log tab (list of finished operations from the moment we statred the client)
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – 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)
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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 …
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting 2 December 2008, Utrecht
Project SIP - infrastructure – authentication – client
Thank you
Questions...
[email protected], [email protected], [email protected]
24