Presentation on theme: "SIP.edu : OpenSER in an academic environment OpenSER SUMMIT - VON – Berlin 2006."— Presentation transcript:
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 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
Available services “sip:firstname.lastname@example.org” URIs that map with regular E.164 extensions at INRIA Accessible to anyone from the Internet “sip:email@example.com” 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:firstname.lastname@example.org " 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:email@example.com, 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