idnits 2.17.1 draft-ietf-iptel-cpl-framework-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 20 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 (June 25, 1999) is 9065 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 848 looks like a reference -- Missing reference section? '2' on line 852 looks like a reference -- Missing reference section? '3' on line 857 looks like a reference -- Missing reference section? '4' on line 862 looks like a reference -- Missing reference section? '5' on line 865 looks like a reference -- Missing reference section? '6' on line 871 looks like a reference -- Missing reference section? '7' on line 875 looks like a reference -- Missing reference section? '8' on line 879 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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-00.txt Columbia University 4 June 25, 1999 5 Expires: December 1999 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 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 A large number of the services we wish to make possible for Internet 33 telephony require fairly elaborate combinations of signalling 34 operations, often in network devices, to complete. We want a simple 35 and standardized way to create such services to make them easier to 36 implement and deploy. This document describes an architectural 37 framework for such a mechanism, which we call a call processing 38 language. It also outlines requirements for such a language. 40 1 Introduction 42 Recently, several protocols have been created to allow telephone 43 calls to be made over IP networks, notably SIP [1] and H.323 [2]. 44 These emerging standards have opened up the possibility of a broad 45 and dramatic decentralization of the provisioning of telephone 46 services so they can be under the user's control. 48 Many Internet telephony services can, and should, be implemented 49 entirely on end devices. Multi-party calls, for instance, or call 50 waiting alert tones, or camp-on services, depend heavily on end- 51 system state and on the specific content of media streams, 52 information which often is only available to the end system. A 53 variety of services, however -- those involving user location, call 54 distribution, behavior when end systems are busy, and the like -- are 55 independent of a particular end device, or need to be operational 56 even when an end device is unavailable. These services are still best 57 located in a network device, rather than in an end system. 59 Traditionally, network-based services have been created only by 60 service providers. Service creation typically involved using 61 proprietary or restricted tools, and there was little range for 62 customization or enhancement by end users. Internet telephony, 63 however, provides an opportunity to open up the service creation 64 process to end users or third-party service designers. To accomplish 65 this however, we need a standardized, safe way for these new service 66 creators to describe the desired behavior of network servers. 68 This document describes an architecture in which network devices 69 respond to call signalling events by triggering user-created programs 70 written in a simple, static, non-expressively-complete language. We 71 call this language a call processing language 73 2 Motivating examples 75 To motivate the subsequent discussion, this section gives some 76 specific examples of services which we want users to be able to 77 create programmatically. Note that some of these examples are 78 deliberately somewhat complicated, so as to demonstrate the level of 79 decision logic that should be possible. 81 o Call forward on busy/no answer 83 When a new call comes in, the call should ring at the user's 84 desk telephone. If it is busy, the call should always be 85 redirected to the user's voicemail box. If, instead, there's no 86 answer after four rings, it should also be redirected to his or 87 her voicemail, unless it's from a supervisor, in which case it 88 should be proxied to the user's cell phone if it is currently 89 registered. 91 o Information address 93 A company advertises a general "information" address for 94 prospective customers. When a call comes in to this address, if 95 it's currently working hours, the caller should be given a list 96 of the people currently willing to accept general information 97 calls. If it's outside of working hours, the caller should get a 98 webpage indicating what times they can call. 100 o Intelligent user location 102 When a call comes in, the list of locations where the user has 103 registered should be consulted. Depending on the type of call 104 (work, personal, etc.), the call should ring at an appropriate 105 subset of the registered locations, depending on information in 106 the registrations. If the user picks up from more than one 107 station, the pick-ups should be reported back separately to the 108 calling party. 110 o Intelligent user location with media knowledge 112 When a call comes in, the call should be proxied to the station 113 the user has registered from whose media capabilities best match 114 those specified in the call request. If the user does not pick 115 up from that station within four rings, the call should be 116 proxied to the other stations from which he or she has 117 registered, sequentially, in order of decreasing closeness of 118 match. 120 o Client billing allocation -- lawyer's office 122 When a call comes in, the calling address is correlated with the 123 corresponding client, and client's name, address, and the time 124 of the call is logged. If no corresponding client is found, the 125 call is forwarded to the lawyer's secretary. 127 3 Architecture 129 The Call Processing Language operates on a generalized model of an 130 Internet telephony network. While the details of various protocols 131 differ, on an abstract level all major Internet telephony 132 architectures are sufficiently similar that their major features can 133 be described commonly. 135 3.1 Network components 137 In the view of the Call Processing Language, an Internet telephony 138 network consists of two types of components. End systems originate 139 and/or receive signalling information and media; network systems 140 relay or control signalling information. While in actual networks 141 other devices exist, such as mixers, media gateways, or firewalls, 142 the CPL does not deal with them directly, and they will not be 143 discussed here. 145 Network systems, in SIP, are proxy servers, redirect servers, or 146 registrars; in H.323 they are gatekeepers. On the abstract level the 147 CPL deals with, the functionality of two protocols is largely 148 equivalent, and this document will generally use SIP terminology. 149 Network systems can perform three types of actions on call setup 150 information. They can: 152 proxy it: forward it on to one or more other network or end systems, 153 returning one of the responses received. 155 redirect it: return a response informing the sending system of a 156 different address to which it should send the request. 158 reject it: inform the sending system that the setup request could not 159 be completed. See RFC 2543 [1] for illustrations of proxy and 160 redirect functionality. End systems may also be able to perform 161 some of these actions: almost certainly rejection, and possibly 162 redirection. 164 3.2 Network model 166 An Internet telephony network contains a number of network systems 167 and a number of user agents. Call establishment requests can pass 168 through a series of network systems, and user agents can be contacted 169 by any of a number of network systems, or directly by other user 170 agents. 172 For example, in figure 1, there are two paths the call establishment 173 request information may take. For Route 1, the originator knows only 174 a user address for the user it is trying to contact, and it is 175 configured to send outgoing calls through a local outgoing proxy 176 server. Therefore, it forwards the request to its local server, 177 which finds the server of record for that address, and forwards it on 178 to that server. 180 In this case, the organization the destination user belongs to uses a 181 multi-stage setup to find users. The corporate server identifies 182 which department a user is part of, then forwards the request to the 183 appropriate departmental server, which actually locates the user. 184 (This is similar to the way e-mail forwarding is often configured.) 185 The response to the request will travel back along the same path. 187 For route 2, however, the originator knows the specific device 188 address it is trying to contact, and it is not configured to use a 189 local outgoing proxy. In this case, the originator can directly 190 contact the destination without having to communicate with any 191 network servers at all. 193 Outgoing Corporate Departmental 194 Proxy Server Server 195 _______ Outgoing proxy contacts _______ _______ 196 | | corporate server | | | | 197 | | -------------------------> | | ---------> | | 198 |_____| |_____| |_____| 199 Route 1 ^ \ Searches 200 / \ for 201 Sends to/ \ User 202 proxy / _| 203 _______ _______ 204 | | Route 2 | | 205 | | ----------------------------------------------------> | | 206 |_____| Originator directly contacts destination |_____| 208 Originator Destination 210 Figure 1: Possible paths of call setup messages 212 We see, then, that in Internet telephony network systems cannot in 213 general know the state of end systems they "control," since 214 signalling information may have bypassed them. This architectural 215 limitation implies a number of restrictions on how some services can 216 be implemented. For instance, a network system cannot reliably know 217 if an end system is currently busy or not; a call may have been 218 placed to the end system without traversing that network system. 219 Thus, signalling messages must explicitly travel to end systems to 220 find out their state; in the example, the end system must explicitly 221 return a "busy" indication. 223 Users can have CPL scripts on any network server which their call 224 establishment requests pass through and with which they have a trust 225 relationship. For instance, in the example above the destination user 226 could have scripts on both the corporate server and the departmental 227 server. These scripts would typically perform different functions, 228 related to the role of the server on which they reside; a script on 229 the corporate-wide server could be used to customize which department 230 the user wishes to be found at, for instance, whereas a script at the 231 departmental server could be used for more fine-grained location 232 customization. Some services, such as filtering out unwanted calls, 233 could be located at either server. See section 3.6.3 for some 234 implications of a scenario like this. 236 3.3 Role of a CPL script 238 A CPL script runs in a network system, and controls that system's 239 proxy, redirect, or rejection actions for the set-up of a particular 240 call. It does not attempt to co-ordinate the behavior of multiple 241 network systems, or to describe features on a "Global Functional 242 Plane" as in the Intelligent Network architecture. 244 CPL scripts are associated with a particular Internet telephony 245 address. When a call establishment request arrives at a network 246 system which is a CPL server, that server associates the address 247 specified in the request with its database of CPL scripts; if one 248 matches, that corresponding script is executed. CPL scripts may be 249 associated either with the originator address or the destination 250 address of the call establishment request. For some discussion of 251 what happens if, for instance, a server has scripts for both an 252 originating and destination address, see section 3.6.2. 254 In general, in an Internet telephony network, an address will denote 255 one of two things: either a user, or a device. A user address refers 256 to a particular individual, for example sip:joe@example.com, 257 regardless of where that user actually is or what kind of device he 258 or she is using. A device address, by contrast, refers to a 259 particular physical device, such as sip:x26063@phones.example.com. 260 Other, intermediate sorts of addresses are also possible, and have 261 some use (such as an address for "my cell phone, wherever it 262 currently happens to be registered"), but we expect them to be less 263 common. A CPL script is agnostic to the type of address it is 264 associated with; while scripts associated with user addresses are 265 probably the most useful for most services, there is no reason that a 266 script could not be associated with any other type of address as 267 well. 269 By controlling basic call set-up actions, a user can achieve a number 270 of services. Many common services are implemented using a CPL script 271 for incoming calls to a user address. These include: searching for 272 the user's current location in some specialized way; specifying what 273 happens when this initial search fails, either because it received 274 some sort of negative response (e.g., busy) or did not receive any 275 definitive response within a fixed time period (e.g., no answer); or 276 handling certain originating addresses specifically, for instance by 277 informing the caller that the call was refused. Services that can be 278 implemented by a script triggered by an outgoing user address are 279 somewhat more limited, but one example is to translate a user's 280 abbreviated addresses into addresses specified with a fully-qualified 281 domain name. 283 3.4 Creation and transport of a call processing language script 285 Users create call processing language scripts, typically on end 286 devices, and transmit them through the network to network systems. 287 Scripts persist in network systems until changed or deleted, unless 288 they are specifically given an expiration time; a network system 289 which supports CPL scripting will need stable storage. 291 The exact means by which the end device transmits the script to the 292 server remains to be determined; it is likely that many solutions 293 will be able to co-exist. This method will need to be authenticated 294 in almost all cases. The methods that have been suggested include 295 web file upload, SIP REGISTER message payloads, remote method 296 invocation, SNMP, ACAP, LDAP, and remote file systems such as NFS. 298 Creation of a CPL script may be through the creation of a text file; 299 or for a simpler user experience, a graphical user interface which 300 allows the manipulation of some basic rules. 302 The end device on which the user creates the CPL script need not bear 303 any relationship to the end devices to which calls are actually 304 placed. For example, a CPL script might be created on a PC, whereas 305 calls might be intended to be received on a simple audio-only 306 telephone. The CPL also might not necessarily be created on a device 307 near either the end device or the signalling server in network terms; 308 a user might, for example, decide to forward his or her calls to a 309 remote location only after arriving at that location. 311 Users can also retrieve their current script from the network to an 312 end system so it can be edited. The signalling server should also be 313 able to report errors related to the script to the user, both static 314 errors that could be detected at upload time, and any run-time errors 315 that occur. 317 If a user's calls can pass through multiple local signalling servers 318 which know about that user (as discussed in section 3.2), the user 319 may choose to upload scripts to any or all of those servers. These 320 scripts can be entirely independent. 322 3.5 Execution process of a CPL script 324 When a call event arrives, a CPL server considers the information in 325 the request and determines if any of the scripts it has stored are 326 applicable to the call in question. If so, it performs the actions 327 corresponding to the matching scripts. 329 The most common type of script defines a set of actions to be taken 330 for the entire process of call set-up -- from the time a call request 331 is initially received, to the time that (from the point of view of 332 this device) the call is either definitively accepted or definitively 333 rejected. This could be near-instantaneous, if, for instance, the 334 script decides to reject the call; or it could be an arbitrarily long 335 time, if the server allows calls to wait for a call pick-up without 336 imposing a timeout. 338 Abstractly, a script can be considered as a list of condition/action 339 pairs; if an incoming invitation matches a given condition, then the 340 corresponding action (or more properly set of actions) will be taken. 341 In some circumstances, additional actions can be taken based on the 342 consequences of the first action, and possibly on additional 343 conditions. If no condition matches the invitation, the signalling 344 server's standard action should be taken. 346 While many of the uses of a CPL script are specific to one particular 347 user, there are a number of circumstances in which an administrator 348 of a signalling server would wish to provide a script which applies 349 to all users of the server, or a large set of them. For instance, a 350 system might be configured to prevent calls from or to a list of 351 banned incoming or outgoing addresses; these should presumably be 352 configured for everyone, but users still need to be able to have 353 their own custom scripts as well. Similarly, an administrative script 354 might perform the necessary operations to allow media to traverse a 355 firewall; but individual users' scripts should not have permission to 356 perform these operations. See the next section for some implications 357 of this. 359 3.6 Feature interaction behavior 361 Feature interaction is the term used in telephony systems when two or 362 more requested features produce ambiguous or conflicting behavior 363 [3]. Feature interaction issues for features implemented with a call 364 processing language can be roughly divided into three categories: 365 feature-to-feature in one server, script-to-script in one server, and 366 server-to-server. 368 3.6.1 Feature-to-feature interactions 370 Due to the explicit nature of event conditions discussed in the 371 previous section, feature-to-feature interaction is not likely to be 372 a problem in a call processing language environment. Whereas a 373 subscriber to traditional telephone features might unthinkingly 374 subscribe to both "call waiting" and "call forward on busy," a user 375 creating a CPL script would only be able to trigger one action in 376 response to the condition "a call arrives while the line is busy." 377 Given a good user interface for creation, or a CPL server which can 378 check for unreachable code in an uploaded script, contradictory 379 condition/action pairs can be avoided. 381 3.6.2 Script-to-script interactions 383 Script-to-script interactions can arise if multiple scripts are 384 invoked for a single call. This can occur in a number of possible 385 cases: if both the call originator and the destination have scripts 386 specified on a single server; if a script forwards a request to 387 another address which also has a script; or if an administrative 388 script is specified as well as a user's individual script. 390 In the first two of these cases, the correct behavior is fairly 391 obvious: the server should first execute the actions specified by the 392 "first" script. In the first case, this is the originator's script; 393 in the second case, this is the script which triggered the request. 394 When the first script says to forward the request to some other 395 address, those actions are considered as new requests which arrive at 396 the second script. When the second script sends back a final 397 response, that response arrives at the first script in the same 398 manner as if a script arrived over the network. Note that for the 399 second type of these interactions, script forwarding can be 400 recursive; a CPL server much be careful to prevent forwarding loops. 402 The correct behavior for the third type of script-to-script 403 interaction depends on the scope of the administrative script. 404 Typically, the administrator's script should run after origination 405 scripts, intercepting any proxy or redirection decisions, and before 406 recipient scripts, to avoid a user's script evading administrative 407 restrictions. 409 3.6.3 Server-to-server interactions 411 The third case of feature interactions, server-to-server 412 interactions, is the most complex of these three. The canonical 413 example of this type of interaction is the combination of Originating 414 Call Screening and Call Forwarding: a user (or administrator) may 415 wish to prevent calls from being placed to a particular address, but 416 the local script has no way of knowing if a call placed to some 417 other, legitimate address will be proxied, by a remote server, to the 418 banned address. This type of problem is unsolvable in an 419 administratively heterogeneous network, even a "lightly" 420 heterogeneous network such as current telephone systems. CPL does not 421 claim to solve it, but the problem is not any worse for CPL scripts 422 than for any other means of deploying services. 424 Another class of server-to-server interactions are best resolved by 425 the underlying signalling protocol, since they can arise whether the 426 signalling servers are being controlled by a call processing language 427 or by some entirely different means. One example of this is 428 forwarding loops, where user X may have calls forwarded to Y, who has 429 calls forwarded back to X. SIP has a mechanism to detect such loops. 430 A call processing language server thus does not need to define any 431 special mechanisms to prevent such occurrences; it should, however, 432 be possible to trigger a different set of call processing actions in 433 the event that a loop is detected, and/or to report back an error to 434 the owner of the script through some standardized run-time error 435 reporting mechanism. 437 3.6.4 Signalling ambiguity 439 As an aside, [3] discusses a fourth type of feature interaction for 440 traditional telephone networks, signalling ambiguity. This can arise 441 when several features overload the same operation in the limited 442 signal path from an end station to the network: for example, flashing 443 the switch-hook can mean both "add a party to a three-way call" and 444 "switch to call waiting." Because of the explicit nature of 445 signalling in both the Internet telephony protocols discussed here, 446 this issue does not arise. 448 3.7 Relationship with existing languages 450 This document's description of the CPL as a "language" is not 451 intended to imply that a new language necessarily needs to be 452 implemented from scratch. A server could potentially implement all 453 the functionality described here as a library or set of extensions 454 for an existing language; Java, or the various freely-available 455 scripting languages (Tcl, Perl, Python, Guile), are obvious 456 possibilities. 458 However, there are motivations for creating a new language. All the 459 existing languages are, naturally, expressively complete; this has 460 two inherent disadvantages. The first is that any function 461 implemented in them can take an arbitrarily long time, use an 462 arbitrarily large amount of memory, and may never terminate. For call 463 processing, this sort of resource usage is probably not necessary, 464 and as described in section 5.1, may in fact be undesirable. One 465 model for this is the electronic mail filtering language Sieve [4], 466 which deliberately restricts itself from being Turing-complete. The 467 second disadvantage with expressively complete languages is that they 468 make automatic generation and parsing very difficult; an analogy can 469 be drawn with the difference between markup languages like HTML or 470 XML, which can easily be manipulated by smart editors, and powerful 471 document programming languages such as Latex or Postscript which 472 usually cannot be. 474 4 Related work 476 4.1 IN service creation environments 478 The ITU's IN series describe, on an abstract level, service creation 479 environments [5]. These describe services in a traditional circuit- 480 switched telephone network as a series of decisions and actions 481 arranged in a directed acyclic graph. Many vendors of IN services use 482 modified and extended versions of this for their proprietary service 483 creation environments. 485 4.2 SIP CGI 487 SIP CGI [6] is an interface for implementing services on SIP servers. 488 Unlike a CPL, it is a very low-level interface, and would not be 489 appropriate for services written by non-trusted users. 491 5 Necessary language features 493 This section lists those properties of a call processing language 494 which we believe to be necessary to have in order to implement the 495 motivating examples, in line with the described architecture. 497 5.1 Language characteristics 499 These are some abstract attributes which any proposed call processing 500 language should possess. 502 o Light-weight, efficient, easy to implement 504 In addition to the general reasons why this is desirable, a 505 network server might conceivably handle very large call volumes, 506 and we don't want CPL execution to be a major bottleneck. One 507 way to achieve this might be to compile scripts before 508 execution. 510 o Easily verifiable for correctness 512 For a script which runs in a server, mis-configurations can 513 result in a user becoming unreachable, making it difficult to 514 indicate run-time errors to a user (though a second-channel 515 error reporting mechanism such as e-mail could ameliorate this). 516 Thus, it should be possible to verify, when the script is 517 committed to the server, that it is at least syntactically 518 correct, does not have any obvious loops or other failure modes, 519 and does not use too many server resources. 521 o Executable in a safe manner 523 No action the CPL script takes should be able to subvert 524 anything about the server which the user shouldn't have access 525 to, or affect the state of other users without permission. 526 Additionally, since CPL scripts will typically run on a server 527 on which users cannot normally run code, either the language or 528 its execution environment must be designed so that scripts 529 cannot use unlimited amounts of network resources, server CPU 530 time, storage, or memory. 532 o Easily writeable and parseable by both humans and machines. 534 For maximum flexibility, we want to allow humans to write their 535 own scripts, or to use and customize script libraries provided 536 by others. However, most users will want to have a more 537 intuitive user-interface for the same functionality, and so will 538 have a program which creates scripts for them. Both cases 539 should be easy; in particular, it should be easy for script 540 editors to read human-generated scripts, and vice-versa. 542 o Extensible 544 It should be possible to add additional features to a language 545 in a way that existing scripts continue to work, and existing 546 servers can easily recognize features they don't understand and 547 safely inform the user of this fact. 549 o Independent of underlying signalling details 551 The same scripts should be usable whether the underlying 552 protocol is SIP, H.323, a traditional telephone network, or any 553 other means of setting up calls. It should also be agnostic to 554 address formats. (We use SIP terminology in our descriptions of 555 requirements, but this should map fairly easily to other 556 systems.) It may also be useful to have the language extend to 557 processing of other sorts of communication, such as e-mail or 558 fax. 560 5.2 Base features -- call signalling 562 To be useful, a call processing language obviously should be able to 563 react to and initiate call signalling events. 565 o Should execute actions when a call request arrives 567 See section 3, particularly 3.5. 569 o Should be able to make decisions based on event properties 571 A number of properties of a call event are relevant for a 572 script's decision process. These include, roughly in order of 573 importance: 575 - Destination address 577 We want to be able to do destination-based routing or 578 screening. Note that in SIP we want to be able to filter 579 on either or both of the addresses in the To header and the 580 Request-URI. 582 - Originator address 584 Similarly, we want to be able to do originator-based 585 screening or routing. 587 - Caller Preferences 589 In SIP, a caller can express preferences about the type of 590 device to be reached -- see [7]. The script should be able 591 to make decisions based on this information. 593 - Information about caller or call 595 SIP has textual fields such as Subject, Organization, 596 Priority, etc., and a display name for addresses; users can 597 also add non-standard additional headers. H.323 has a 598 single Display field. 600 - Media description 602 Requests specify the types of media that will flow, their 603 bandwidth usage, their network destination addresses, etc. 605 - Authentication/encryption status 607 Requests can be authenticated. Many properties of the 608 authentication are relevant: the method of 609 authentication/encryption, who performed the 610 authentication, which specific fields were encrypted, etc. 612 o Should be able to take action based on a request 614 There are a number of actions we can take in response to an 615 incoming request. We can: 617 - reject it 619 We should be able to indicate that the call is not 620 acceptable or not able to be completed. We should also 621 be able to send more specific rejection codes 622 (including, for SIP, the associated textual string, 623 warning codes, or message payload). 625 - send a provisional response to it 627 While a call request is being processed, provisional 628 responses such as "Trying," "Ringing," and "Queued" are 629 sent back to the caller. It is not clear whether the 630 script should specify the sending of such responses 631 explicitly, or whether they should be implicit in other 632 actions performed. 634 - redirect it 636 We should be able to tell the request sender to try a 637 different location. 639 - proxy it 641 We should be able to send the request on to another 642 location, or to several other locations ("branching" the 643 request), and await the responses. It should also be 644 possible to specify a timeout value after which we give 645 up on receiving any definitive responses. 647 o Should be able to take action based a response to a 648 proxied or branched request 650 Once we have proxied requests, we need to be able to make 651 decisions based on the responses we receive to those 652 requests (or the lack thereof). We should be able to: 654 - consider its message fields 656 We should be able to consider the same fields of a 657 response as we consider in the initial request. 659 - relay it on to the requestor 661 If the response is satisfactory, it should be 662 returned to the sender. 664 - for a branch, choose one of several responses to 665 relay back 667 If we branched a request, we obviously expect to 668 receive several responses. There are several issues 669 here -- choosing among the responses, and how long to 670 wait if we've received responses from some but not 671 all destinations. 673 - initiate other actions 675 If we didn't get a response, or any we liked, we 676 should be able to try something else instead (e.g., 677 call forward on busy). 679 5.3 Base features -- non-signalling 681 A number of other features that a call processing language should 682 have do not refer to call signalling per se; however, they are still 683 extremely desirable to implement many useful features. 685 The servers which provide these features might reside in other 686 Internet devices, or might be local to the server (or other 687 possibilities). The language should be independent of the location of 688 these servers, at least at a high level. 690 o Logging 692 In addition to the CPL server's natural logging of events, the 693 user will also want to be able to log arbitrary other items. The 694 actual storage for this logging information might live either 695 locally or remotely. 697 o Error reporting 699 If an unexpected error occurs, the script should be able to 700 report the error to the script's owner. This should use the same 701 mechanism as the script server uses to report language errors to 702 the user (see section 5.5). 704 o Access to user-location info 706 Proxies will often collect information on users' current 707 location, either through SIP REGISTER messages, the H.323 RRQ 708 family of RAS messages, or some other mechanism (see section 709 3.2). The CPL should be able to refer to this information so a 710 call can be forwarded to the registered locations or some subset 711 of them. 713 o Database access 715 Much information for CPL control might be stored in external 716 databases, for example a wide-area address database, or 717 authorization information, for a CPL under administrative 718 control. The language could specify some specific database 719 access protocols (such as SQL or LDAP), or could be more 720 generic. 722 o Other external information 724 Other external information the script should be able to access 725 includes web pages, which could be sent back in a SIP message 726 body; or a clean interface to remote procedure calls such as 727 Corba, RMI, or DCOM, for instance to access an external billing 728 database. 730 5.4 Language features 732 Some features do not involve any operations external to the CPL's 733 execution environment, but are still necessary to allow some standard 734 services to be implemented. (This list is not exhaustive.) 736 o Pattern-matching 738 It should be possible to give special treatment to addresses and 739 other text strings based not only on the full string but also on 740 more general or complex sub-patterns of them. 742 o Address filtering 744 Once a set of addresses has been retrieved through one of the 745 methods in section 5.3, the user needs to be able to choose a 746 sub-set of them, based on their address components or other 747 parameters. 749 o Randomization 751 Some forms of call distribution are randomized as to where they 752 actually end up. 754 o Date/time information 756 Users may wish to condition some services (e.g., call 757 forwarding, call distribution) on the current time of day, day 758 of the week, etc. 760 5.5 Control 761 As described in section 3.4, we must have a mechanism to send and 762 retrieve CPL scripts, and associated data, to and from a signalling 763 server. This method should support reporting upload-time errors to 764 users; we also need some mechanism to report errors to users at 765 script execution time. Authentication is vital, and encryption is 766 very useful. The specification of this mechanism can be (and probably 767 ought to be) a separate specification from that of the call 768 processing language itself. 770 6 Security considerations 772 The security considerations of transferring CPL scripts are discussed 773 in sections 3.4 and 5.5. Some considerations about the execution of 774 the language are discussed in section 5.1. 776 7 Changes from previous versions 778 7.1 Changes from draft-ietf-iptel-cpl-requirements-00 780 The changebars in the Postscript version of this document indicate 781 changes from this version. 783 o Changed the title of the draft from "...Requirements" to 784 "...Framework and Requirements," and changed the draft name, 785 to better reflect the content. 787 o Deleted a number of overambitious service examples that aren't 788 supported in the CPL as it has developed. 790 o Deleted discussion of end systems, media devices, and other 791 items that aren't supported in the CPL as it has developed. 793 o Reorganized the Architecture section. 795 o Clarified the Network Model section. 797 o Added Related Work section. 799 o Added requirement to support caller preferences. 801 o Deleted many requirements for higher-level and end-system 802 features that are not supported in the CPL as it has 803 developed. 805 o Re-worded many sections for clarity. 807 o Added To Do / Open Issues section. 809 8 To Do / Open Issues 811 o Add Terminology section. 813 o How do users find out which servers they should upload their 814 scripts to? 816 o Flesh out the Related Work sections, particularly describing 817 the different roles of CPL and SIP CGI. (As in [8].) 819 o The Control section needs to be fleshed out considerably. 821 o The entire document should be reorganized for clarity. 823 9 Acknowledgments 825 We would like to thank Tom La Porta and Jonathan Rosenberg for their 826 comments and suggestions. 828 10 Authors' Addresses 830 Jonathan Lennox 831 Dept. of Computer Science 832 Columbia University 833 1214 Amsterdam Avenue, MC 0401 834 New York, NY 10027 835 USA 836 electronic mail: lennox@cs.columbia.edu 838 Henning Schulzrinne 839 Dept. of Computer Science 840 Columbia University 841 1214 Amsterdam Avenue, MC 0401 842 New York, NY 10027 843 USA 844 electronic mail: schulzrinne@cs.columbia.edu 846 11 Bibliography 848 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 849 session initiation protocol," Request for Comments (Proposed 850 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 852 [2] International Telecommunication Union, "Visual telephone systems 853 and equipment for local area networks which provide a non-guaranteed 854 quality of service," Recommendation H.323, Telecommunication 855 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 857 [3] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. 858 Schure, and H. Velthuijsen, "A feature interaction benchmark for IN 859 and beyond," Feature Interactions in Telecommunications Systems, IOS 860 Press , pp. 1--23, 1994. 862 [4] T. Showalter, "Sieve: A mail filtering language," Internet Draft, 863 Internet Engineering Task Force, Mar. 1999. Work in progress. 865 [5] International Telecommunication Union, "General recommendations 866 on telephone switching and signaling -- intelligent network: 867 Introduction to intelligent network capability set 1," Recommendation 868 Q.1211, Telecommunication Standardization Sector of ITU, Geneva, 869 Switzerland, Mar. 1993. 871 [6] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway 872 interface for SIP," Internet Draft, Internet Engineering Task Force, 873 May 1999. Work in progress. 875 [7] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 876 callee capabilities," Internet Draft, Internet Engineering Task 877 Force, Mar. 1999. Work in progress. 879 [8] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming 880 internet telephony services," Technical Report CUCS-010-99, Columbia 881 University, New York, New York, Mar. 1999. 883 Full Copyright Statement 885 Copyright (c) The Internet Society (1999). All Rights Reserved. 887 This document and translations of it may be copied and furnished to 888 others, and derivative works that comment on or otherwise explain it 889 or assist in its implementation may be prepared, copied, published 890 and distributed, in whole or in part, without restriction of any 891 kind, provided that the above copyright notice and this paragraph are 892 included on all such copies and derivative works. However, this 893 document itself may not be modified in any way, such as by removing 894 the copyright notice or references to the Internet Society or other 895 Internet organizations, except as needed for the purpose of 896 developing Internet standards in which case the procedures for 897 copyrights defined in the Internet Standards process must be 898 followed, or as required to translate it into languages other than 899 English. 901 The limited permissions granted above are perpetual and will not be 902 revoked by the Internet Society or its successors or assigns. 904 This document and the information contained herein is provided on an 905 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 906 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 907 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 908 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 909 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 911 Table of Contents 913 1 Introduction ........................................ 1 914 2 Motivating examples ................................. 2 915 3 Architecture ........................................ 3 916 3.1 Network components .................................. 3 917 3.2 Network model ....................................... 4 918 3.3 Role of a CPL script ................................ 6 919 3.4 Creation and transport of a call processing 920 language script ................................................ 7 921 3.5 Execution process of a CPL script ................... 7 922 3.6 Feature interaction behavior ........................ 8 923 3.6.1 Feature-to-feature interactions ..................... 8 924 3.6.2 Script-to-script interactions ....................... 9 925 3.6.3 Server-to-server interactions ....................... 9 926 3.6.4 Signalling ambiguity ................................ 10 927 3.7 Relationship with existing languages ................ 10 928 4 Related work ........................................ 11 929 4.1 IN service creation environments .................... 11 930 4.2 SIP CGI ............................................. 11 931 5 Necessary language features ......................... 11 932 5.1 Language characteristics ............................ 11 933 5.2 Base features -- call signalling .................... 12 934 5.3 Base features -- non-signalling ............ 15 935 5.4 Language features ................................... 16 936 5.5 Control ............................................. 16 937 6 Security considerations ............................. 17 938 7 Changes from previous versions ...................... 17 939 7.1 Changes from draft-ietf-iptel-cpl-requirements-00 940 ................................................................ 17 941 8 To Do / Open Issues ................................. 18 942 9 Acknowledgments ..................................... 18 943 10 Authors' Addresses .................................. 18 944 11 Bibliography ........................................ 18