ASCII is the King Might of Ancient Interface Methods Jiri Kuthan, iptel.org

Jiri Kuthan, SIP2003, January 2003, Paris Outline Revisiting APIs/Interfaces: History, benefits, properties Efficiency Requirements Proposal: Use ASCII Interfaces Design Arguments Conclusions

Jiri Kuthan, SIP2003, January 2003, Paris History Lessons Separation of expertise is good for efficiency –Divide and Conquer (“Divide et impera”, Caesar, 100BCE- 44BCE) –Labor Division (Adam Smith: The Wealth of Nations, 1776) “The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgement with which it is any where directed, or applied, seem to have been the effects of the division of labour.” small companies enabled to provide small products getting educated in a small area faster and more effective manpower in a small well-understood area more likely to be made more efficient by deployment of automated machines Software instantiation of the D&C Principle: APIs

Jiri Kuthan, SIP2003, January 2003, Paris Proposals for Use of Interfaces in Multimedia Applications CORBA, CPL, CSTA, CTI, JAIN, Java Enhanced SIP (JES), Java Servlet API, JINI, JTAPI, OSA-PARLAY, SIP CGI- BIN, TAPI, TINA, TOPS, VoiceXML … and numerous proprietary interfaces…

Jiri Kuthan, SIP2003, January 2003, Paris API Promise: Efficiency Developers can focus on applications and avoid burning manpower in stack implementation. Evolution speed higher – incremental upgrade and improvement of separated components easier to deploy. Well-designed API hides protocol and allows porting applications across protocols – convenient for building gateways.

Jiri Kuthan, SIP2003, January 2003, Paris API Problems Language dependence – using API in languages other than designed for difficult. No process isolation – buggy applications can break server. Architectural ties – application must follow server architecture: memory management and parallel processing in particular. Complexity – too long time spent on learning curve.  Other interfacing approaches sought.

Jiri Kuthan, SIP2003, January 2003, Paris Efficiency Requirements Simplicity – the promise of APIs is to make application developer’s life easier. Time spent on learning curve needs to be short. (PHP perceived easier than Java and thus dominating in server apps.) Language-independence – the easiest way to achieve programmer’s familiarity with an API is to export it to his favorite programming language. Attempts to force a Perl geek to use Java unlikely to succeed. (CGI-BIN is an excellent proof of concept.) Legacy recycling – ability to reuse existing application tools essential to efficiency. Extensibility – ability to link new applications with new functionality without rebuilding the system in run-time. Process isolation – make application live in separate space, so that buggy applications cannot crash server. Portability – avoid APIs specific to a platform; later porting it to other platforms very costly.

Jiri Kuthan, SIP2003, January 2003, Paris Interface Design Scope Local versus remote –Some APIs are based on Remote Procedure Call (RPC) mechanisms. –We argue remote property is NOT needed for use in SIP applications – distributiveness already provided by SIP and adding an RPC protocol just increases complexity. Relationship between server and applications: I.Servers use applications (e.g., a proxy server uses an external least-cost routing application to determine next-hop) II.Applications use servers (e.g., an application uses a SIP server to initiate an instant message) -  Both Useful

Jiri Kuthan, SIP2003, January 2003, Paris Review: What We Are Seeking Effective, easy-to-learn, language independent, local application interface that permits bidirectional linking of SIP servers and SIP- unaware applications

Jiri Kuthan, SIP2003, January 2003, Paris Case I: Servers Use Applications Example: unconditional forwarding: proxy server rewrites request URI from to Request processing and routing is SIP’s native way for creation of services. Existing IETF Technologies for definition of request-processing logic: –CGI-BIN – administrator grade, textual in/out –CPL – user grade, predefined XML actions Non-IETF Standards: Java Servlets iptel.org’s SIP Express server: admin-grade concept of –routing language – simple, fast, and covers most important cases –external modules – allow to plug-in new request-processing features as needed

Routing Language SER Routing Language /* user online ? */ if (lookup(“location”)) { t_relay(); break; }; if (method==“INVITE”) { /* report to syslog */ log(“ACC: missed call\n”); }; sl_send_reply(“404”,”Not Found”); Request routing flexibility needed to link SIP components (voic , PSTN gateway, logging facility, etc.) together Answer: request routing language (features conditions, URI- rewriting, request modification, replying, etc.) Example: reporting missed calls User Online? INVITE request? yes no Report Missed Call yes SIP: 404 Not Found SIP: forward request Done no Begin

Jiri Kuthan, SIP2003, January 2003, Paris Extensibility: Modules MUST requirement: ability to add new service functionality Answer: Linking SER routing scripts to external modules, that export additional functionality Existing modules: RADIUS accounting, SMS support, digest authentication, regular expressions, jabber gateway, etc. exec module links textual SIP messages to UN*X applications # SER script: challenge any user # claiming our domain in From header # field; good anti-spam practise; it # uses module actions for RegExp and # digest authentication # apply a regular expression if (!search(“From:.*iptel\.org”) { # verify credentials if (!proxy_authorize( “iptel.org”, “subscriber”)) { # challenge if credentials poor proxy_challenge(“iptel.org”); break; }

