RFC 2824

Call Processing Language Framework and Requirements

📅 published May 2000, from ietf

RFC 2824: Call Processing Language Framework and Requirements 🦋

Network Working Group: this one lives in the Network Working Group 🌸 Authors: J. Lennox and H. Schulzrinne, both from Columbia University 🎀 Category: Informational (this is info, not a standard, so no pressure 💅) Date: May 2000 ⭐ Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💖

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌈

okay so a LOT of the services we want for Internet telephony need pretty elaborate combos of signalling operations, and those often happen inside network devices 😭 we want a simple, standardized way to build these so they're easier to implement and deploy 🧚 this doc lays out an architectural framework for that mechanism, which we call a call processing language. it also outlines the requirements for such a language 💜

Table of Contents 🍓

1        Introduction ........................................    2
2        Terminology .........................................    3
3        Example services ....................................    4
4        Usage scenarios .....................................    6
5        CPL creation ........................................    6
6        Network model .......................................    7
6.1      Model components ....................................    7
6.1.1    End systems .........................................    7
6.1.2    Signalling servers ..................................    8
6.2      Component interactions ..............................    8
7        Interaction of CPL with network model ...............   10
7.1      What a script does ..................................   10
7.2      Which script is executed ............................   11
7.3      Where a script runs .................................   12
8        Creation and transport of a call processing
         language script .....................................   12
9        Feature interaction behavior ........................   13
9.1      Feature-to-feature interactions .....................   13
9.2      Script-to-script interactions .......................   14
9.3      Server-to-server interactions .......................   15
9.4      Signalling ambiguity ................................   15
10       Relationship with existing languages ................   15
11       Related work ........................................   17
11.1     IN service creation environments ....................   17
11.2     SIP CGI .............................................   17
12       Necessary language features .........................   17
12.1     Language characteristics ............................   17
12.2     Base features -- call signalling ....................   19
12.3     Base features -- non-signalling .....................   21
12.4     Language features ...................................   22
12.5     Control .............................................   23
13       Security Considerations .............................   23
14       Acknowledgments .....................................   23
15       Authors' Addresses ..................................   23
16       Bibliography ........................................   24
17       Full Copyright Statement ............................   25

1 Introduction ✨

okay so recently, a bunch of protocols were created so phone calls could be made over IP networks, most notably SIP [1] and H.323 [2] 📞 these emerging standards have opened the door to a huge, dramatic decentralization of how telephone services get set up, so they can be under the user's control 👑

Lots of Internet telephony services can, and honestly should, be built entirely on end devices 💅 multi-party calls, call waiting alert tones, and camp-on services all depend heavily on end-system state and on the specific content of the media streams, which is info that often only the end system has 🙈 BUT a bunch of other services (the ones about user location, call distribution, behavior when end systems are busy, and stuff like that) don't depend on one particular device, or they need to keep working even when a device is unavailable 😭 those are still best located in a network device, not an end system 🌸

Traditionally, network-based services were only created by service providers 😤 building them usually meant using proprietary or restricted tools, so there was very little room for customization or enhancement by end users. In the Internet environment, though, this totally changes ✨ global connectivity and open protocols let end users or third parties design and implement new or customized services, and deploy and modify them dynamically without needing a service provider to act as a middleman 🦋

A number of Internet applications already have customization environments, like the web with CGI [3], or e-mail with Sieve [4] or procmail 💌 to make an equally open customization environment for Internet telephony, we need a standardized, safe way for these new service creators to describe how they want network servers to behave 🔥

This document describes an architecture where network devices respond to call signalling events by triggering user-created programs. Those programs are written in a simple, static, non-expressively-complete language, and we call that language a call processing language 🎀

The development of this document was heavily influenced by one particular call processing language, described in [5] 🧚 in general, when this document says "a call processing language," it means a generic language that fills this role. "the call processing language" or "the CPL" refers to that one specific language 💖

2 Terminology 📖

Okay, let's get the vocab down, bestie 🫶 this section defines some of the terminology used in the document.

SIP [1] terms used here include:

  • invitation: The initial INVITE request of a SIP transaction, which is how one party starts a call with another 📨
  • redirect server: A SIP device that responds to invitations and other requests by telling the request originator about an alternate address the request should be sent to 🦋
  • proxy server: A SIP device that receives invitations and other requests and forwards them to other SIP devices. It then receives the responses to the requests it forwarded, and passes them back to the sender of the original request 🔁
  • user agent: A SIP device that creates and receives requests, so it can set up a call or otherwise change a call's state. This could be a telephone or a voicemail system, for example 📱
  • user agent client: The part of a user agent that initiates requests 🚀
  • user agent server: The part of a user agent that responds to requests 🌷

