SIP.edu : OpenSER in an academic environment

OpenSER SUMMIT - VON – Berlin 2006

Agenda

Introduction INRIA The SIP.edu project

SIP.edu at INRIA Access control with RADIUS

Expected limitations and problems Future improvements

INRIA

French National Institute for Research in Computer Science and Control

Fundamental and applied research in various fields Networking Multimedia Software security Modeling living structures and mechanisms

5000 people in 6 locations

The SIP.edu project

Started in late 2003, from an Internet2 organization initiative

Aims to connect academic institutions with SIP Two prerequisites

A user e-mail to phone number mapping mechanism SIP address ~= email address

Integrate with an existing PBX to make non-SIP phones reachable Not necessarily IP enabled

More than 250,000 people reachable MIT, Harvard University, Yale, ..

SIP.edu : target architecture

SIP.edu at INRIA

DNS SRV records to our SIP proxy SIP proxy : OpenSER version 1.0.1 Directory : OpenLDAP

Gathers the information for all INRIA members SIP PBX gateway : Asterisk + Cisco router

12 channels to the existing PBX PBX : TENOVIS

SIP.edu at INRIA : the picture

Available services

“sip:first.last@inria.fr” URIs that map with regular E.164 extensions at INRIA Accessible to anyone from the Internet

“sip:0123456789@inria.fr” URIs, to call external E.164 extensions Restricted to INRIA’s members

RADIUS based access control

Sample call flow to a numeric extension To initiate a call to PSTN extension 0123456789, Alice types

“sip:0123456789@inria.fr" into her SIP user agent (UA); DNS SRV query Sent to INRIA’s SIP proxy

The proxy detects a numeric extension, and triggers the RADIUS authentication process

The proxy re-writes the INVITE to INVITE sip:0123456789@asterisk.inria.fr, which it

sends to the Asterisk server;

Asterisk rings extension 0123456789 through the PSTN gateway and PBX.

SIP and RADIUS : user password storage Two alternatives

Clear text format Insecure Regular authentication database cannot be used

Digest-HA1: MD5(username:realm:password) User password is kept opaque to the admin Stored information is still sensitive Regular authentication database cannot be used

The key role of OpenSER

Call processing logic Not that easy to handle but powerful

Modular software architecture Many database/protocols connectors

RADIUS, SQL, Jabber, .. External scripting integration

In our SIP.edu architecture, the LDAP information retrieval process is a shell script launched by OpenSER

Expected limitations and problems

NAT issues SPIT (SPam over IP Telephony)

Use inter-domain TLS?

OpenSER already addresses those issues

Future improvements

Enable RADIUS authorization by implementing group checking

Integrate with our Jabber based IM - presence solution

Already possible with OpenSER