ASCII is the King

1. ASCII is the King Might of Ancient Interface Methods Jiri Kuthan, iptel.org sip:jiri@iptel.org

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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: • Servers use applications (e.g., a proxy server uses an external least-cost routing application to determine next-hop) • Applications use servers (e.g., an application uses a SIP server to initiate an instant message) -  Both Useful Jiri Kuthan, SIP2003, January 2003, Paris

9. 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

10. Case I: Servers Use Applications • Example: unconditional forwarding: proxy server rewrites request URI from sales@example.com to john@example.com • 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 Jiri Kuthan, SIP2003, January 2003, Paris

11. 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”); Routing Language • Request routing flexibility needed to link SIP components (voicemail, PSTN gateway, logging facility, etc.) together • Answer: request routing language (features conditions, URI-rewriting, request modification, replying, etc.) • Example: reporting missed calls Begin INVITE request? no User Online? no yes yes Report Missed Call SIP: forward request SIP: 404 Not Found Done

12. 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; } } Extensibility: Modules Jiri Kuthan, SIP2003, January 2003, Paris

13. 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”); } Exec Module – Link to More Apps 2 INVITE 404 # shell script: send email # notification MAILTO=`user2email $SIP_USER` printf “User %s called” \ “$SIP_HF_FROM” | mail –s “Missed Call” $MAILTO 2 Jiri Kuthan, SIP2003, January 2003, Paris

14. 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

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

16. Our Proposal: Use ASCII Interface Connected via a FIFO Pipe Weather notification Web provisioning Server health watching • 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 FIFO interface In addition to its normal SIP operation, SIP Server acts as “application rendez-vous point” Plug-in modules with exported features digest authentication user location SMS gateway Jiri Kuthan, SIP2003, January 2003, Paris

17. 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 :ul_add:reply location # (table name) jiri # (username in address of record) sip:7271@gw.iptel.org # (new contact) 3600 # (expiration time) 0.5 # (priority) Request pipe SIP Server Response pipe 200 OK # (status code) Jiri Kuthan, SIP2003, January 2003, Paris

18. 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 Jiri Kuthan, SIP2003, January 2003, Paris

19. 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.

20. 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

21. 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 sip:weather@iptel.org sip:receiver@iptel.org Content-Type: text/plain Contact: sip:weather@iptel.org weather alert: Very strong winds in the area: $speed . EOF fi Legacy Recycling: Weather Example Jiri Kuthan, SIP2003, January 2003, Paris

22. 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

23. 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

24. Information Resources • Email: jiri@iptel.org • IP Telephony Information: http://www.iptel.org/info/ • SIP Services: http://www.iptel.org/user/ • SIP Express Router: http://www.iptel.org/ser/ Jiri Kuthan, SIP2003, January 2003, Paris