H.323 [2] terms used here include:

  • terminal: An H.323 device that originates and receives calls, along with their associated media 🎧
  • gatekeeper: An H.323 entity on the network that provides address translation and controls access to the network for H.323 terminals and other endpoints. A gatekeeper may also provide other services to the endpoints, like bandwidth management and locating gateways 🚪
  • gateway: A device that translates calls between an H.323 network and another network, typically the public-switched telephone network 🌉
  • RAS: The Registration, Admission and Status messages exchanged between two H.323 entities, for example between an endpoint and a gatekeeper 📋

General terms used in this document include:

  • user location: The process by which an Internet telephony device figures out where a user named by a particular address can be found 📍
  • CPL: A Call Processing Language, which is a simple language for describing how Internet telephony call invitations should be processed 🧚
  • script: A particular instance of a CPL, describing a particular set of desired services 📜
  • end system: A device from which and to which calls are established. It creates and receives the call's media (audio, video, or the like). This may be a SIP user agent or an H.323 terminal 💜
  • signalling server: A device that handles routing of call invitations. It does not process or interact with the media of a call. It may be a SIP proxy or redirect server, or an H.323 gatekeeper 🛣️

3 Example services 🎀

To set the scene, this section gives some specific examples of services we want users to be able to create programmatically 💅 some of these examples are deliberately a bit complicated, so you can see how much decision logic should be possible 🧠

  • Call forward on busy/no answer 📞 When a new call comes in, it should ring at the user's desk telephone. If that line is busy, the call should always be redirected to the user's voicemail box. If there's no answer after four rings, it should also go to his or her voicemail, unless it's from a supervisor. In that case, it should be proxied to the user's cell phone if the cell phone is currently registered. the drama is real 😭
  • Information address 💁 A company advertises a general "information" address for prospective customers. When a call comes in to this address and it's currently working hours, the caller should be given a list of the people who are currently willing to accept general information calls. If it's outside working hours, the caller should get a webpage showing what times they can call. 🕘
  • Intelligent user location 🗺️ When a call comes in, the list of locations where the user has registered should be checked. Depending on the type of call (work, personal, etc.), the call should ring at an appropriate subset of the registered locations, based on the info in those registrations. If the user picks up from more than one station, each pick-up should be reported back separately to the calling party 🙌
  • Intelligent user location with media knowledge 🎞️ When a call comes in, the call should be proxied to the station the user has registered from whose media capabilities best match those specified in the call request. If the user doesn't pick up from that station within four rings, the call should be proxied to the other stations they've registered from, one at a time, in order of decreasing closeness of match 🔍
  • Client billing allocation -- lawyer's office ⚖️ When a call comes in, the calling address is matched to the corresponding client, and the client's name, address, and the time of the call are logged. If no corresponding client is found, the call is forwarded to the lawyer's secretary 📒

4. Usage scenarios ✨

okay so a CPL would be super useful for building services in a bunch of different situations 💅

  • Script creation by end user 💖 The most direct move is when the end user writes the script themselves. They decide what service they want, describe it in a CPL script, and upload it to a server 🎀
  • Third party outsourcing 🦋 Since CPL is a standardized language, third parties can create or customize services for their clients. The scripts can then run on servers owned by the end user or the user's service provider 👑
  • Administrator service definition 🔥 Server admins can use a CPL to make simple services or write policy for the servers they run. If a server already runs CPL services, letting admins write scripts as well as users is a pretty easy add-on 💜
  • Web middleware 🌈 There have been lots of ideas for making services through web interfaces. A CPL could be the back-end for those setups: a web app builds a CPL script for a user, and the telephony server runs the services. Neither side needs to know the details of the other 🫶

5. CPL creation

ngl there are a few different ways CPL scripts could get made 🧚 Kinda like how HTML can be made in lots of ways, we picture several creation styles for CPL scripts.

  • Hand authoring ✍️ The most direct route is writing scripts by hand, if you're a knowledgeable user. The CPL described in [5] has a text format with a simple syntax, so hand authoring will be straightforward 🌸
  • Automated scripts 🤖 CPL features can be generated automatically, like in the web middleware example from the last section. Because the syntax is simple and text-based, standard text-processing languages can create and edit CPL scripts with ease 💖
  • GUI tools 🖱️ Finally, users can use GUI tools to create and edit CPL scripts. We expect most average users to go this route once CPL gets popular. The language is being designed with this in mind, so the full expressive power of scripts can be shown simply and clearly in a graphical way ✨

6. Network model

The Call Processing Language works with a generalized model of an Internet telephony network 🦋 The details of each protocol are different, but at a high level all the major Internet telephony architectures are similar enough that their main features can be described together. This document mostly uses SIP terminology, because the authors have mostly worked with that protocol 💅

6.1. Model components

okay so in CPL's network model, an Internet telephony network has two kinds of components 🎀

6.1.1. End systems

End systems are devices that originate and/or receive signalling information and media 📞 That includes simple and complex phones, PC telephony clients, and automated voice systems. CPL doesn't care about the details of what these devices can do. An end system can start a call, and it can accept, reject, or forward incoming calls. How all that happens (ringing, multi-line phones, and so on) doesn't matter to CPL 🙈

For CPL, gateways are also end systems. An example is a device that connects calls between an IP telephony network and the PSTN 🌉 Other devices, like mixers or firewalls, aren't directly handled by CPL, and they won't be covered here 💀

6.1.2. Signalling servers

Signalling servers are devices that relay or control signalling information 🧠 In SIP they're proxy servers, redirect servers, or registrars. In H.323 they're gatekeepers.

Signalling servers can do three things with call setup information. They can:

  • proxy it: forward it on to one or more other network or end systems, returning one of the responses received.
  • redirect it: return a response telling the sending system a different address to send the request to.
  • reject it: tell the sending system that the setup request couldn't be completed.

RFC 2543 [1] has illustrations of proxy and redirect behaviour 📚 End systems can also do some of these actions too: rejection is almost certainly possible, and redirection maybe 🌷

Signalling servers also usually keep track of where users are 📍 Whether that comes from registrations (SIP REGISTER or H.323 RAS messages), static configuration, or dynamic searches, signalling servers must have some way of working out where a user is right now, so they can make smart choices about proxying or redirecting 💜

Signalling servers are also usually able to keep logs of the transactions that pass through them, and to send e-mail to destinations on the Internet, under programmatic control 📧

6.2. Component interactions

When an end system places a call, the setup request can take all kinds of routes through the network 🛣️ First, the originating end system has to decide where to send its requests. There are two options: the originator may be set up so that all its requests go to one local server, or it may resolve the destination address to find a remote signalling server or end system and send the request straight there 🎯

Once the request reaches a signalling server, that server uses its user location database, its local policy, DNS resolution, or other methods to figure out the next signalling server or end system to send it to 🧭 A request may pass through any number of signalling servers, from zero (when end systems talk directly) all the way up to, in principle, every server on the network 🌍 Also, any end system or signalling server can (in principle) receive requests from, or send them to, any other one 🤝

Here's an example using figure 1, which shows two paths the call setup request might take 🗺️ For Route 1, the originator only knows a user address for the person it's trying to reach, and it's set up to send outgoing calls through a local outgoing proxy server. So it forwards the request to its local server, which finds the server of record for that address and forwards it on to that server 📬

