ascii is the king might of ancient interface methods jiri kuthan, iptel.org sip:[email protected]

ASCII is the King

Might of Ancient Interface Methods

Jiri Kuthan, iptel.orgsip:[email protected]

Jiri Kuthan, SIP2003, January 2003, Paris

Outline

• Revisiting APIs/Interfaces: History, benefits, properties

• Efficiency Requirements

• Proposal: Use ASCII Interfaces

• Design Arguments

• Conclusions


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


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…


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.


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.


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.


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


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


Case I: Servers Use Applications• Example: unconditional forwarding: proxy server rewrites request

URI from [email protected] to [email protected]• 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

mailto:[email protected]


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 (voicemail, 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: 404Not Found

SIP: forwardrequest

Done

no

Begin


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 expressionif (!search(“From:.*iptel\.org”){ # verify credentials if (!proxy_authorize( “iptel.org”, “subscriber”)) { # challenge if credentials poor proxy_challenge(“iptel.org”); break; }}


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 usersif (!lookup(“location”)) { /* log(“missed call”); */ exec_msg(“/tmp/notify.sh”);}

# shell script: send email # notification

MAILTO=`user2email $SIP_USER`printf “User %s called” \ “$SIP_HF_FROM” | mail –s “Missed Call” $MAILTO

INVITE

2

2

404


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


Example: Contact Maintenance

Web application can show, add and delete user contacts stored in server’s memory.


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

gatewayuser

locationdigest

authentication

Plug-in modules with exported features

In addition to its normalSIP operation, SIP Server actsas “application rendez-vouspoint”

Weather notification

Webprovisioning

Server healthwatching

FIFO interface


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:replylocation # (table name)jiri # (username in address of record)sip:[email protected] # (new contact)3600 # (expiration time)0.5 # (priority)

200 OK # (status code)

SIPServer


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.


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


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" ]

thencat > $SER_FIFO << EOF

:t_uac_from:nullMESSAGEsip:[email protected]:[email protected]: text/plainContact: sip:[email protected]

weather alert: Very strong winds in the area: $speed

.

EOFfi


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


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


Information Resources

• Email: [email protected]

• IP Telephony Information: http://www.iptel.org/info/

• SIP Services: http://www.iptel.org/user/

• SIP Express Router: http://www.iptel.org/ser/


http://www.iptel.org/info/

http://www.iptel.org/user/

ascii is the king might of ancient interface methods jiri kuthan, iptel.org sip:[email protected]

Documents

apis slide

paris api promise

new applications

porting applications

paris proposals

java servlet api

efficiency divide

efficiency developers