Jiri Kuthan, SIP2003, January 2003, Paris Exec Module – Link to More Apps Exec module: starting external applications on request receipt; (similar to but simpler than SIP CGI-BIN) Features: –ability to use existing UN*X tools (mail, sed & awk, wget, …) –Language-independency Interface: –Request URI and header fields passed as environment variables to the applications –Whole request passed on standard input –Optionally, application’s output evaluated as new request’s URI (e.g., unconditional forwarding) # SER script: execute an external # command for off-line users if (!lookup(“location”)) { /* log(“missed call”); */ exec_msg(“/tmp/notify.sh”); } # shell script: send # notification MAILTO=`user2 $SIP_USER` printf “User %s called” \ “$SIP_HF_FROM” | mail –s “Missed Call” $MAILTO INVITE

Jiri Kuthan, SIP2003, January 2003, Paris Case II) Applications Use Server External applications need to access server internals and/or SIP stack Web-applications –User manipulation of their contacts in user location database Could not be done easily via a back-end database if cached by SIP server –“Send Instant Message” – initiate a SIP transaction –Monitoring of server health| Management Applications –User administration (e.g., revoking user’s privileges) –Run-time reconfiguration (e.g., introducing a new domain) Command-line tools –Send a scheduled instant message

Jiri Kuthan, SIP2003, January 2003, Paris Example: Contact Maintenance Web application can show, add and delete user contacts stored in server’s memory.

Jiri Kuthan, SIP2003, January 2003, Paris Our Proposal: Use ASCII Interface Connected via a FIFO Pipe Design ideas: –Register new logic from plug- in modules with SIP server –Export the logic to applications through a textual request-response FIFO interface (named pipes) FIFO server properties –Server looks like a file to application – any file-based application can use it –Excellent portability –Simple and extensible –Application isolation SMS gateway user location digest authentication Plug-in modules with exported features In addition to its normal SIP operation, SIP Server acts as “application rendez-vous point” Weather notification Web provisioning Server health watching FIFO interface

Jiri Kuthan, SIP2003, January 2003, Paris FIFO Use Example: Adding a New Contact Adding contacts useful for linking address of record with static contacts, such as PSTN destinations User location module exports FIFO action for adding new contacts Request pipe Response pipe :ul_add:reply location # (table name) jiri # (username in address of record) # (new contact) 3600 # (expiration time) 0.5 # (priority) 200 OK # (status code) SIP Server

Jiri Kuthan, SIP2003, January 2003, Paris Example: Use of FIFO from Web/PHP Appending a contact from a PHP script /* construct FIFO command */ $fifo_cmd=":ul_add:".$config->reply_fifo_filename."\n". $config->ul_table."\n".//table $user_id."\n".//username $sip_address."\n".//contact $expires."\n".//expires $config->ul_priority."\n\n";//priority $reply=write2fifo($fifo_cmd, $errors, $status); Note: –Few lines of code … it is SIMPLE –The stub function long only less than 40 lines of commented PHP code

Simplicity & Language Independence Programming as easy as printing a request Textual stdin/stdout FIFO interface easily linkable to any programming environment: No binary linking difficulties No dependency on a particular programming language – developers can use what they best understand, including scripting languages Use of scripting languages makes code shorter and takes less time (graphs from [*] demonstrate complexity for a specific problem) (*) Source of both graphs: Lutz Prechelt: “An Empirical Comparison of C, C++, Java, Perl, Python,RXX, and Tcl”, March 2000.

Jiri Kuthan, SIP2003, January 2003, Paris On Windsurfing Jiri’s hobby: windsurfing; cool but loading a van with gear, traveling to a lake, setting up a sale and learning that the wind is gone is frustrating Missing piece: delivering up-to-date local weather information in real-time to users How to engineer that? Use a specialized, sip- unaware, weather forecast linux application and link it to SIP via ser’s FIFO interface

Jiri Kuthan, SIP2003, January 2003, Paris Legacy Recycling: Weather Example Textual stdin/stdout interface well established in the world of UN*X applications. Examples: –cron daemon for scheduled calls –awk for database processing –PHP for web applications –shell scripts for command- line tools –wx2000 for weather forecasts  Note: –Applications SIP-unaware –Application code simple measure=`./wx200d-1.2/wx200 --gust --C` speed=`echo $measure | cut -d\ -f1 | sed -e 's/\.//' ` if [ "$speed" -gt "$max_speed" ] then cat > $SER_FIFO << EOF :t_uac_from:null MESSAGE Content-Type: text/plain Contact: weather alert: Very strong winds in the area: $speed. EOF fi

Jiri Kuthan, SIP2003, January 2003, Paris Extensibility: Add New Features on the Fly Minimizing upgrade overhead during introduction of new features greatly saves development cycles. Application of feature rendezvous principle allows application upgrade without rebuilding server. –New features can be implemented by third parties in new modules, linked to server dynamically and exported to applications. Flexibility in parameterization: FIFO command parameters can be –identified by name –added on demand  upgrades to new feature versions easier while preserving backwards compatibility

Jiri Kuthan, SIP2003, January 2003, Paris Conclusions We demonstrate a traditional way to couple SIP server capabilities with applications using a stdin/stdout interface. Interfaces for two ways proposed: –SIP servers leveraging applications (routing scripts+modules+exec) –Applications leveraging SIP servers (modules+FIFO server) Primary benefit of the proposed interfaces: efficiency of service programming; achieved through: –Language independency, that permits use of popular scripting languages –stdin/stdout textual interface, that allows reuse of numerous UNI*X tools and applications –Dynamic linking and flexible parameterization, that provides extensibility –Portability

Jiri Kuthan, SIP2003, January 2003, Paris Information Resources IP Telephony Information: SIP Services: SIP Express Router: