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
dmatek@srce.hr, dpenezic@srce.hr, djovanovic@srce.hr
18th TF-Mobility Meeting
2 December 2008, Utrecht
1
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
2
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
3
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, …
18th TF-Mobility Meeting
2 December 2008, Utrecht
4
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).
18th TF-Mobility Meeting
2 December 2008, Utrecht
5
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)
18th TF-Mobility Meeting
2 December 2008, Utrecht
6
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
7
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
8
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
…
18th TF-Mobility Meeting
2 December 2008, Utrecht
9
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
10
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.
18th TF-Mobility Meeting
2 December 2008, Utrecht
11
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 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 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 received
token (it fully follows SIP authentication process)
5. SIP registrar looks into SIP database for a password (token) OR
already 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
18th TF-Mobility Meeting
2 December 2008, Utrecht
12
Project SIP - infrastructure – authentication – client
Infrastructure - Authentication - scenario #2 - other SIP clients
1.
2.
1. Users visit web page (by HTTPS request) where they enter their
credentials
2. Servlet generates a token and also sends it into SIP database
3. Users copy token into their clients (Xlite, Eyebeam, SIP
Communicator, …)
18th TF-Mobility Meeting
2 December 2008, Utrecht
13
Project SIP - infrastructure – authentication – client
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.
18th TF-Mobility Meeting
2 December 2008, Utrecht
14
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
…
18th TF-Mobility Meeting
2 December 2008, Utrecht
15
Project SIP - infrastructure – authentication – client
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
18th TF-Mobility Meeting
2 December 2008, Utrecht
16
Project SIP - infrastructure – authentication – client
Main communication tab
our (sending) video window
start sending our video
remote (receiving) video window
status box
Volume slider
field for entering URI
Redial button
Answer button
Call Forward button
18th TF-Mobility Meeting
Online/offline button
OnHold button
DTMF enabled dialpad
Cancel button
DoNotDisturb button
2 December 2008, Utrecht
17
Project SIP - infrastructure – authentication – client
Contacts, presence and IM tab
user offline
user online
received/sent IM field
IM typing field
18th TF-Mobility Meeting
2 December 2008, Utrecht
18
Project SIP - infrastructure – authentication – client
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
19
Project SIP - infrastructure – authentication – client
Log tab (list of finished operations from the moment we statred the client)
18th TF-Mobility Meeting
2 December 2008, Utrecht
20
Project SIP - infrastructure – authentication – client
Client - advantages over other SIP clients
 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
21
Project SIP - infrastructure – authentication – client
Client - future work
 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
22
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, …
18th TF-Mobility Meeting
2 December 2008, Utrecht
23
Project SIP - infrastructure – authentication – client
Thank you
Questions...
dmatek@srce.hr, dpenezic@srce.hr, djovanovic@srce.hr
18th TF-Mobility Meeting
2 December 2008, Utrecht
24