ASCII is the King by aax58232


									   ASCII is the King

Might of Ancient Interface Methods

    Jiri Kuthan,
• Revisiting APIs/Interfaces: History, benefits,
• 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-
   – 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
 Enhanced SIP (JES), Java Servlet API,
… and numerous proprietary interfaces…

          Jiri Kuthan, SIP2003, January 2003, Paris
       API Promise: Efficiency
• Developers can focus on applications and
  avoid burning manpower in stack
• 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
• 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)
    –       We argue remote property is NOT needed for use in
            SIP applications – distributiveness already provided by
            SIP and adding an RPC protocol just increases
•         Relationship between server and applications:
    I.      Servers use applications (e.g., a proxy server uses an
            external least-cost routing application to determine
    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
• Existing IETF Technologies for definition of request-processing
   – CGI-BIN – administrator grade, textual in/out
   – CPL – user grade, predefined XML actions
• Non-IETF Standards: Java Servlets
•’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

                     Jiri Kuthan, SIP2003, January 2003, Paris
                         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
                                             SER Routing Language
                 no                     no   /* user online ? */
 User Online?         INVITE request?        if (lookup(“location”)) {
         yes                      yes             break;
                         Report              };
                        Missed Call          if (method==“INVITE”) {
                                                  /* report to syslog */
  SIP: forward           SIP: 404                 log(“ACC: missed call\n”);
    request             Not Found            };
                                             sl_send_reply(“404”,”Not Found”);
             Extensibility: Modules
• MUST requirement: ability           #   SER script: challenge any user
  to add new service                  #   claiming our domain in From header
                                      #   field; good anti-spam practise; it
                                      #   uses module actions for RegExp and
• Answer: Linking SER                 #   digest authentication
  routing scripts to external
  modules, that export                # apply a regular expression
                                      if (!search(“From:.*iptel\.org”)
  additional functionality            {
• Existing modules: RADIUS               # verify credentials
  accounting, SMS support,               if (!proxy_authorize(
  digest authentication,                       “subscriber”)) {
  regular expressions, jabber               # challenge if credentials poor
  gateway, etc.                             proxy_challenge(“”);
• exec module links textual              }
  SIP messages to UN*X                }
                 Jiri Kuthan, SIP2003, January 2003, Paris
   Exec Module – Link to More Apps
• Exec module: starting external                                   2
  applications on request receipt;
  (similar to but simpler than SIP                        INVITE
• Features:
   – ability to use existing UN*X                 # SER script: execute an external
     tools (mail, sed & awk,                      # command for off-line users
                                                  if (!lookup(“location”)) {
     wget, …)                                        /* log(“missed call”); */
   – Language-independency                           exec_msg(“/tmp/”);
• Interface:
   – Request URI and header fields                # shell script: send email
     passed as environment variables to           # notification
     the applications
   – Whole request passed on standard             MAILTO=`user2email $SIP_USER`
     input                                        printf “User %s called” \
                                                    “$SIP_HF_FROM” |
   – Optionally, application’s output               mail –s “Missed Call” $MAILTO
     evaluated as new request’s URI
     (e.g., unconditional forwarding)
                      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
      • Could not be done easily via a back-end database if cached by SIP
   – “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
                                           Weather              Web              Server health
• Design ideas:                            notification         provisioning     watching
   – Register new logic from plug-
     in modules with SIP server
   – Export the logic to
     applications through a textual                                   FIFO interface
     request-response FIFO
     interface (named pipes)                                   In addition to its normal
                                                               SIP operation, SIP Server acts
• FIFO server properties                                       as “application rendez-vous
   – Server looks like a file to                               point”
     application – any file-based                Plug-in modules with exported features
     application can use it
   – Excellent portability
   – Simple and extensible
   – Application isolation                              digest              user        SMS
                                                    authentication        location     gateway
                    Jiri Kuthan, SIP2003, January 2003, Paris
   FIFO Use Example: Adding a New
• Adding contacts useful for
  linking address of record
  with static contacts, such as             :ul_add:reply
  PSTN destinations                         location # (table name)
                                            jiri # (username in address of record)
• User location module             # (new contact)
  exports FIFO action for                   3600 # (expiration time)
  adding new contacts                       0.5 # (priority)

                                    Request pipe
                                            Response pipe

                                                             200 OK # (status code)

                 Jiri Kuthan, SIP2003, January 2003, Paris
Example: Use of FIFO from Web/PHP
• Appending a contact from a PHP script
/* construct FIFO command */
   $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
    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
• 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                    measure=`./wx200d-1.2/wx200
  interface well established in              --gust --C`
  the world of UN*X                       speed=`echo $measure | cut -d\ -f1
                                             | sed -e 's/\.//' `
  applications.                           if [ "$speed" -gt "$max_speed" ]
• Examples:                                  then
                                                  cat > $SER_FIFO << EOF
   – cron daemon for scheduled            :t_uac_from:null
     calls                                MESSAGE
   – awk for database processing
   – PHP for web applications   
   – shell scripts for command-           Content-Type: text/plain
     line tools                           Contact:
   – wx2000 for weather forecasts         weather alert: Very strong winds in
                                            the area: $speed
• Note:                                   .
   – Applications SIP-unaware             EOF
   – Application code simple              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
• 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
• 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
• Email:
• IP Telephony Information:
• SIP Services:
• SIP Express Router:

            Jiri Kuthan, SIP2003, January 2003, Paris

To top