ASCII is the King

1
ASCII is the King

• Might of Ancient Interface Methods
• Jiri Kuthan, iptel.org
• sipjiri_at_iptel.org

2
Outline

• Revisiting APIs/Interfaces History, benefits,
  properties
• Efficiency Requirements
• Proposal Use ASCII Interfaces
• Design Arguments
• Conclusions

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 DC Principle APIs

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

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.

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.

7
Efficiency Requirements

• Simplicity the promise of APIs is to make
  application developers 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 programmers 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.

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

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

10
Case I Servers Use Applications

• Example unconditional forwarding proxy server
  rewrites request URI from sales_at_example.com to
  john_at_example.com
• Request processing and routing is SIPs 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.orgs 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

11
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

• SER Routing Language
• / user online ? /
• if (lookup(location))
• t_relay()
• break
• if (methodINVITE)
• / report to syslog /
• log(ACC missed call\n)
• sl_send_reply(404,Not Found)

INVITE request?
no
User Online?
no
yes
yes
Report Missed Call
SIP forward request
SIP 404 Not Found
Done
12
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 UNX
  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

13
Exec Module Link to More Apps
2

• Exec module starting external applications on
  request receipt (similar to but simpler than SIP
  CGI-BIN)
• Features
• ability to use existing UNX 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, applications output evaluated as new
  requests URI (e.g., unconditional forwarding)

INVITE
404

• SER script execute an external
• command for off-line users
• if (!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
2
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 users
  privileges)
• Run-time reconfiguration (e.g., introducing a new
  domain)
• Command-line tools
• Send a scheduled instant message

15
Example Contact Maintenance
Web application can show, add and delete user
contacts stored in servers memory.
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
SMS gateway
user location
digest authentication
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_addreply location (table name) jiri
(username in address of record) sip7271_at_gw.iptel.
org (new contact) 3600 (expiration time) 0.5
(priority)
Request pipe
SIP Server
Response pipe
200 OK (status code)
18
Example Use of FIFO from Web/PHP

• Appending a contact from a PHP script
• / construct FIFO command /
• fifo_cmd"ul_add".config-gtreply_fifo_filename.
  "\n".
• config-gtul_table."\n". //table
• user_id."\n". //username
• sip_address."\n". //contact
• expires."\n". //expires
• config-gtul_priority."\n\n" //priority
• replywrite2fifo(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

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

• Jiris 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 sers FIFO interface

21
Legacy Recycling Weather Example

• Textual stdin/stdout interface well established
  in the world of UNX 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
• speedecho measure cut -d\ -f1 sed -e
  's/\.//'
• if "speed" -gt "max_speed"
• then
• cat gt SER_FIFO ltlt EOF
• t_uac_fromnull
• MESSAGE
• sipweather_at_iptel.org
• sipreceiver_at_iptel.org
• Content-Type text/plain
• Contact sipweather_at_iptel.org
• weather alert Very strong winds in the area
  speed
• .
• EOF
• fi

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

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
  scriptsmodulesexec)
• Applications leveraging SIP servers (modulesFIFO
  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 UNIX tools and applications
• Dynamic linking and flexible parameterization,
  that provides extensibility
• Portability

24
Information Resources

• Email jiri_at_iptel.org
• IP Telephony Information http//www.iptel.org/inf
  o/
• SIP Services http//www.iptel.org/user/
• SIP Express Router http//www.iptel.org/ser/