170 likes | 307 Views
ANM 2008, Phoenix – April, 18 th Helmut Hlavacs, Andrea Hess, Michael Nussbaumer karin.hummel@univie.ac.at University of Vienna Department of Distributed and Multimedia Systems. Babel-SIP: Self-learning SIP Message Adaptation for Increasing SIP-Compatibility. Problem Statement.
E N D
ANM 2008, Phoenix – April, 18th Helmut Hlavacs, Andrea Hess, Michael Nussbaumer karin.hummel@univie.ac.at University of Vienna Department of Distributed and Multimedia Systems Babel-SIP: Self-learning SIP Message Adaptation for Increasing SIP-Compatibility
Problem Statement Open protocols • Multiple vendors • Compatibility depends on the accurateness of implementations Example: SIP (Session Initiation Protocol) for VoIP • Vendors publish lists of compatible hard phones • Remaining problems with SIP dialects How to overcome incompatibilities of peers?
Use Techniques from “Autonomic Computing” Analogy to the human autonomic nervous system Investigated to increase autonomicity in computing systems IBM initiative from 2001[1] Self-x properties Self-configuring Self-protecting Self-healing Self-optimizing etc. Artificial Intelligence research Autonomous software agents, robots Planning, reasoning, and learning [1] Richard Murch. Autonomic Computing. IBM Press. 2005
Outline of the Talk SIP (Session Initiation Protocol) Autonomic SIP adaptation C4.5 tree Babel-SIP Experiments Quantitative results Qualitative results
SIP (Session Initiation Protocol) Session management of the Internet Multimedia Subsystem (IMS) of Next Generation Networks, Voice over IP (VoIP) Defined in RFC 3261 (and additional RFCs for different aspects like RFC 3262, 3263, 3265, 3515, 3311, 3665, and others) • Uses TCP/IP protocol stack • SIP header fields Functions • User location • User availability • User capabilities • Session setup • Session management REGISTER sip:Domain SIP/2.0 To: <sip:UserID@Domain> From: <sip:UserID@Domain> Via: SIP/2.0/UDP IPAdress:Port Call-ID: NDYzYzMwNjJhMDRjYTFj CSeq: 1 REGISTER Contact: <sip:UserID@IPAdress:Port> Max-Forwards: 70
Autonomic SIP Adaptation Problem of transient incompatibilities Introduce a module for arbitrary proxies: Classification of messages (accepted/rejected) Adaptation of messages to avoid rejections Generic approach (not specific for SIP)
C4.5 Decision Trees Used for classification, to identify relevant header parameters causing rejections Training phase required to build the tree Avoids over-fitting, capable to deal with incomplete data For SIP messages: headers, header fields, and standard values are defined as tree attributes 274 attributes per (REGISTER) message Implementation: WEKA machine learning library, J48 C4.5 tree Attributes are stored in Attribute Relation File Format (ARFF) Input: attribute vector A Output: attribute vector A with new values FOREACH (Ai in A) Ai.value = 0 IF (Ai.name in SIP message) THEN IF (SIP message field is numeric) THEN Ai.value = value of SIP message field ELSE Ai.value = 1
Example C4.5 Tree (Trained with REGISTERs) Hierarchy shows the importance of parameters Replaces <= 0 | Allow_DO <= 0 | | Content-Language <= 0 | | | Contact_methods <= 0 | | | | To_user <= 0: ACCEPTED (112.0/5.0) | | | | To_user > 0 | | | | | Contact_q <= 0 | | | | | | Call-ID <= 0: REJECTED (2.0) | | | | | | Call-ID > 0: ACCEPTED (12.0/1.0) | | | | | Contact_q > 0: REJECTED (2.0) | | | Contact_methods > 0 | | | | Accept <= 0: REJECTED (6.0/1.0) | | | | Accept > 0: ACCEPTED (11.0/1.0) | | Content-Language > 0 | | | Contact_flow-id <= 0: REJECTED (6.0/1.0) | | | Contact_flow-id > 0: ACCEPTED (2.0) | Allow_DO > 0 | | Allow-Events_talk <= 0: REJECTED (6.0) | | Allow-Events_talk > 0: ACCEPTED (3.0/1.0) Replaces > 0: REJECTED (11.0) Number of messages classified / wrong classifications
Babel SIP Automatic protocol adapter • Placed between the proxy socket and the UA • Observes rejected/accepted messages to train C4.5 tree • Classifies messages and adapts likely rejected messages mi • Distance metric d(mi,mj) to choose the message mc from the set of known accepted messages most similar to mi • Current implementation: Weka Euclidean Distance • Derive most problematic field in mi and replace it with the corresponding field in mc
Experiments REGISTER message headers Using a commercial SIP proxy server (from a major Austrian telecom equipment provider): guaranteed to work with two hard phones and one soft phone First experiments: monitoring of nine most popular hard phones Example findings: one hard phone A uses less than 10 header fields, phone B uses 15 header fields; the header field also differed Second experiments Artificial messages (random combinations of observed SIP header fields, header field values, and header field parameters from observed hard phones and additional from RFC 3261) 344 different REGISTER message headers (78 rejected; ~22.67%)
Training and Test Sets Training data set Accepted messages: 39 / 78% Rejected messages: 11 / 22% Total number: 50 Test data set Accepted messages: 227 / 77.21% Rejected messages: 67 / 22.79% Total number: 294 Experiment: 15 replicated experimental runs (4400 messages per run chosen at random from test data); training after each 20 messages
Rejection Rate Observed over Time Rejection ratio of overlapping bins of 100 messages (1-100, 21-120, etc.), smoothing and calculating the mean and 90% confidence interval
Redials over Time Assuming phones that redial after a rejection r times Experiments: training and test phase (15 runs) Results: r is best set to 4/5 – increasing does not lead to better result
Analysis of Babel-SIP Behavior • Mean aggregated over all 15 runs • Rejection of previously accepted messages • Unacceptable behavior • Additional experiments: 14 hard -, 5 soft phones • and 227 test messages (known to be accepted) • None of these messages was rejected
Qualitative Insights Example REGISTER C4.5 tree gives good insights (e.g., for not so well trained protocol newbies): top down / bottom up CSeq is mandatory parameter (as defined in RFC 3621) CallID mandatory
Conclusions and Future Work • Babel-SIP: automatic, self-learning SIP-message translator • Generic approach --> can be applied to other protocols • Important for the transient phase between creating a new SIP stack and final release of a 100% reliable new proxy • Experiments with REGISTER message header rate of rejected message could be nearly halved (22.67% to 13.12%) • So far: we did not include the semantics of the header fields - first idea: take a rule based approach • Investigate other SIP message types (INVITE) • Extend the approach to other application protocols, like HTTP or RTSP
Thank you ! … Announcement: