idnits 2.17.00 (12 Aug 2021) /tmp/idnits28397/draft-ietf-iptel-cpl-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 1999) is 8240 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1018 looks like a reference -- Missing reference section? '2' on line 1022 looks like a reference -- Missing reference section? '3' on line 1027 looks like a reference -- Missing reference section? '4' on line 1031 looks like a reference -- Missing reference section? '5' on line 1034 looks like a reference -- Missing reference section? '6' on line 1038 looks like a reference -- Missing reference section? '7' on line 1044 looks like a reference -- Missing reference section? '8' on line 1049 looks like a reference -- Missing reference section? '9' on line 1053 looks like a reference -- Missing reference section? '10' on line 1057 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IPTEL WG 2 Internet Draft Lennox/Schulzrinne 3 draft-ietf-iptel-cpl-framework-01.txt Columbia University 4 October 22, 1999 5 Expires: April 2000 7 Call Processing Language Framework and Requirements 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 A large number of the services we wish to make possible for Internet 28 telephony require fairly elaborate combinations of signalling 29 operations, often in network devices, to complete. We want a simple 30 and standardized way to create such services to make them easier to 31 implement and deploy. This document describes an architectural 32 framework for such a mechanism, which we call a call processing 33 language. It also outlines requirements for such a language. 35 1 Introduction 37 Recently, several protocols have been created to allow telephone 38 calls to be made over IP networks, notably SIP [1] and H.323 [2]. 39 These emerging standards have opened up the possibility of a broad 40 and dramatic decentralization of the provisioning of telephone 41 services so they can be under the user's control. 43 Many Internet telephony services can, and should, be implemented 44 entirely on end devices. Multi-party calls, for instance, or call 45 waiting alert tones, or camp-on services, depend heavily on end- 46 system state and on the specific content of media streams, 47 information which often is only available to the end system. A 48 variety of services, however -- those involving user location, call 49 distribution, behavior when end systems are busy, and the like -- are 50 independent of a particular end device, or need to be operational 51 even when an end device is unavailable. These services are still best 52 located in a network device, rather than in an end system. 54 Traditionally, network-based services have been created only by 55 service providers. Service creation typically involved using 56 proprietary or restricted tools, and there was little range for 57 customization or enhancement by end users. In the Internet 58 environment, however, this changes. Global connectivity and open 59 protocols allow end users or third parties to design and implement 60 new or customized services, and to deploy and modify their services 61 dynamically without requiring a service provider to act as an 62 intermediary. 64 A number of Internet applications have such customization 65 environments -- the web has CGI [3], for instance, and e-mail has 66 Sieve [4] or procmail. To create such an open customization 67 environment for Internet telephony, we need a standardized, safe way 68 for these new service creators to describe the desired behavior of 69 network servers. 71 This document describes an architecture in which network devices 72 respond to call signalling events by triggering user-created programs 73 written in a simple, static, non-expressively-complete language. We 74 call this language a call processing language. 76 The development of this document has been substantially informed by 77 the development of a particular call processing language, as 78 described in [5]. In general, when this document refers to "a call 79 processing language," it is referring to a generic language that 80 fills this role; "the call processing language" or "the CPL" refers 81 to this particular language. 83 2 Example services 85 To motivate the subsequent discussion, this section gives some 86 specific examples of services which we want users to be able to 87 create programmatically. Note that some of these examples are 88 deliberately somewhat complicated, so as to demonstrate the level of 89 decision logic that should be possible. 91 o Call forward on busy/no answer 92 When a new call comes in, the call should ring at the user's 93 desk telephone. If it is busy, the call should always be 94 redirected to the user's voicemail box. If, instead, there's 95 no answer after four rings, it should also be redirected to 96 his or her voicemail, unless it's from a supervisor, in which 97 case it should be proxied to the user's cell phone if it is 98 currently registered. 100 o Information address 102 A company advertises a general "information" address for 103 prospective customers. When a call comes in to this address, 104 if it's currently working hours, the caller should be given a 105 list of the people currently willing to accept general 106 information calls. If it's outside of working hours, the 107 caller should get a webpage indicating what times they can 108 call. 110 o Intelligent user location 112 When a call comes in, the list of locations where the user has 113 registered should be consulted. Depending on the type of call 114 (work, personal, etc.), the call should ring at an appropriate 115 subset of the registered locations, depending on information 116 in the registrations. If the user picks up from more than one 117 station, the pick-ups should be reported back separately to 118 the calling party. 120 o Intelligent user location with media knowledge 122 When a call comes in, the call should be proxied to the 123 station the user has registered from whose media capabilities 124 best match those specified in the call request. If the user 125 does not pick up from that station within four rings, the call 126 should be proxied to the other stations from which he or she 127 has registered, sequentially, in order of decreasing closeness 128 of match. 130 o Client billing allocation -- lawyer's office 132 When a call comes in, the calling address is correlated with 133 the corresponding client, and client's name, address, and the 134 time of the call is logged. If no corresponding client is 135 found, the call is forwarded to the lawyer's secretary. 137 3 Usage scenarios 139 A CPL would be useful for implementing services in a number of 140 different scenarios. 142 o Script creation by end user 144 In the most direct approach for creating a service with a CPL, 145 an end user simply creates a script describing their service. 146 He or she simply decides what service he or she wants, 147 describes it using a CPL script, and then uploads it to a 148 server. 150 o Third party outsourcing 152 Because a CPL is a standardized language, it can also be used 153 to allow third parties to create or customize services for 154 clients. These scripts can then be run on servers owned by the 155 end user or the user's service provider. 157 o Administrator service definition 159 A CPL can also be used by server administrators to create 160 simple services or describe policy for servers they control. 161 If a server is implementing CPL services in any case, 162 extending the service architecture to allow administrators as 163 well as users to create scripts is a simple extension. 165 o Web middleware 167 Finally, there have been a number of proposals for service 168 creation or customization using web interfaces. A CPL could be 169 used as the back-end to such environments: a web application 170 could create a CPL script on behalf of a user, and the 171 telephony server could then implement the services without 172 either compotent having to be aware of the specifics of the 173 other. 175 4 CPL creation 177 There are also a number of means by which CPL scripts could be 178 created. Like HTML, which can be created in a number of different 179 manners, we envision multiple creation styles for a CPL script. 181 o Hand authoring 183 Most directly, CPL scripts can be created by hand, by 184 knowledgable users. The CPL described in [5] has a text 185 format with an uncomplicated syntax, so hand authoring will be 186 straightforward. 188 o Automated scripts 190 CPL features can be created by automated means, such as in the 191 example of the web middleware described in the previous 192 section. With a simple, text-based syntax, standard text- 193 processing languages will be able to create and edit CPL 194 scripts easily. 196 o GUI tools 198 Finally, users will be able to use GUI tools to create and 199 edit CPL scripts. We expect that most average-experience 200 users will take this approach once the CPL gains popularity. 201 The CPL will be designed with this application in mind, so 202 that the full expressive power of scripts can be represented 203 simply and straightforwardly in a graphical manner. 205 5 Network model 207 The Call Processing Language operates on a generalized model of an 208 Internet telephony network. While the details of various protocols 209 differ, on an abstract level all major Internet telephony 210 architectures are sufficiently similar that their major features can 211 be described commonly. This document generally uses SIP terminology, 212 as its authors' experience has mainly been with that protocol. 214 5.1 Model components 216 In the Call Processing Language's network model, an Internet 217 telephony network contains two types of components. 219 5.1.1 End systems 221 End systems are devices which originate and/or receive signalling 222 information and media. These include simple and complex telephone 223 devices, PC telephony clients, and automated voice systems. The CPL 224 abstracts away the details of the capabilities of these devices. An 225 end system can originate a call; and it can accept, reject, or 226 forward incoming calls. The details of this process (ringing, multi- 227 line telephones, and so forth) are not important for the CPL. 229 For the purposes of the CPL, gateways -- for example, a device which 230 connects calls between an IP telephony network and the PSTN -- are 231 also considered to be end systems. Other devices, such as mixers or 232 firewalls, are not directly dealt with by the CPL, and they will not 233 be discussed here. 235 5.1.2 Signalling servers 236 Signalling servers are devices which relay or control signalling 237 information. In SIP, they are proxy servers, redirect servers, or 238 registrars; in H.323, they are gatekeepers. 240 Signalling servers can perform three types of actions on call setup 241 information. They can: 243 proxy it: forward it on to one or more other network or end 244 systems, returning one of the responses received. 246 redirect it: return a response informing the sending system of a 247 different address to which it should send the request. 249 reject it: inform the sending system that the setup request 250 could not be completed. 252 RFC 2543 [1] has illustrations of proxy and redirect functionality. 253 End systems may also be able to perform some of these actions: almost 254 certainly rejection, and possibly redirection. 256 Signalling servers also normally maintain information about user 257 location. Whether by means of registrations (SIP REGISTER or H.323 258 RAS messages), static configuration, or dynamic searches, signalling 259 servers must have some means by which they can determine where a user 260 is currently located, in order to make intelligent choices about 261 their proxying or redirection behavior. 263 Signalling servers are also usually able to keep logs of transactions 264 that pass through them, and to send e-mail to desinations on the 265 Internet, under programatic control. 267 5.2 Component interactions 269 When an end system places a call, the call establishment request can 270 proceed by a variety of routes through components of the network. To 271 begin with, the originating end system must decide where to send its 272 requests. There are two possibilities here: the originator may be 273 configured so that all its requests go to a single local server; or 274 it may resolve the destination address to locate a remote signalling 275 server or end system to which it can send the request directly. 277 Once the request arrives at a signalling server, that server uses its 278 user location database, its local policy, DNS resolution, or other 279 methods, to determine the next signalling server or end system to 280 which the request should be sent. A request may pass through any 281 number of signalling servers: from zero (in the case when end systems 282 communicate directly) to, in principle, every server on the network. 283 What's more, any end system or signalling server can (in principle) 284 receive requests from or send them to any other. 286 Outgoing Corporate Departmental 287 Proxy Server Server 288 _______ Outgoing proxy contacts _______ _______ 289 | | corporate server | | | | 290 | | -------------------------> | | ---------> | | 291 |_____| |_____| |_____| 292 Route 1 ^ \ Searches 293 / \ for 294 Sends to/ \ User 295 proxy / _| 296 _______ _______ 297 | | Route 2 | | 298 | | ----------------------------------------------------> | | 299 |_____| Originator directly contacts destination |_____| 301 Originator Destination 303 Figure 1: Possible paths of call setup messages 305 For example, in figure 1, there are two paths the call establishment 306 request information may take. For Route 1, the originator knows only 307 a user address for the user it is trying to contact, and it is 308 configured to send outgoing calls through a local outgoing proxy 309 server. Therefore, it forwards the request to its local server, 310 which finds the server of record for that address, and forwards it on 311 to that server. 313 In this case, the organization the destination user belongs to uses a 314 multi-stage setup to find users. The corporate server identifies 315 which department a user is part of, then forwards the request to the 316 appropriate departmental server, which actually locates the user. 317 (This is similar to the way e-mail forwarding is often configured.) 318 The response to the request will travel back along the same path. 320 For Route 2, however, the originator knows the specific device 321 address it is trying to contact, and it is not configured to use a 322 local outgoing proxy. In this case, the originator can directly 323 contact the destination without having to communicate with any 324 network servers at all. 326 We see, then, that in Internet telephony signalling servers cannot in 327 general know the state of end systems they "control," since 328 signalling information may have bypassed them. This architectural 329 limitation implies a number of restrictions on how some services can 330 be implemented. For instance, a network system cannot reliably know 331 if an end system is currently busy or not; a call may have been 332 placed to the end system without traversing that network system. 333 Thus, signalling messages must explicitly travel to end systems to 334 find out their state; in the example, the end system must explicitly 335 return a "busy" indication. 337 6 Interaction of CPL with network model 339 6.1 What a script does 341 A CPL script runs in a signalling server, and controls that system's 342 proxy, redirect, or rejection actions for the set-up of a particular 343 call. It does not attempt to co-ordinate the behavior of multiple 344 signalling servers, or to describe features on a "Global Functional 345 Plane" as in the Intelligent Network architecture [6]. 347 More specifically, a script replaces the user location functionality 348 of a signalling server. As described in section 5.1.2, a signalling 349 server typically maintains a database of locations where a user can 350 be reached; it makes its proxy, redirect, and rejection decisions 351 based on the contents of that database. A CPL script replaces this 352 basic database lookup functionality; it takes the registration 353 information, the specifics of a call request, and other external 354 information it wants to reference, and chooses the signalling actions 355 to perform. 357 Abstractly, a script can be considered as a list of condition/action 358 pairs; if some attribute of the registration, request, and external 359 information matches a given condition, then the corresponding action 360 (or more properly set of actions) is taken. In some circumstances, 361 additional actions can be taken based on the consequences of the 362 first action and additional conditions. If no condition matches the 363 invitation, the signalling server's standard action -- its location 364 database lookup, for example -- is taken. 366 6.2 Which script is executed 368 CPL scripts are usually associated with a particular Internet 369 telephony address. When a call establishment request arrives at a 370 signalling server which is a CPL server, that server associates the 371 source and destination addresses specified in the request with its 372 database of CPL scripts; if one matches, the corresponding script is 373 executed. 375 Once the script has executed, if it has choosen to perform a proxy 376 action, a new Internet telephony address will result as the 377 destination of that proxying. Once this has occured, the server again 378 checks its database of scripts to see if any of them are associated 379 with the new address; if one is, that script as well is executed 380 (assuming that a script has not attempted to proxy to an address 381 which the server has already tried). For more details of this 382 recursion process, and a description of what happens when a server 383 has scripts that correspond both to a scripts origination address and 384 its destination address, see section 8.2. 386 In general, in an Internet telephony network, an address will denote 387 one of two things: either a user, or a device. A user address refers 388 to a particular individual, for example sip:joe@example.com, 389 regardless of where that user actually is or what kind of device he 390 or she is using. A device address, by contrast, refers to a 391 particular physical device, such as sip:x26063@phones.example.com. 392 Other, intermediate sorts of addresses are also possible, and have 393 some use (such as an address for "my cell phone, wherever it 394 currently happens to be registered"), but we expect them to be less 395 common. A CPL script is agnostic to the type of address it is 396 associated with; while scripts associated with user addresses are 397 probably the most useful for most services, there is no reason that a 398 script could not be associated with any other type of address as 399 well. The recursion process described above allows scripts to be 400 associated with several of a user's addresses; thus, a user script 401 could specify an action "try me at my cell phone," whereas a device 402 script could say "I don't want to accept cell phone calls while I'm 403 out of my home area." 405 It is also possible for a CPL script to be associated not with one 406 specific Internet telephony address, but rather with all addresses 407 handled by a signalling server, or a large set of them. For instance, 408 an administrator might configure a system to prevent calls from or to 409 a list of banned incoming or outgoing addresses; these should 410 presumably be configured for everyone, but users should still to be 411 able to have their own custom scripts as well. Exactly when such 412 scripts should be executed in the recursion process depends on the 413 precise nature of the administrative script. See section 8.2 for 414 further discussion of this. 416 6.3 Where a script runs 417 Users can have CPL scripts on any network server which their call 418 establishment requests pass through and with which they have a trust 419 relationship. For instance, in the example in figure 1, the 420 originating user could have a script on the outgoing proxy, and the 421 destination user could have scripts on both the corporate server and 422 the departmental server. These scripts would typically perform 423 different functions, related to the role of the server on which they 424 reside; a script on the corporate-wide server could be used to 425 customize which department the user wishes to be found at, for 426 instance, whereas a script at the departmental server could be used 427 for more fine-grained location customization. Some services, such as 428 filtering out unwanted calls, could be located at either server. See 429 section 8.3 for some implications of a scenario like this. 431 7 Creation and transport of a call processing language script 433 Users create call processing language scripts, typically on end 434 devices, and transmit them through the network to signalling servers. 435 Scripts persist in signalling servers until changed or deleted, 436 unless they are specifically given an expiration time; a network 437 system which supports CPL scripting will need stable storage. 439 The end device on which the user creates the CPL script need not bear 440 any relationship to the end devices to which calls are actually 441 placed. For example, a CPL script might be created on a PC, whereas 442 calls might be intended to be received on a simple audio-only 443 telephone. Indeed, the device on which the script is created may not 444 be an "end device" in the sense described in section 5.1.1 at all; 445 for instance, a user could create and upload a CPL script from a 446 non-multimedia-capable web terminal. 448 The CPL also might not necessarily be created on a device near either 449 the end device or the signalling server in network terms. For 450 example, a user might decide to forward his or her calls to a remote 451 location only after arriving at that location. 453 The exact means by which the end device transmits the script to the 454 server remains to be determined; it is likely that many solutions 455 will be able to co-exist. This method will need to be authenticated 456 in almost all cases. The methods that have been suggested include 457 web file upload, SIP REGISTER message payloads, remote method 458 invocation, SNMP, ACAP, LDAP, and remote file systems such as NFS. 460 Users can also retrieve their current script from the network to an 461 end system so it can be edited. The signalling server should also be 462 able to report errors related to the script to the user, both static 463 errors that could be detected at upload time, and any run-time errors 464 that occur. 466 If a user has trust relationships with multiple signalling servers 467 (as discussed in section 6.3), the user may choose to upload scripts 468 to any or all of those servers. These scripts can be entirely 469 independent. 471 8 Feature interaction behavior 473 Feature interaction is the term used in telephony systems when two or 474 more requested features produce ambiguous or conflicting behavior 475 [7]. Feature interaction issues for features implemented with a call 476 processing language can be roughly divided into three categories: 477 feature-to-feature in one server, script-to-script in one server, and 478 server-to-server. 480 8.1 Feature-to-feature interactions 482 Due to the explicit nature of event conditions discussed in the 483 previous section, feature-to-feature interaction is not likely to be 484 a problem in a call processing language environment. Whereas a 485 subscriber to traditional telephone features might unthinkingly 486 subscribe to both "call waiting" and "call forward on busy," a user 487 creating a CPL script would only be able to trigger one action in 488 response to the condition "a call arrives while the line is busy." 489 Given a good user interface for creation, or a CPL server which can 490 check for unreachable code in an uploaded script, contradictory 491 condition/action pairs can be avoided. 493 8.2 Script-to-script interactions 495 Script-to-script interactions arise when a server invokes multiple 496 scripts for a single call, as described in section 6.2. This can 497 occur in a number of cases: if both the call originator and the 498 destination have scripts specified on a single server; if a script 499 forwards a request to another address which also has a script; or if 500 an administrative script is specified as well as a user's individual 501 script. 503 The solution to this interaction is to determine an ordering among 504 the scripts to be executed. In this ordering, the "first" script is 505 executed first; if this script allows or permits the call to be 506 proxied, the script corresponding to the next address is executed. 507 When the first script says to forward the request to some other 508 address, those actions are considered as new requests which arrive at 509 the second script. When the second script sends back a final 510 response, that response arrives at the first script in the same 511 manner as if a request arrived over the network. Note that in some 512 cases, forwarding can be recursive; a CPL server must be careful to 513 prevent forwarding loops. 515 Abstractly, this can be viewed as equivalent to having each script 516 execute on a separate signalling server. Since the CPL architecture 517 is designed to allow scripts to be executed on multiple signalling 518 servers in the course of locating a user, we can conceptually 519 transform script-to-script interactions into the server-to-server 520 interactions described in the next section, reducing the number of 521 types of interactions we need to concern ourselves with. 523 The question, then, is to determine the correct ordering of the 524 scripts. For the case of a script forwarding to an address which 525 also has a script, the ordering is obvious; the other two cases are 526 somewhat more subtle. When both originator and destination scripts 527 exist, the originator's script should be executed before the 528 destination script; this allows the originator to perform address 529 translation, call filtering, etc., before a destination address is 530 determined and a corresponding script is chosen. 532 Even more complicated is the case of the ordering of administrative 533 scripts. Many administrative scripts, such as ones that restrict 534 source and destination addresses, need to be run after originator 535 scripts, but before destination scripts, to avoid a user's script 536 evading administrative restrictions through clever forwarding; 537 however, others, such as a global address book translation function, 538 would need to be run earlier or later. Servers which allow 539 administrative scripts to be run will need to allow the administrator 540 to configure when in the script execution process a particular 541 administrative script should fall. 543 8.3 Server-to-server interactions 545 The third case of feature interactions, server-to-server 546 interactions, is the most complex of these three. The canonical 547 example of this type of interaction is the combination of Originating 548 Call Screening and Call Forwarding: a user (or administrator) may 549 wish to prevent calls from being placed to a particular address, but 550 the local script has no way of knowing if a call placed to some 551 other, legitimate address will be proxied, by a remote server, to the 552 banned address. This type of problem is unsolvable in an 553 administratively heterogeneous network, even a "lightly" 554 heterogeneous network such as current telephone systems. CPL does not 555 claim to solve it, but the problem is not any worse for CPL scripts 556 than for any other means of deploying services. 558 Another class of server-to-server interactions are best resolved by 559 the underlying signalling protocol, since they can arise whether the 560 signalling servers are being controlled by a call processing language 561 or by some entirely different means. One example of this is 562 forwarding loops, where user X may have calls forwarded to Y, who has 563 calls forwarded back to X. SIP has a mechanism to detect such loops. 564 A call processing language server thus does not need to define any 565 special mechanisms to prevent such occurrences; it should, however, 566 be possible to trigger a different set of call processing actions in 567 the event that a loop is detected, and/or to report back an error to 568 the owner of the script through some standardized run-time error 569 reporting mechanism. 571 8.4 Signalling ambiguity 573 As an aside, [7] discusses a fourth type of feature interaction for 574 traditional telephone networks, signalling ambiguity. This can arise 575 when several features overload the same operation in the limited 576 signal path from an end station to the network: for example, flashing 577 the switch-hook can mean both "add a party to a three-way call" and 578 "switch to call waiting." Because of the explicit nature of 579 signalling in both the Internet telephony protocols discussed here, 580 this issue does not arise. 582 9 Relationship with existing languages 584 This document's description of the CPL as a "language" is not 585 intended to imply that a new language necessarily needs to be 586 implemented from scratch. A server could potentially implement all 587 the functionality described here as a library or set of extensions 588 for an existing language; Java, or the various freely-available 589 scripting languages (Tcl, Perl, Python, Guile), are obvious 590 possibilities. 592 However, there are motivations for creating a new language. All the 593 existing languages are, naturally, expressively complete; this has 594 two inherent disadvantages. The first is that any function 595 implemented in them can take an arbitrarily long time, use an 596 arbitrarily large amount of memory, and may never terminate. For call 597 processing, this sort of resource usage is probably not necessary, 598 and as described in section 11.1, may in fact be undesirable. One 599 model for this is the electronic mail filtering language Sieve [4], 600 which deliberately restricts itself from being Turing-complete. 602 Similar levels of safety and protection (though not automatic 603 generation and parsing) could also be achieved through the use of a 604 "sandbox" such as is used by Java applets, where strict bounds are 605 imposed on the amount of memory, cpu time, stack space, etc., that a 606 program can use. The difficulty with this approach is primarily in 607 its lack of transparency and portability: unless the levels of these 608 bounds are imposed by the standard, a bad idea so long as available 609 resources are increasing exponentially with Moore's Law, a user can 610 never be sure whether a particular program can sucessfully be 611 executed on a given server without running into the server's resource 612 limits, and a program which executes sucessfully on one server may 613 fail unexpectedly on another. Non-expressively-complete languages, on 614 the other hand, allow an implicit contract between the script writer 615 and the server: so long as the script stays within the rules of the 616 language, the server will guarantee that it will execute the script. 618 The second disadvantage with expressively complete languages is that 619 they make automatic generation and parsing of scripts very difficult, 620 as every parsing tool must be a full interpreter for the language. An 621 analogy can be drawn from the document-creation world: while text 622 markup languages like HTML or XML can be, and are, easily manipulated 623 by smart editors, powerful document programming languages such as 624 LaTeX or Postscript usually cannot be. While there are word 625 processors that can save their documents in LaTeX form, they cannot 626 accept as input arbitrary LaTeX documents, let alone preserve the 627 structure of the original document in an edited form. By contrast, 628 essentially any HTML editor can edit any HTML document from the web, 629 and the high-quality ones preserve the structure of the original 630 documents in the course of editing them. 632 10 Related work 634 10.1 IN service creation environments 636 The ITU's IN series describe, on an abstract level, service creation 637 environments [6]. These describe services in a traditional circuit- 638 switched telephone network as a series of decisions and actions 639 arranged in a directed acyclic graph. Many vendors of IN services use 640 modified and extended versions of this for their proprietary service 641 creation environments. 643 10.2 SIP CGI 645 SIP CGI [8] is an interface for implementing services on SIP servers. 646 Unlike a CPL, it is a very low-level interface, and would not be 647 appropriate for services written by non-trusted users. 649 The paper "Programming Internet Telephony Services" [9] discusses the 650 similarties and contrasts between SIP CGI and CPL in more detail. 652 11 Necessary language features 654 This section lists those properties of a call processing language 655 which we believe to be necessary to have in order to implement the 656 motivating examples, in line with the described architecture. 658 11.1 Language characteristics 659 These are some abstract attributes which any proposed call processing 660 language should possess. 662 o Light-weight, efficient, easy to implement 664 In addition to the general reasons why this is desirable, a 665 network server might conceivably handle very large call 666 volumes, and we don't want CPL execution to be a major 667 bottleneck. One way to achieve this might be to compile 668 scripts before execution. 670 o Easily verifiable for correctness 672 For a script which runs in a server, mis-configurations can 673 result in a user becoming unreachable, making it difficult to 674 indicate run-time errors to a user (though a second-channel 675 error reporting mechanism such as e-mail could ameliorate 676 this). Thus, it should be possible to verify, when the script 677 is committed to the server, that it is at least syntactically 678 correct, does not have any obvious loops or other failure 679 modes, and does not use too many server resources. 681 o Executable in a safe manner 683 No action the CPL script takes should be able to subvert 684 anything about the server which the user shouldn't have access 685 to, or affect the state of other users without permission. 686 Additionally, since CPL scripts will typically run on a server 687 on which users cannot normally run code, either the language 688 or its execution environment must be designed so that scripts 689 cannot use unlimited amounts of network resources, server CPU 690 time, storage, or memory. 692 o Easily writeable and parseable by both humans and machines. 694 For maximum flexibility, we want to allow humans to write 695 their own scripts, or to use and customize script libraries 696 provided by others. However, most users will want to have a 697 more intuitive user-interface for the same functionality, and 698 so will have a program which creates scripts for them. Both 699 cases should be easy; in particular, it should be easy for 700 script editors to read human-generated scripts, and vice- 701 versa. 703 o Extensible 705 It should be possible to add additional features to a language 706 in a way that existing scripts continue to work, and existing 707 servers can easily recognize features they don't understand 708 and safely inform the user of this fact. 710 o Independent of underlying signalling details 712 The same scripts should be usable whether the underlying 713 protocol is SIP, H.323, a traditional telephone network, or 714 any other means of setting up calls. It should also be 715 agnostic to address formats. (We use SIP terminology in our 716 descriptions of requirements, but this should map fairly 717 easily to other systems.) It may also be useful to have the 718 language extend to processing of other sorts of communication, 719 such as e-mail or fax. 721 11.2 Base features -- call signalling 723 To be useful, a call processing language obviously should be able to 724 react to and initiate call signalling events. 726 o Should execute actions when a call request arrives 728 See section 6, particularly 6.1. 730 o Should be able to make decisions based on event properties 732 A number of properties of a call event are relevant for a 733 script's decision process. These include, roughly in order of 734 importance: 736 - Destination address 738 We want to be able to do destination-based routing or 739 screening. Note that in SIP we want to be able to filter on 740 either or both of the addresses in the To header and the 741 Request-URI. 743 - Originator address 745 Similarly, we want to be able to do originator-based 746 screening or routing. 748 - Caller Preferences 750 In SIP, a caller can express preferences about the type of 751 device to be reached -- see [10]. The script should be able 752 to make decisions based on this information. 754 - Information about caller or call 755 SIP has textual fields such as Subject, Organization, 756 Priority, etc., and a display name for addresses; users can 757 also add non-standard additional headers. H.323 has a single 758 Display field. 760 - Media description 762 Requests specify the types of media that will flow, their 763 bandwidth usage, their network destination addresses, etc. 765 - Authentication/encryption status 767 Requests can be authenticated. Many properties of the 768 authentication are relevant: the method of 769 authentication/encryption, who performed the authentication, 770 which specific fields were encrypted, etc. 772 o Should be able to take action based on a request 774 There are a number of actions we can take in response to an 775 incoming request. We can: 777 - reject it 779 We should be able to indicate that the call is not 780 acceptable or not able to be completed. We should also be 781 able to send more specific rejection codes (including, for 782 SIP, the associated textual string, warning codes, or 783 message payload). 785 - send a provisional response to it 787 While a call request is being processed, provisional 788 responses such as "Trying," "Ringing," and "Queued" are sent 789 back to the caller. It is not clear whether the script 790 should specify the sending of such responses explicitly, or 791 whether they should be implicit in other actions performed. 793 - redirect it 795 We should be able to tell the request sender to try a 796 different location. 798 - proxy it 800 We should be able to send the request on to another 801 location, or to several other locations ("branching" the 802 request), and await the responses. It should also be 803 possible to specify a timeout value after which we give up 804 on receiving any definitive responses. 806 o Should be able to take action based a response to a proxied or 807 branched request 809 Once we have proxied requests, we need to be able to make 810 decisions based on the responses we receive to those requests 811 (or the lack thereof). We should be able to: 813 - consider its message fields 815 We should be able to consider the same fields of a response 816 as we consider in the initial request. 818 - relay it on to the requestor 820 If the response is satisfactory, it should be returned to 821 the sender. 823 - for a branch, choose one of several responses to relay back 825 If we branched a request, we obviously expect to receive 826 several responses. There are several issues here -- 827 choosing among the responses, and how long to wait if we've 828 received responses from some but not all destinations. 830 - initiate other actions 832 If we didn't get a response, or any we liked, we should be 833 able to try something else instead (e.g., call forward on 834 busy). 836 11.3 Base features -- non-signalling 838 A number of other features that a call processing language should 839 have do not refer to call signalling per se; however, they are still 840 extremely desirable to implement many useful features. 842 The servers which provide these features might reside in other 843 Internet devices, or might be local to the server (or other 844 possibilities). The language should be independent of the location of 845 these servers, at least at a high level. 847 o Logging 849 In addition to the CPL server's natural logging of events, the 850 user will also want to be able to log arbitrary other items. 852 The actual storage for this logging information might live 853 either locally or remotely. 855 o Error reporting 857 If an unexpected error occurs, the script should be able to 858 report the error to the script's owner. This should use the 859 same mechanism as the script server uses to report language 860 errors to the user (see section 11.5). 862 o Access to user-location info 864 Proxies will often collect information on users' current 865 location, either through SIP REGISTER messages, the H.323 RRQ 866 family of RAS messages, or some other mechanism (see section 867 5.2). The CPL should be able to refer to this information so a 868 call can be forwarded to the registered locations or some 869 subset of them. 871 o Database access 873 Much information for CPL control might be stored in external 874 databases, for example a wide-area address database, or 875 authorization information, for a CPL under administrative 876 control. The language could specify some specific database 877 access protocols (such as SQL or LDAP), or could be more 878 generic. 880 o Other external information 882 Other external information the script should be able to access 883 includes web pages, which could be sent back in a SIP message 884 body; or a clean interface to remote procedure calls such as 885 Corba, RMI, or DCOM, for instance to access an external 886 billing database. 888 11.4 Language features 890 Some features do not involve any operations external to the CPL's 891 execution environment, but are still necessary to allow some standard 892 services to be implemented. (This list is not exhaustive.) 894 o Pattern-matching 896 It should be possible to give special treatment to addresses 897 and other text strings based not only on the full string but 898 also on more general or complex sub-patterns of them. 900 o Address filtering 902 Once a set of addresses has been retrieved through one of the 903 methods in section 11.3, the user needs to be able to choose a 904 sub-set of them, based on their address components or other 905 parameters. 907 o Randomization 909 Some forms of call distribution are randomized as to where 910 they actually end up. 912 o Date/time information 914 Users may wish to condition some services (e.g., call 915 forwarding, call distribution) on the current time of day, day 916 of the week, etc. 918 11.5 Control 920 As described in section 7, we must have a mechanism to send and 921 retrieve CPL scripts, and associated data, to and from a signalling 922 server. This method should support reporting upload-time errors to 923 users; we also need some mechanism to report errors to users at 924 script execution time. Authentication is vital, and encryption is 925 very useful. The specification of this mechanism can be (and probably 926 ought to be) a separate specification from that of the call 927 processing language itself. 929 12 Security considerations 931 The security considerations of transferring CPL scripts are discussed 932 in sections 7 and 11.5. Some considerations about the execution of 933 the language are discussed in section 11.1. 935 13 Changes from previous versions 937 13.1 Changes from draft-ietf-iptel-cpl-framework-00 939 The changebars in the Postscript and PDF versions of this document 940 indicate changes from this version. 942 o Added "Usage scenarios" section. 944 o Added "CPL creation" section. 946 o Reorganized old "Architecture" section into "Network model" 947 and "Interaction," and significantly re-organized and re- 948 worked it. 950 o Added discussion of "sandbox" execution environments, and 951 contrasted their merits with those of non-expressively- 952 complete languages. 954 o Changed the term "network systems" to "signalling servers" 955 throughout, to align the terminology used to that used in the 956 gateway location protocol. 958 o Significant re-writing and clarification throughout the 959 document. 961 13.2 Changes from draft-ietf-iptel-cpl-requirements-00 963 o Changed the title of the draft from "...Requirements" to 964 "...Framework and Requirements," and changed the draft name, 965 to better reflect the content. 967 o Deleted a number of overambitious service examples that aren't 968 supported in the CPL as it has developed. 970 o Deleted discussion of end systems, media devices, and other 971 items that aren't supported in the CPL as it has developed. 973 o Reorganized the Architecture section. 975 o Clarified the Network Model section. 977 o Added Related Work section. 979 o Added requirement to support caller preferences. 981 o Deleted many requirements for higher-level and end-system 982 features that are not supported in the CPL as it has 983 developed. 985 o Re-worded many sections for clarity. 987 o Added To Do / Open Issues section. 989 14 To Do / Open Issues 991 o Add Terminology section. 993 15 Acknowledgments 995 We would like to thank Tom La Porta and Jonathan Rosenberg for their 996 comments and suggestions. 998 16 Authors' Addresses 1000 Jonathan Lennox 1001 Dept. of Computer Science 1002 Columbia University 1003 1214 Amsterdam Avenue, MC 0401 1004 New York, NY 10027 1005 USA 1006 electronic mail: lennox@cs.columbia.edu 1008 Henning Schulzrinne 1009 Dept. of Computer Science 1010 Columbia University 1011 1214 Amsterdam Avenue, MC 0401 1012 New York, NY 10027 1013 USA 1014 electronic mail: schulzrinne@cs.columbia.edu 1016 17 Bibliography 1018 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1019 session initiation protocol," Request for Comments (Proposed 1020 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 1022 [2] International Telecommunication Union, "Visual telephone systems 1023 and equipment for local area networks which provide a non-guaranteed 1024 quality of service," Recommendation H.323, Telecommunication 1025 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 1027 [3] K. Coar and D. Robinson, "The WWW common gateway interface 1028 version 1.1," Internet Draft, Internet Engineering Task Force, Apr. 1029 1999. Work in progress. 1031 [4] T. Showalter, "Sieve: A mail filtering language," Internet Draft, 1032 Internet Engineering Task Force, Mar. 1999. Work in progress. 1034 [5] J. Lennox and H. Schulzrinne, "CPL: a language for user control 1035 of internet telephony services," Internet Draft, Internet Engineering 1036 Task Force, Mar. 1999. Work in progress. 1038 [6] International Telecommunication Union, "General recommendations 1039 on telephone switching and signaling -- intelligent network: 1040 Introduction to intelligent network capability set 1," Recommendation 1041 Q.1211, Telecommunication Standardization Sector of ITU, Geneva, 1042 Switzerland, Mar. 1993. 1044 [7] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. 1045 Schure, and H. Velthuijsen, "A feature interaction benchmark for IN 1046 and beyond," Feature Interactions in Telecommunications Systems, IOS 1047 Press , pp. 1--23, 1994. 1049 [8] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway 1050 interface for SIP," Internet Draft, Internet Engineering Task Force, 1051 May 1999. Work in progress. 1053 [9] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming 1054 internet telephony services," Technical Report CUCS-010-99, Columbia 1055 University, New York, New York, Mar. 1999. 1057 [10] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 1058 callee capabilities," Internet Draft, Internet Engineering Task 1059 Force, Mar. 1999. Work in progress. 1061 Full Copyright Statement 1063 Copyright (c) The Internet Society (1999). All Rights Reserved. 1065 This document and translations of it may be copied and furnished to 1066 others, and derivative works that comment on or otherwise explain it 1067 or assist in its implementation may be prepared, copied, published 1068 and distributed, in whole or in part, without restriction of any 1069 kind, provided that the above copyright notice and this paragraph are 1070 included on all such copies and derivative works. However, this 1071 document itself may not be modified in any way, such as by removing 1072 the copyright notice or references to the Internet Society or other 1073 Internet organizations, except as needed for the purpose of 1074 developing Internet standards in which case the procedures for 1075 copyrights defined in the Internet Standards process must be 1076 followed, or as required to translate it into languages other than 1077 English. 1079 The limited permissions granted above are perpetual and will not be 1080 revoked by the Internet Society or its successors or assigns. 1082 This document and the information contained herein is provided on an 1083 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1084 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1085 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1086 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1087 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1089 Table of Contents 1091 1 Introduction ........................................ 1 1092 2 Example services .................................... 2 1093 3 Usage scenarios ..................................... 3 1094 4 CPL creation ........................................ 4 1095 5 Network model ....................................... 5 1096 5.1 Model components .................................... 5 1097 5.1.1 End systems ......................................... 5 1098 5.1.2 Signalling servers .................................. 5 1099 5.2 Component interactions .............................. 6 1100 6 Interaction of CPL with network model ............... 8 1101 6.1 What a script does .................................. 8 1102 6.2 Which script is executed ............................ 8 1103 6.3 Where a script runs ................................. 9 1104 7 Creation and transport of a call processing 1105 language script ................................................ 10 1106 8 Feature interaction behavior ........................ 11 1107 8.1 Feature-to-feature interactions ..................... 11 1108 8.2 Script-to-script interactions ....................... 11 1109 8.3 Server-to-server interactions ....................... 12 1110 8.4 Signalling ambiguity ................................ 13 1111 9 Relationship with existing languages ................ 13 1112 10 Related work ........................................ 14 1113 10.1 IN service creation environments .................... 14 1114 10.2 SIP CGI ............................................. 14 1115 11 Necessary language features ......................... 14 1116 11.1 Language characteristics ............................ 14 1117 11.2 Base features -- call signalling .................... 16 1118 11.3 Base features -- non-signalling ..................... 18 1119 11.4 Language features ................................... 19 1120 11.5 Control ............................................. 20 1121 12 Security considerations ............................. 20 1122 13 Changes from previous versions ...................... 20 1123 13.1 Changes from draft-ietf-iptel-cpl-framework-00 ...... 20 1124 13.2 Changes from draft-ietf-iptel-cpl-requirements-00 1125 ................................................................ 21 1126 14 To Do / Open Issues ................................. 21 1127 15 Acknowledgments ..................................... 21 1128 16 Authors' Addresses .................................. 22 1129 17 Bibliography ........................................ 22