In this case, the organization the destination user belongs to uses a multi-stage setup to find users 🏢 The corporate server works out which department the user is in, then forwards the request to the right departmental server, which actually finds the user. (It's kind of like how e-mail forwarding is often set up 📨) The response travels back along the same path.

For Route 2, the originator knows the specific device address it's trying to reach, and it isn't set up to use a local outgoing proxy 🎯 Here, the originator can contact the destination directly, without talking to any network servers at all 🦋

So signalling servers in Internet telephony generally can't know the state of the end systems they "control," because signalling information may have skipped right past them 🙃 That architectural limitation puts some restrictions on how certain services can be built. For example, a network system can't reliably tell whether an end system is busy, since a call may have been placed to that end system without going through the network system 📵 So signalling messages have to travel to end systems explicitly to find out their state. In the example, the end system must explicitly send back a "busy" indication 📣

      Outgoing                           Corporate        Departmental
        Proxy                              Server            Server
       _______  Outgoing proxy contacts   _______            _______
       |     |     corporate server       |     |            |     |
       |     | -------------------------> |     | ---------> |     |
       |_____|                            |_____|            |_____|
Route 1   ^                                                    \Searches
         /                                                      \   for
Sends to/                                                        \ User
 proxy /                                                         _|
   _______                                                      _______
   |     |   Route 2                                            |     |
   |     | ---------------------------------------------------> |     |
   |_____|      Originator directly contacts destination        |_____|

  Originator                                                 Destination

         Figure 1: Possible paths of call setup messages

7. Interaction of CPL with network model ✨

7.1. What a script does

okay so a CPL script runs inside a signalling server 💻 It controls that system's proxy, redirect, or rejection actions for setting up one particular call. It doesn't try to coordinate multiple signalling servers, and it doesn't describe features on a "Global Functional Plane" like the Intelligent Network architecture does [6] 🙅‍♀️

More specifically, a script replaces the user location part of a signalling server 🔄 As mentioned in section 6.1.2, a signalling server normally keeps a database of places where a user can be reached, and it bases its proxy, redirect, and rejection decisions on what's in that database. A CPL script takes over this basic database lookup: it takes the registration information, the details of the call request, and any other external information it wants to look at, and then picks the signalling actions to perform 🧚‍♀️

Basically, a script can be thought of as a list of condition/action pairs 📋 If some attribute of the registration, request, or external information matches a given condition, the matching action (or, more accurately, set of actions) is taken. In some cases, extra actions can be taken based on what happened after the first action, plus additional conditions 🔥 If no condition matches the invitation, the signalling server's standard action runs instead, such as its location database lookup 💖

7.2. Which script is executed 💅

okay so CPL scripts are usually tied to one specific Internet telephony address 📞✨. When a call setup request lands on a signalling server that's a CPL server, that server checks the source and destination addresses in the request against its database of CPL scripts. If one matches, that script runs 🎀.

Once the script has run, if it chose a proxy action, a brand new Internet telephony address becomes the destination of that proxying 🦋. The server then checks its database again to see if any scripts are tied to the new address. If one is, that script runs too 💖, as long as no script has tried to proxy to an address the server already tried 🙅‍♀️. For the full scoop on this recursion, plus what happens when a server has scripts for both the origination address and the destination address, check out section 9.2 🧚.

Now, in general, an address in an Internet telephony network is one of two things 🌸: a user or a device. A user address refers to a particular person, like sip:joe@example.com, no matter where they are or what device they're using 💜. A device address points to one physical device, like sip:x26063@phones.example.com 📱. There are also in-between addresses that are kinda useful, like "my cell phone, wherever it's currently registered" 🍓. We don't expect those to show up much though 🙈.

A CPL script doesn't care what type of address it's tied to 💅. Scripts on user addresses are probably the most useful for most services, but nothing stops a script from being tied to any other type of address too ✨. The recursion process lets scripts sit on several of a user's addresses. So a user script could say "try me at my cell phone," while a device script could say "I don't want to accept cell phone calls while I'm out of my home area" 🏠💀.

It's also possible for a CPL script to be tied not to one address, but to every address a signalling server handles, or a big set of them 🌈. Picture an administrator blocking calls to or from a list of banned addresses 🚫. Those scripts would presumably be set up for everyone, but users should still be able to have their own custom scripts too 🫶. Exactly when an admin script runs during recursion depends on what that admin script actually does 🤔. See section 9.2 for more on that.

7.3. Where a script runs 🌟

Users can keep CPL scripts on any network server their call setup requests pass through, as long as they have a trust relationship with that server 🤝. For example, in the figure 1 setup, the originating user could have a script on the outgoing proxy 📤. The destination user could have scripts on both the corporate server and the departmental server 🏢. These scripts would usually do different jobs based on what role their server plays 👑. A script on the corporate-wide server could handle which department the user wants to be found at 🗂️, while a script on the departmental server could handle more fine-grained location stuff 🎯. Some services, like filtering out unwanted calls, could live on either server 🚫📞. See section 9.3 for some implications of this kind of setup 🧐.

This model doesn't say how users find a CPL-capable network server 🔍. Usually it's the same way they'd find a local Internet telephony server to register with 💌. That could be manual configuration, or automated stuff like the Service Location Protocol [7] 🤖. People have proposed that automated discovery should include a field saying whether the server lets users upload CPLs 🙌.

8. Creation and transport of a call processing language script ✍️

Users create CPL scripts, usually on end devices, then send them through the network to signalling servers 💻➡️🖥️. Scripts stick around on signalling servers until someone changes or deletes them, unless they were given an expiration time ⏳. So a network system that supports CPL scripting will need stable storage 💾.

The end device where a user creates a CPL script doesn't have to be related to the end devices where calls actually land 📱🎧. For example, a script could get made on a PC, while calls are meant to ring on a basic audio-only phone ☎️. Honestly, the device where the script gets created might not even count as an "end device" in the sense of section 6.1.1 💀. A user could create and upload a script from a non-multimedia-capable web terminal 🖥️💅.

The CPL also doesn't have to be made on a device that's close to the end device or the signalling server, network-wise 🗺️. For example, someone might decide to forward their calls to a remote location only after they've already arrived there ✈️🌸.

How the end device actually sends the script to the server is still to be determined 🔮. It's likely that lots of solutions will be able to co-exist 🌈. This method will need authentication in almost all cases 🔐. The suggested methods include web file upload, SIP REGISTER message payloads, remote method invocation, SNMP, ACAP, LDAP, and remote file systems like NFS 📂✨.

Users can also pull their current script from the network down to an end system so they can edit it ✏️. The signalling server should also be able to report script errors back to the user 🚨. That covers both static errors that could be caught at upload time, and run-time errors that happen while the script is running 🏃‍♀️💥.

If a user has trust relationships with multiple signalling servers (as discussed in section 7.3), they can upload scripts to any or all of them 🫧. Those scripts can be totally independent of each other 🦋.

9. Feature interaction behavior 🔥

Feature interaction is the term telephony folks use when two or more requested features produce ambiguous or conflicting behavior [8] 😵‍💫. For features built with a call processing language, feature interaction issues fall into roughly three categories 📚: feature-to-feature in one server, script-to-script in one server, and server-to-server 🧩.

9.1. Feature-to-feature interactions 🎀

Because of how explicit the event conditions are (we covered that in the previous section 🤓), feature-to-feature interaction isn't likely to be a problem in a call processing language environment 🙌. Picture a traditional phone subscriber who might unthinkingly sign up for both "call waiting" and "call forward on busy" 📞. In CPL, a user creating a script could only trigger one action for the condition "a call arrives while the line is busy" 🙅‍♀️. Add a good user interface for creation, or a CPL server that can check uploaded scripts for unreachable code 🔍, and contradictory condition/action pairs can be avoided 💖.

9.2. Script-to-script interactions 🧚‍♀️

Script-to-script interactions happen when a server runs multiple scripts for a single call, as described in section 7.2 💫. This can happen in a few cases 🌸: if both the call originator and the destination have scripts on a single server; if a script forwards a request to another address that also has a script; or if an administrative script is set up alongside a user's individual script 🛠️.

The fix for this interaction is to decide on an order for the scripts to run in 📋. In that order, the "first" script runs first. If that script allows or permits the call to be proxied, the script for the next address runs 🏃‍♀️. When the first script says to forward the request to some other address, those actions count as new requests that arrive at the second script 📨. When the second script sends back a final response, that response reaches the first script just like it would if a request had arrived over the network 🔄. Forwarding can sometimes be recursive, so a CPL server has to be careful to prevent forwarding loops 🔁🚨.

Conceptually, this is the same as having each script run on its own separate signalling server 🖥️🖥️. The CPL architecture is designed so scripts can run on multiple signalling servers while locating a user, so we can treat script-to-script interactions as the server-to-server interactions in the next section 🧠. That cuts down on the number of interaction types we need to think about 💅.

So the real question is figuring out the right ordering for the scripts 🤔. When a script forwards to an address that also has a script, the ordering is obvious 🙌. The other two cases are a little more subtle 👀. When both the originator's and the destination's scripts exist, the originator's script should run before the destination script 🎯. That lets the originator do address translation, call filtering, and so on, before a destination address is picked and its matching script is chosen 🌟.

Administrative scripts are even more complicated 😭. Lots of admin scripts, like ones that restrict source and destination addresses, need to run after originator scripts but before destination scripts 🚧. Otherwise a user's script could sneakily get around admin restrictions through clever forwarding 🕵️‍♀️. Other admin scripts, like a global address book translation function, would need to run earlier or later 📖. So servers that allow admin scripts need to let the administrator set exactly where in the script execution process each admin script falls ⏰💜.

9.3. Server-to-server interactions

Okay, this one is the spiciest of the three feature interaction types 😭🔥. Server-to-server interactions are the most complex, bestie. The classic example is Originating Call Screening combined with Call Forwarding. Picture this: a user (or an admin) wants to stop calls from going to some specific address 🚫. But the local script has no way of knowing whether a call to some other, totally legit address will get proxied by a remote server over to the banned one 👀. This kind of problem can't be solved in an administratively heterogeneous network, not even a "lightly" heterogeneous one like today's telephone systems 💀. CPL doesn't pretend it can fix this 🫶. Still, the problem isn't any worse for CPL scripts than for any other way of deploying services, so no extra drama there ✨.

Another group of server-to-server interactions is better handled by the underlying signalling protocol 🧚. That's because they can show up whether the signalling servers are driven by a call processing language or by something totally different. A good example is forwarding loops, where user X has calls forwarded to Y, and Y has calls forwarded right back to X 🔁. SIP already has a mechanism to detect these loops 🙌. So a call processing language server doesn't need to invent any special mechanisms to stop them 💅. It should, though, be possible to trigger a different set of call processing actions when a loop is detected, and/or to report an error back to the script's owner through some standardized run-time error reporting mechanism 🌸.

9.4. Signalling ambiguity

As a little aside 🦋, [8] talks about a fourth type of feature interaction in traditional telephone networks: signalling ambiguity. This happens when several features try to use the same operation on the limited signal path from an end station to the network 🤯. For example, flashing the switch-hook could mean either "add a party to a three-way call" or "switch to call waiting" 📞. Thanks to the explicit nature of signalling in both of the Internet telephony protocols discussed here, this issue just doesn't come up 🙌✨.

10. Relationship with existing languages

Quick clarification 💖: calling CPL a "language" doesn't mean a new one has to be built from scratch 🛠️. A server could totally implement all of this as a library or as extensions to an existing language 🧩. Java, or the freely available scripting languages (Tcl, Perl, Python, Guile), are the obvious options 💜.

That said, there are real reasons to make a new language 👑. All the existing ones are expressively complete, and that comes with two big downsides 💀. The first: any function written in them can take forever, eat tons of memory, and may never terminate at all 😱. For call processing, that kind of resource usage probably isn't needed, and as section 12.1 explains, it might even be undesirable 🙅‍♀️. The electronic mail filtering language Sieve [4] is a great model here, since it deliberately avoids being Turing-complete 🌈.

You could get similar safety and protection (though not automatic generation and parsing) with a "sandbox," like the ones Java applets use, where strict limits are placed on memory, CPU time, stack space, and so on 🧱. The catch is that this approach lacks transparency and portability 🫠. Unless the standard imposes the actual limits (and that's a bad idea as long as available resources keep growing exponentially with Moore's Law 📈), a user can never be sure a program will run on a given server without hitting that server's limits 😬. A program might run fine on one server and then fail unexpectedly on another ☹️. Non-expressively-complete languages, on the other hand, create an implicit contract between the script writer and the server 🤝: as long as the script sticks to the rules of the language, the server will guarantee it gets executed 💯.

The second downside of expressively complete languages is that they make automatic generation and parsing of scripts super hard 🥲, because every parsing tool has to be a full interpreter for the language. Think about document creation: text markup languages like HTML or XML can be, and are, easily manipulated by smart editors 🖊️, but powerful document programming languages like LaTeX or Postscript usually can't be 🙈. Some word processors can save their documents in LaTeX form, but they can't accept arbitrary LaTeX documents as input, let alone keep the structure of the original document while editing it 😩. By contrast, basically any HTML editor can edit any HTML document from the web, and the high-quality ones preserve the structure of the original documents as you edit 🎀.

11.1. IN service creation environments

The ITU's IN series describes service creation environments on an abstract level [6] 🧠. These describe services in a traditional circuit-switched telephone network as a series of decisions and actions arranged in a directed acyclic graph 📊. Lots of IN service vendors use modified and extended versions of this for their proprietary service creation environments 🏢.

11.2. SIP CGI

SIP CGI [9] is an interface for implementing services on SIP servers 🖥️. Unlike a CPL, it's a very low-level interface 🔧, so it wouldn't be appropriate for services written by non-trusted users 🚫. If you want the nitty-gritty on the similarities and differences between SIP CGI and CPL, the paper "Programming Internet Telephony Services" [10] goes into more detail 📚🦋.

12. Necessary language features

This section lists the properties we believe a call processing language needs in order to implement the motivating examples, in line with the architecture described earlier 🌟.

12.1. Language characteristics

These are some abstract attributes any proposed call processing language should have 💅.

  • Light-weight, efficient, easy to implement ⚡

A network server might conceivably handle very large call volumes, and we really don't want CPL execution to become a major bottleneck 🚧. One way to achieve this might be to compile scripts before execution 🧃.

  • Easily verifiable for correctness 🔍

For a script running in a server, mis-configurations can leave a user unreachable 😱, and it's hard to report run-time errors to a user (though a second-channel error reporting mechanism such as e-mail could help with this 📧). So it should be possible to verify, when the script is committed to the server, that it's at least syntactically correct, doesn't have any obvious loops or other failure modes, and doesn't use too many server resources 🧐.

  • Executable in a safe manner 🛡️

No action the CPL script takes should be able to subvert anything about the server that the user shouldn't have access to, or affect the state of other users without permission 🙅‍♀️. Also, since CPL scripts will typically run on a server where users can't normally run code, either the language or its execution environment must be designed so scripts can't use unlimited amounts of network resources, server CPU time, storage, or memory 🔒.

  • Easily writeable and parsable by both humans and machines. ✍️

We want humans to be able to write their own scripts, or to use and customize script libraries provided by others 💖. But most users will want a more intuitive user interface for the same functionality, so they'll have a program that creates scripts for them 🪄. Both cases should be easy. In particular, it should be easy for script editors to read human-generated scripts, and vice-versa 🫶.

  • Extensible 🧩

It should be possible to add features to a language in a way that existing scripts keep working, and existing servers can easily recognize features they don't understand and safely inform the user of this fact 🌈.

  • Independent of underlying signalling details 📡

The same scripts should be usable whether the underlying protocol is SIP, H.323, a traditional telephone network, or any other means of setting up calls 🌍. It should also be agnostic to address formats. (We use SIP terminology in our descriptions of requirements, but this should map fairly easily to other systems 🗺️.) It may also be useful to extend the language to process other sorts of communication, such as e-mail or fax 💌📠.

12.2 Base features -- call signalling ✨

okay so, to be actually useful, a call processing language obviously needs to be able to react to call signalling events AND start them itself 📞💖

  • Should execute actions when a call request arrives 🚀

See section 7, particularly 7.1. 🎀

  • Should be able to make decisions based on event properties 🧠

bestie, a bunch of call event properties are relevant for a script's decision process. Roughly in order of importance, they are:

  • Destination address 📍

we want to do destination-based routing or screening. Note that in SIP we want to be able to filter on either or both of the addresses in the To header and the Request-URI. 💅

  • Originator address 🦋

same energy here. we want originator-based screening or routing too, obviously 😌

  • Caller Preferences 💜

in SIP, a caller can express preferences about the type of device they want to be reached on, see [11]. the script should be able to make decisions based on this info, no cap 🔥

  • Information about caller or call 🌸

SIP has textual fields like Subject, Organization, Priority, etc., plus a display name for addresses. users can also add non-standard additional headers, which is so iconic of them 🙈 H.323 has a single Display field. the script should be able to make decisions based on these parameters ✨

  • Media description 🎶

call invitations specify the types of media that will flow, their bandwidth usage, their network destination addresses, etc. the script should be able to make decisions based on these media characteristics. literally the vibe check of the call 💅

  • Authentication/encryption status 🔐

call invitations can be authenticated, and there are a lot of properties of that authentication that matter: the method of authentication/encryption, who performed the authentication, which specific fields were encrypted, etc. the script should be able to make decisions based on these security parameters. security main character era 👑

  • Should be able to take action based on a call invitation 📨

there are a bunch of things we can do when an incoming call setup request shows up. we can:

  • reject it 🚫

we should be able to indicate that the call is not acceptable or not able to be completed. we should also be able to send more specific rejection codes (including, for SIP, the associated textual string, warning codes, or message payload). not me being dramatic about rejection, but we need the receipts 💀

  • redirect it ↪️

we should be able to tell the call initiator sender to try a different location. "try over there bestie" energy 🦋

  • proxy it 🔁

we should be able to send the call invitation on to another location, or to several other locations ("forking" the invitation), and await the responses. it should also be possible to specify a timeout value after which we give up on receiving any definitive responses. we don't wait forever, we have standards 💅⏳

  • Should be able to take action based on a response to a proxied or forked call invitation 📬

once we've proxied an invitation, we need to make decisions based on the responses we get back to that invitation (or the lack of them). we should be able to:

  • consider its message fields 🔍

we should be able to consider the same fields of a response as we consider in the initial invitation. same checks, different day 🫶

  • relay it on to the call originator 📤

if the response is satisfactory, it should be returned to the sender. delivered, slay ✨

  • for a fork, choose one of several responses to relay back 🎭

if we forked an invitation, we obviously expect to receive several responses. there are a couple of issues here: choosing among the responses, and how long to wait if we've received responses from some but not all destinations. the drama is real 😭

  • initiate other actions 🎬

if we didn't get a response, or didn't get any we liked, we should be able to try something else instead (e.g., call forward on busy). plan B is giving main character 🧚

12.3 Base features -- non-signalling 🌈

okay, so there are a bunch of other features a call processing language should have that don't refer to call signalling per se. they're still extremely desirable though, because they unlock lots of useful features 🤩

the servers that provide these features might live in other Internet devices, or be local to the server (or other possibilities). the language should be independent of where these servers are, at least at a high level. location-agnostic and proud 🌍

  • Logging 📝

in addition to the CPL server's natural logging of events, the user will also want to log arbitrary other items. the actual storage for this logging info might live locally or remotely. receipts, always 🧾

  • Error reporting 🚨

if an unexpected error occurs, the script should be able to report it to the script's owner. this may use the same mechanism the script server uses to report language errors to the user (see section 12.5). no silent failures in my world 💅

  • Access to user-location info 📡

proxies will often collect info on users' current location, either through SIP REGISTER messages, the H.323 RRQ family of RAS messages, or some other mechanism (see section 6.2). the CPL should be able to refer to this info, so a call can be forwarded to the registered locations or some subset of them. knowing where everyone is, iykyk 👀

  • Database access 🗄️

a lot of info for CPL control might be stored in external databases, for example a wide-area address database, or authorization info for a CPL under administrative control. the language could specify some specific database access protocols (such as SQL or LDAP), or it could be more generic. both are valid, its giving options 💜

  • Other external information 🌐

other external info a script could access includes web pages, which could be sent back in a SIP message body; or a clean interface to remote procedure calls such as Corba, RMI, or DCOM, for instance to access an external billing database. however, for simplicity, these interfaces may not be in the initial version of the protocol. ngl, we're keeping the first release lean and that's a mood 🌸

12.4 Language features 🧩

some features don't involve any operations outside the CPL's execution environment, but they're still necessary to implement some standard services. (this list is not exhaustive, so don't come for me 🙈)

  • Pattern-matching 🔤

it should be possible to give special treatment to addresses and other text strings based not only on the full string but also on more general or complex sub-patterns of them. pattern recognition is her whole thing 🦋

  • Address filtering 🧹

once a set of addresses has been retrieved through one of the methods in section 12.3, the user needs to be able to choose a sub-set of them, based on their address components or other parameters. curating the list, periodt 💅

  • Randomization 🎲

some forms of call distribution are randomized as to where they actually end up. chaos, but make it organized 🌀

  • Date/time information 🕰️

users may wish to condition some services (e.g., call forwarding, call distribution) on the current time of day, day of the week, etc. timing is everything, bestie ⭐

12.5 Control 🎛️

as described in section 8, we must have a mechanism to send and retrieve CPL scripts, and associated data, to and from a signalling server. this method should support reporting upload-time errors to users; we also need some mechanism to report errors to users at script execution time. authentication is vital, and encryption is very useful. the specification of this mechanism can be (and probably ought to be) a separate specification from that of the call processing language itself. two specs, one vibe, it's giving organized 🗂️🔐

13 Security Considerations 🚨

okay bestie, this part is SERIOUS 😭 the security considerations of transferring CPL scripts are discussed in sections 8 and 12.5. some considerations about the execution of the language are discussed in section 12.1. read those sections like your data depends on it, because it kinda does 🔐💀

14 Acknowledgments 🫶

we would like to thank Tom La Porta and Jonathan Rosenberg for their comments and suggestions. thank you queens 👑✨

15 Authors' Addresses 🖋️

Jonathan Lennox
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA

EMail: lennox@cs.columbia.edu
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA

EMail: schulzrinne@cs.columbia.edu

16 Bibliography 📚

[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

[2] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

[3] K. Coar and D. Robinson, "The WWW common gateway interface version 1.1", Work in Progress.

[4] T. Showalter, "Sieve: A mail filtering language", Work in Progress.

[5] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services", Work in Progress.

[6] International Telecommunication Union, "General recommendations on telephone switching and signaling -- intelligent network: Introduction to intelligent network capability set 1," Recommendation Q.1211, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.

[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[8] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. Schure, and H. Velthuijsen, "A feature interaction benchmark for IN and beyond," Feature Interactions in Telecommunications Systems, IOS Press, pp. 1-23, 1994.

[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway interface for SIP", Work in Progress.

[10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming internet telephony services," Technical Report CUCS-010-99, Columbia University, New York, New York, Mar. 1999.

[11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in Progress.

Okay bestie, time for the legal bit, and yes, it's giving serious. 💅 Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀

So here's the deal. You're allowed to copy this document and share it with other people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those in whole or in part, no restrictions of any kind, as long as the copyright notice and this paragraph are on every copy and every derivative work. 🫶

BUT (and this is a big but 😭) the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are if you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or if you need to translate it into a language other than English. 🌈

The permissions I just listed are perpetual, which means the Internet Society or its successors or assigns can never take them back. Iconic. 👑

Now the disclaimer, which is not as fun but still matters. ✨ This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from