idnits 2.17.1 draft-ietf-iptel-cpl-requirements-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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 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 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 30, 1998) is 9402 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 926 looks like a reference -- Missing reference section? '2' on line 930 looks like a reference -- Missing reference section? '3' on line 935 looks like a reference -- Missing reference section? '4' on line 940 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPTEL WG 3 Internet Draft Lennox/Schulzrinne 4 ietf-iptel-cpl-requirements-00.txt Lucent Bell Labs/Columbia University 5 July 30, 1998 6 Expires: February 1999 8 Call Processing Language Requirements 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 A large number of the services we wish to make possible 33 for Internet telephony require fairly elaborate 34 combinations of signalling operations, often in network 35 devices, to complete. We want a simple and standardized 36 way to create such services to make them easier to 37 implement and deploy. This document describes an 38 architecture for such a method, which we call a call 39 processing language. It also outlines requirements for 40 such a language. 42 1 Introduction 44 Recently, several protocols have been created to allow telephone 45 calls to be made over IP networks, notably SIP [1] and H.323 [2]. 46 These emerging standards have opened up the possibility of a broad 47 and dramatic decentralization of the provisioning of telephone 48 services so they can be under the user's control. 50 Many of these services may reside on end devices. A broad set of 51 services, however -- those involving user location, call 52 distribution, behavior-on-busy, and the like -- are independent of a 53 particular end device, or need to be operational even when an end 54 device is unavailable. These still best reside in a network device 55 rather than an end system. To allow user control over such devices, 56 we need a standardized way for end-users to specify the precise 57 behavior of the servers. This document proposes an architecture in 58 which network devices or end systems respond to call signalling 59 events by triggering user-created programs which control the reaction 60 to the events. 62 For reasons discussed in section 3.7, this document proposes a 63 relatively static, non-expressively-complete language to solve this 64 problem. We call this a call processing language. However, most of 65 the requirements this document lists apply equally well to a library 66 of call processing routines for an existing language. 68 2 Motivating examples 70 These are some specific examples of services which we want to be able 71 to create programatically. They are arranged roughly in order of 72 increasing requirements they impose. Note that some of these examples 73 are deliberately somewhat complicated, so as to demonstrate the level 74 of decision logic that should be possible. 76 o Call forward on busy/no answer 78 When a new call comes in, the call should ring at the user's 79 desk telephone. If it is busy, the call should always be 80 redirected to the user's voicemail box. If, instead, there's no 81 answer after four rings, it should also be redirected to his or 82 her voicemail, unless it's from a superviser, in which case it 83 should be proxied to the user's cellphone if it has registered. 85 o Administrative screening -- firewall 87 An outgoing call should be rejected if it is going to any 88 destination that is on a "banned" list. Otherwise, it should be 89 forwarded on to the appropriate destination; if the destination 90 accepts the call, the firewall should be told to open up the UDP 91 host/port pairs the two endpoints specified for their media. The 92 same thing should be done for incoming calls, checking the 93 origination address. 95 o Central phone server 97 If a call comes in for a specific person, it should be 98 redirected to the locations where they can currently be found. 99 If a call comes in for the general "information" address we've 100 advertised, if it's currently working hours, the caller should 101 be given a list of the people currently willing to accept 102 general information calls; if it's outside of working hours, the 103 caller gets a recorded message indicating what times they can 104 call. 106 o Intelligent user location 108 When a call comes in, it should ring at every station from which 109 the user has registered. If the user picks up from more than one 110 station, the pick-ups should be reported back separately to the 111 calling party. 113 o Intelligent user location with media knowledge 115 When a call comes in, the call should be proxied to the station 116 the user has registered from whose media capabilities best match 117 those specified in the call request. If the user does not pick 118 up from that station within four rings, the call should be 119 proxied to the other stations from which he or she has 120 registered, sequentially, in order of decreasing closeness of 121 match. 123 o Intelligent user location with mixer (home phone) 125 When a call comes in, it should ring at every station from which 126 the user has registered. If the call is picked up from more than 127 one station, the media from each station should be transparently 128 mixed together and sent to the caller. 130 o Third-party registration control 132 When a registration arrives for a user, make sure that the 133 registration was authenticated, the person performing the 134 registration has permission to perform the registration for the 135 specified user, and the location registered is allowed for the 136 registered user. If so, enter it in the registration database; 137 if not, reject it. 139 o Calendarbook access 141 When a call comes in, the user's on-line calendar should be 142 consulted. If it specifies that the user has a meeting scheduled 143 for this time, the caller should get a busy indication. 144 Otherwise, the call should be directed to the user's office 145 telephone. 147 o Client billing allocation -- lawyer's office 149 When a call comes in, the calling address is correlated with the 150 corresponding client, and client's name and the time and 151 duration of the call are logged. If no corresponding client is 152 found, the call is forwarded to the lawyer's secretary. 154 o End system busy 156 When a new call comes in, if the user is currently in a call, a 157 call-waiting tone is generated, unless one of the calls 158 currently in progress is with the user's boss or he or she has 159 set "Do Not Disturb" in the user interface, in which case the 160 caller gets a busy indication. 162 o Phone bank (call distribution/queueing) 164 Incoming calls should be distributed to the phone-bank workers, 165 so that each worker handles approximately the same total number 166 of calls. If all the phone-bank workers are busy, calls should 167 be queued until someone is available. Calls coming from 168 preferred customers should get priority in the queue. If the 169 length of the queue grows to twice the size of the phone bank, 170 calls should be directed to management as well until the queue 171 length has decreased again. Each caller should be given an 172 approximate indication of waiting time or number of calls ahead 173 of them in the queue as they wait. Callers should be given the 174 option of listening to the music-on-hold of their choice. 176 3 Architecture 178 3.1 Network components 180 A network which supports Internet telephony consists of two types of 181 components: end systems, which originate and/or receive media, and 182 network systems, which relay signalling information. 184 End systems are either user agents, which reach actual people, or 185 automated systems, which do not; this document will deal primarily 186 with the former. Network systems, in SIP, are proxy servers, 187 redirect servers, or registrars; in H.323 they are gatekeepers. The 188 functionality between the two protocols is largely equivalent, and 189 this document will generally use the SIP names. Proxy servers are 190 network systems which receive a request and forward it on. Redirect 191 servers tell the originating location an alternate location to try. 192 Registrars track users' current locations; they will usually be the 193 same devices as proxy or redirect servers, but do not necessarily 194 have to be. See the illustrations in [1]. End systems may also have 195 some properties of network systems, most likely the ability to 196 perform redirection. 198 3.2 Model of normal use 200 Local Signalling Server Remote Signalling Server 201 locates destination finds location for 202 permanent address 203 _______ Local server contacts _______ _______ 204 | | permanent address | | | | 205 | | --------------------------------------> | | ----->| | 206 |_____| Local address |_____| |_____| 207 ^ ----- server con- permanent -------> \ Search Another 208 Send to / \-----------\ /---------/ \ for Terminal 209 local / X \ User 210 server/ contacts / \ tacts terminal _| 211 _______ Originator ---------/ \----------- address _______ 212 | | ----------/ \-------> | | 213 | | ----------------------------------------------> | | 214 |_____| Direct connection to terminal address |_____| 215 Terminal 216 Originator has terminal address 218 Figure 1: Illustration of call signalling messages 220 Internet telephony addresses can be divided into two broad 221 categories: terminal addresses and permanent user addresses. A 222 terminal address is one that refers to a particular device, whose 223 network-level (IP) address does not change. A permanent user address, 224 on the other hand, refers on a more abstract level to an individual 225 user, whose current location and network address may change. When a 226 user becomes available at a location, his or her end system registers 227 itself with a network server indicating this fact. (In SIP, users 228 register via the REGISTER message; in H.323, via RRQ and related RAS 229 messages.) A user may register from more than one location 230 simultaneously. 232 Figure 1 shows how call signalling may flow. Calls may be placed 233 either to terminal or permanent user addresses. Calls to terminal 234 addresses may contact the corresponding device directly, or may 235 travel through some signalling server. Calls to permanent user 236 addresses must pass through the signalling server, which locates the 237 user and proxies or redirects the call to the appropriate terminal 238 addresses which the user has registered. 240 Signalling servers may also be used on the originating side. Rather 241 than locate a call's destination on its own, an end system, when 242 originating a call, may have been configured to transfer all its call 243 requests through a single, presumably local, server. This server can 244 then perform the somewhat complex task of actually locating the 245 destination, as well as other tasks such as firewall penetration or 246 encryption of signalling information. 248 Call requests may be forwarded between multiple signalling servers on 249 both the origination and destination ends of a call. For example, a 250 corporation could have a large company-wide server which forwards 251 incoming call requests to individual departmental servers, which then 252 perform the task of actually locating the desired user. This is 253 similar to a typical configuration of e-mail forwarding. 255 Different call invitations for a particular end system might travel 256 through a different set of signalling servers; for instance, a user 257 with several addresses might register his current end system with 258 several different servers. Similarly, an end system placing a call 259 might have several different outgoing signalling servers through 260 which it could place the call. Thus, in general, a signalling server 261 does not see all the signalling events for a particular end system; 262 and so it does not have enough information to be able to determine 263 the end system's state. 265 3.3 Purpose of a call processing language 267 A call processing language (CPL) is primarily intended to allow the 268 user to modify the way an Internet telephony system handles call 269 events. Call events include signalling events such as call setup, 270 termination, or parameter changes, and also, for servers with an 271 appropriate media path, in-band events such as DTMF tones. The user 272 can modify either incoming or outgoing calls. 274 The most common sort of modification will be for incoming call 275 setups. Some ways a user might want to alter the call setup process 276 include: to search terminal addresses for a given user address in an 277 alternate way; to specificy what happens when the initial search 278 fails, either when it receives some sort of negative response (e.g., 279 busy), or does not receive any definitive response within a fixed 280 time period (e.g., no answer); or to handle certain origination 281 addresses specially, for instance by informing the caller that the 282 call was refused. The useful changes to the outgoing call setup are 283 somewhat more limited in scope, but one example is to translate a 284 user's abbreviated addresses into an address specified with a fully- 285 qualified domain name. The transformations to parameter changes or 286 call terminations are generally only useful to complete the actions 287 begun at call setup time; see for instance the lawyer's office 288 example in section 2. 290 Once a language with this level of power has been introduced, other 291 applications of it present themselves. An administrator might wish to 292 perform administrative restrictions on users' calls, for instance 293 blocking incoming or outgoing calls from certain domains. The 294 language could also be scripted on an end system; with minimal 295 extensions, behavior specific to end systems, such as the specifics 296 of how the user is alerted to incoming calls, could also be made 297 programmable. 299 3.4 Creation and transport of a call processing language script 301 Users create call processing language scripts, typically on end 302 devices, and transmit them through the network to network systems. 303 Scripts persist in network devices until changed or deleted, unless 304 they are specifically given an expiration time; a network device 305 which supports CPL scripting will need stable storage. 307 The exact means by which the end device transmits the script to the 308 server remains to be determined; it is likely that many solutions 309 will be able to co-exist. This method will need to be authenticated 310 in almost all cases. The methods that have been suggested include 311 web access, SIP REGISTER message payloads, remote method invocation, 312 SNMP, LDAP, and remote file systems such as NFS. 314 Creation of a CPL script may be through the creation of a text file; 315 or for a simpler user experience, a graphical user interface which 316 allows the manipulation of some basic rules. 318 The end device on which the user creates the CPL script need not bear 319 any relationship to the end devices to which calls are actually 320 placed. For example, a CPL script might be created on a PC, whereas 321 calls might be intended to be received on a simple audio-only 322 telephone. The CPL also might not necessarily be created on a device 323 near either the end device or the signalling server in network terms; 324 a user might, for example, decide to forward his or her calls to a 325 remote location only after arriving at that location. 327 Users can also retrieve their current script from the network to an 328 end system so it can be edited. The signalling server should also be 329 able to report errors related to the script to the user, both static 330 errors that could be detected at upload time, and any run-time errors 331 that occur. 333 If a user's calls will pass through multiple local signalling servers 334 which know about that user (as discussed in section 3.2), the user 335 may choose to upload scripts to any or all of those servers. These 336 scripts can be entirely independent; see section 3.6 for some 337 implications of this. 339 If, as discussed in section 3.3, the call processing language is 340 extended to control end systems, the script-creation mechanism 341 described above should also be able to create such end-system 342 scripts. It may be possible that the end system on which the script 343 executes (the simple telephone mentioned before) is not the same 344 device as the end system on which the script is created; in this 345 case, the script should be transmitted from the script creation site 346 to the end system in the same way it is transmitted from creation 347 sites to network systems. 349 3.5 Execution process of a CPL script 351 When a call event arrives, a CPL server considers the information in 352 the request and determines if any of the scripts it has stored are 353 applicable to the call in question. If so, it performs the actions 354 corresponding to the matching scripts. 356 The most common type of script defines a set of actions to be taken 357 for the entire process of call set-up -- from the time a call request 358 is initially received, to the time that (from the point of view of 359 this device) the call is either definitively accepted or definitively 360 rejected. This could be near-instantaneous, if, for instance, the 361 script decides to reject the call; or it could be an arbitrarily long 362 time, if we are waiting for a call pick-up without a timeout. 364 Generally, we expect a script to be structured as a list of 365 condition/action pairs; if an incoming invitation matches a given 366 condition, then the corresponding action (or more properly set of 367 actions) will be taken. Whether this should be explicit in the 368 language or just implicit in the normal usage remains to be seen. If 369 no condition matches the invitation, the signalling server's standard 370 action should be taken. 372 Other types of scripts may define sets of actions to be taken for 373 other call events: call termination; changes to media format or other 374 call parameters (re-invitations, in SIP); or in-band call events, 375 such as a user sending DTMF tones. However, it is important to note 376 that many, if not most, network servers cannot expect to be able to 377 observe such events; subsequent signalling information may short-cut 378 past the server, as media information almost certainly will. 380 While many of the uses of a CPL script are specific to one particular 381 user, there are a number of circumstances in which an administrator 382 of a signalling server would wish to provide a script which applies 383 to all users of the server, or a large set of them. For instance, a 384 system might be configured to prevent calls from or to a list of 385 banned incoming or outgoing addresses; these should presumably be 386 configured for everyone, but users still need to be able to have 387 their own custom scripts as well. Similarly, an administrative script 388 might perform the necessary operations to allow media to traverse a 389 firewall; but individual users' scripts should not have permission to 390 perform these operations. See the next section for some implications 391 of this. 393 3.6 Feature interaction behavior 395 Feature interaction is the term used in telephony systems when two or 396 more requested features produce ambiguous or conflicting behavior 397 [3]. Feature interaction issues for features implemented with a call 398 processing language can be roughly divided into three categories: 399 feature-to-feature in one server, script-to-script in one server, and 400 server-to-server. 402 Due to the explicit nature of event conditions discussed in the 403 previous section, feature-to-feature interaction is not likely to be 404 a problem in a call processing language environment. Whereas a 405 subscriber to traditional telephone features might unthinkingly 406 subscribe to both "call waiting" and "call forward on busy," a user 407 creating a CPL script would only be able to trigger one action in 408 response to the condition "a call arrives while the line is busy." 409 Given a good user interface for creation, or a CPL server which can 410 check for unreachable code in an uploaded script, contradictory 411 condition/action pairs can be avoided. 413 Script-to-script interactions can arise if both an originator and a 414 destination have scripts specified on the same signalling server, or 415 if an administrative script and a user's script are both specified. 416 In the former case, the correct behavior is fairly obvious: a server 417 should first execute the originator's script, and then, if that 418 script placed a call to a destination, call the destination script 419 with the appropriate conditions. 421 The correct behavior in the latter case depends on the scope of the 422 administrative script; however, normally, the administrator's script 423 should run after origination scripts, intercepting any proxy or 424 redirection decisions, and before recipient scripts, to avoid a 425 user's script evading administrative restrictions. 427 The third case -- server-to-server interactions -- is the most 428 complex of these three. Many such problems are unsolvable in an 429 administratively heterogeneous network, even a "lightly" 430 heterogeneous network such as current telephone systems. The 431 canonical example of this is the interaction of Originating Call 432 Screening and Call Forwarding: a user (or administrator) may wish to 433 prevent calls from being placed to a particular address, but the 434 local script has no way of knowing if a call placed to some other, 435 legitimate address will be proxied, by a remote server, to the banned 436 address. 438 Another class of server-to-server interactions are best resolved by 439 the underlying signalling protocol, since they can arise whether the 440 signalling servers are being controlled by a call processing language 441 or by some entirely different means. One example of this is 442 forwarding loops, where user X may have calls forwarded to Y, who has 443 calls forwarded back to X. SIP has a mechanism to detect such loops. 444 A call processing language server thus does not need to define any 445 special mechanisms to prevent such occurrences; it should, however, 446 be possible to trigger a different set of call processing actions in 447 the event that a loop is detected, and/or to report back an error to 448 the owner of the script through some standardized run-time error 449 reporting mechanism. 451 As an aside, [3] discusses a fourth type of feature interaction for 452 traditional telephone networks, signalling ambiguity. This can arise 453 when several features overload the same operation in the limited 454 signal path from an end station to the network, for example, flashing 455 the switch-hook can mean both "add a party to a three-way call" and 456 "switch to call waiting." Because of the explicit nature of 457 signalling in both the Internet telephony protocols discussed here, 458 this issue does not arise. 460 3.7 Relationship with existing languages 462 This document's description of the CPL as a "language" is not 463 intended to imply that a new language necessarily needs to be 464 implemented from scratch. A server could potentially implement all 465 the functionality described here as a library or set of extensions 466 for an existing language; Java, or the various freely-available 467 scripting languages (Tcl, Perl, Python, Guile), are obvious 468 possibilities. 470 However, there are motivations for creating a new language. All the 471 existing languages are, naturally, expressively complete; this has 472 two inherent disadvantages. The first is that any function 473 implemented in them can take an arbitrarily long time, use an 474 arbitrarily large amount of memory, and may never terminate. For call 475 processing, this sort of resource usage is probably not necessary, 476 and as described in section 5.1, may in fact be undesirable. One 477 model for this is the electronic mail filtering language Sieve [4], 478 which deliberately restricts itself from being Turing-complete. The 479 second disadvantage with expressively complete languages is that they 480 make automatic generation and parsing very difficult; an analogy can 481 be drawn with the difference between markup languages like HTML or 482 XML, which can easily be manipulated by smart editors, and powerful 483 document programming languages such as Latex or Postscript which 484 usually cannot be. 486 4 Related work 488 A future revision of this document will discuss such items as 489 decision tree languages, AT&T's TOPS language, the IN service 490 creation language, timed state diagrams, the Java servlet API, cgi- 491 bin, and active networks. 493 5 Necessary language features 495 This section lists those properties of a call processing language 496 which we believe to be necessary to have in order to implement the 497 motivating examples, in line with the described architecture. 499 5.1 Language characteristics 501 These are some abstract attributes which any proposed call processing 502 language should possess. 504 o Light-weight, efficient, easy to implement 506 In addition to the general reasons why this is desirable, a 507 network server might conceivably handle very large call volumes, 508 and we don't want CPL execution to be a major bottleneck. One 509 way to achieve this might be to compile scripts before 510 execution. 512 o Easily verifiable for correctness 514 For a script which runs in a server, mis-configurations can 515 result in a user becoming unreachable, making it difficult to 516 indicate run-time errors to a user (though a second-channel 517 error reporting mechanism such as e-mail could ameliorate this). 519 Thus, it should be possible to verify, when the script is 520 committed to the server, that it is at least syntactically 521 correct, does not have any obvious loops or other failure modes, 522 and does not use too many server resources. 524 o Executable in a safe manner 526 No action the CPL script takes should be able to subvert 527 anything about the server which the user shouldn't have access 528 to, or affect the state of other users without permission. 529 Additionally, since CPL scripts will typically run on a server 530 on which users cannot normally run code, either the language or 531 its execution environment must be designed so that scripts 532 cannot use unlimited amounts of network resources, server CPU 533 time, storage, or memory. 535 o Easily writeable and parseable by both humans and machines. 537 For maximum flexibility, we want to allow humans to write their 538 own scripts, or to use and customize script libraries provided 539 by others. However, most users will want to have a more 540 intuitive user-interface for the same functionality, and so will 541 have a program which creates scripts for them. Both cases 542 should be easy; in particular, it should be easy for script 543 editors to read human-generated scripts, and vice-versa. 545 o Extensible 547 It should be possible to add additional features to a language 548 in a way that existing scripts continue to work, and existing 549 servers can easily recognize features they don't understand and 550 safely inform the user of this fact. 552 o Independent of underlying signalling details 554 The same scripts should be usable whether the underlying 555 protocol is SIP, H.323, a traditional telephone network, or any 556 other means of setting up calls. It should also be agnostic to 557 address formats. (We use SIP terminology in our descriptions of 558 requirements, but this should map fairly easily to other 559 systems.) It may also be useful to have the language extend to 560 processing of other sorts of communication, such as e-mail or 561 fax. 563 5.2 Base features -- call signalling 565 To be useful, a call processing language obviously should be able to 566 react to and initiate call signalling events. 568 o Should execute an action script when a call request arrives 570 See section 3, particularly 3.5. 572 o Should be able to make decisions based on event properties 574 A number of properties of a call event are relevant for a 575 script's decision process. These include, roughly in order of 576 importance: 578 - Event type 580 It should be possible to handle call invitations, call 581 terminations, user registrations, OPTIONS requests, and 582 other distinct call events separately. 584 - Originator address 586 We want to be able to do originator-based screening or 587 routing. 589 - Destination address 591 Similarly, we want to be able to do destination-based 592 screening or routing. Note that in SIP we want to be able 593 to filter on any or all of the addresses in the To header, 594 the Location header, and the Request-URI. 596 - Information about caller or call 598 SIP has textual fields such as Subject, Organization, 599 Priority, etc., and a display name for addresses; users can 600 also add non-standard additional headers. H.323 has a 601 single Display field. 603 - Media description 605 Requests specify the types of media that will flow, their 606 bandwidth usage, their network destination addresses, etc. 608 - Authentication/encryption status 610 Requests can be authenticated. Many properties of the 611 authentication are relevant: the method of 612 authentication/encryption, who performed the 613 authentication, which specific fields were encrypted, etc. 615 o Should be able to take action based on a request 616 There are a number of actions we can take in response to an 617 incoming request. We can: 619 - reject it 621 We should be able to indicate that the call is not 622 acceptable or not able to be completed. We should also 623 be able to send more specific rejection codes 624 (including, for SIP, the associated textual string, 625 warning codes, or message payload). 627 - send a provisional response to it 629 While a call request is being processed, provisional 630 responses such as "Trying," "Ringing," and "Queued" are 631 sent back to the caller. It is not clear whether the 632 script should specify the sending of such responses 633 explicitly, or whether they should be implicit in other 634 actions performed. 636 - redirect it 638 We should be able to tell the request sender to try a 639 different location. 641 - proxy it 643 We should be able to send the request on to another 644 location, or to several other locations, and await the 645 responses. It should also be possible to specify a 646 timeout value after which we give up on receiving any 647 definitive responses. 649 o Should be able to take action based a response to a 650 proxied or forked request 652 Once we have proxied requests, we need to be able to make 653 decisions based on the responses we receive to those 654 requests (or the lack thereof). We should be able to: 656 - consider all its message fields 658 This consists of a similar set of fields as appear in 659 a request. 661 - relay it on to the requestor 663 If the response is satisfactory, it should be 664 returned to the sender. 666 - for a fork, choose one of several responses to 667 relay back 669 If we forked a request, we obviously expect to 670 receive several responses. There are several issues 671 here -- choosing among the responses, and how long to 672 wait if we've received responses from some but not 673 all destinations. 675 - initiate other actions 677 If we didn't get a response, or any we liked, we 678 should be able to try something else instead (e.g., 679 call forward on busy). 681 5.3 Base features -- non-signalling 683 A number of other features that a call processing language should 684 have do not refer to call signalling per se; however, they are still 685 extremely desirable to implement many useful features. 687 The servers which provide these features might reside in other 688 Internet devices, or might be local to the server (or other 689 possibilities). The language should be independent of the location of 690 these servers, at least at a high level. 692 o Logging 694 In addition to the CPL server's natural logging of events, the 695 user will also want to be able to log arbitrary other items. The 696 actual storage for this logging information might live either 697 locally or remotely. 699 o Error reporting 701 If an unexpected error occurs, the script should be able to 702 report the error to the script's owner. This should use the same 703 mechanism as the script server uses to report language errors to 704 the user (see section 5.9). 706 o Access to user-location info 708 Proxies will often collect information on users' current 709 location, either through SIP REGISTER messages, the H.323 RRQ 710 family of RAS messages, or some other mechanism (see section 711 3.2). The CPL should be able to refer to this information so a 712 call can be forwarded to the registered locations or some subset 713 of them. 715 o Database access 717 Much information for CPL control might be stored in external 718 databases, for example a wide-area address database, or 719 authorization information, for a CPL under administrative 720 control. The language could specify some specific database 721 access protocols (such as SQL or LDAP), or could be more 722 generic. 724 o Other external information 726 Other external information the script should be able to access 727 includes web pages, which could be sent back in a SIP message 728 body; or a clean interface to remote procedure calls such as 729 Corba, RMI, or DCOM, for instance to access an external billing 730 database. 732 o Creation of and access to local state 734 A CPL script may wish to store state information, so that 735 scripts invoked for future transactions related to this call or 736 this user can have access to decisions made by an earlier 737 invocation. For instance, a SIP re-invitation should be proxied 738 to the same location as accepted the original invitation, 739 regardless of the usual forwarding sequence; a server may wish 740 to log the termination of a call in the same way it logged its 741 initiation; or a user might want to limit the number of 742 concurrent calls or calls per day allowed. The persistence of 743 this state information for a call should be time-limited, either 744 explicitly or by default. See section 3.5 for some caveats for a 745 network system of expecting to receive events other than call 746 initiation. 748 5.4 Higher-level features 750 There are some, more complex services which it would be quite useful 751 to be able to describe with a CPL, but which require considerably 752 more maintenance of state, elaborate inter-call event triggering, and 753 so forth, than the features described earlier. 755 It is not clear whether these features should be specified as 756 primitives of the language, or whether they should be assembled from 757 lower-level features. In the latter case, the language may need to 758 have additional low-level features added, beyond those specified in 759 the previous sections, so these features can be constructed. 761 o Queueing 763 Calls which should go to end systems which aren't accepting 764 calls currently can be queued to await delivery. This requires 765 inter-call synchronization to know when to take calls off the 766 queue. 768 It should be possible for the CPL to specify a priority for a 769 queue entry. 771 o Call distribution 773 Calls can be spread to a number of end systems, in a "phone 774 bank" style set-up. Calls need to be directed to exactly one, 775 currently available destination, in some fair manner (e.g., 776 hierarchical, round-robin, randomly distributed, or weighted 777 fair queueing). In many cases, this means that the proxy system 778 needs to be able to track the state of end systems. 780 This should also be able to interface with queueing -- if all 781 end systems are busy, the call is queued, and when one becomes 782 free, the call is taken off the queue. 784 5.5 Contingent features 786 Some features are only useful if other network entities are 787 available. 789 o Access to media servers 791 We want to be able to connect a remote call to recorded audio 792 (or video) messages. 794 o Firewall control 796 If we are working in an environment with a firewall, we need to 797 be able to tell it to open up a specific host/port 5-tuple for 798 our media to flow through. 800 We should be able to specify authentication so the firewall 801 knows it can trust the proxy. 803 o Mixer/translator control 805 If we have a media mixer or translator available, we want to be 806 able to tell it to mix media between several addresses, with 807 fine-grained control over what media flows to where, in what 808 formats. 810 5.6 End-system specific features 812 Some features can only be implemented in end-systems, either because 813 some end-system state is not generally communicated over the network, 814 or because there is no protocol to signal that actions need to be 815 performed. If we want these features to be implementable with the 816 CPL, these additional operations will be necessary. 818 o Access to current calling state 820 We want to know how many other calls are in progress, who they 821 are with, etc. 823 o Access to additional user interface state 825 The end system's user interface might present options which the 826 user could specify on a per-call basis (for example, setting "do 827 not disturb"). 829 o Control of user notification UI 831 This will allow such features as custom distinctive ringing, 832 call-waiting tones (in combination with the call-state query), 833 "reminder ring" for call forwarding, etc. 835 5.7 Language features 837 Some features do not involve any operations external to the CPL's 838 execution environment, but are still necessary to allow some standard 839 services to be implemented. (This list is not exhaustive.) 841 o Pattern-matching 843 It should be possible to give special treatment to addresses and 844 other text strings based not only on the full string but also on 845 more general or complex sub-patterns of them. 847 o Randomization 849 Some forms of call distribution are randomized as to where they 850 actually end up. 852 o Date/time information 854 Users may wish to condition some services (e.g., call 855 forwarding, call distribution) on the current time of day, day 856 of the week, etc. 858 5.8 Future features 860 A number of services which don't exist yet or aren't widely deployed 861 in the Internet will be relevant for Internet telephony. Once they 862 are available, a CPL script should be able to control them. 864 o Ability to specify quality-of-service 866 Certain calls -- either on the basis of importance, or for 867 known-troublesome destinations -- should be able to have their 868 desired quality of service specified by the language. 870 o Access to wide-area service location information 872 A proxy doing call distribution might want to locate the service 873 "closest" (in any one of a number of senses) to the caller; or 874 we might want to find a PSTN gateway close to the destination of 875 a PSTN-style call. In either case a script should be able to 876 control these operations. 878 o Control of payment authorization 880 If any kind of per-call billing is required, a CPL might want to 881 be able to decide whether to accept charges. This is obviously a 882 rather delicate operation from a security standpoint. 884 5.9 Control 886 As described in section 3.4, we must have a mechanism to send and 887 retrieve CPL scripts, and associated data, to and from a signalling 888 server. This method should support reporting upload-time errors to 889 users; we also need some mechanism to report errors to users at 890 script execution time. Authentication is vital, and encryption is 891 very useful. The specification of this mechanism can be (and probably 892 ought to be) a separate specification from that of the call 893 processing language itself. 895 6 Security considerations 897 The security considerations of transferring CPL scripts are discussed 898 in sections 3.4 and 5.9. Some considerations about the execution of 899 the language are discussed in section 5.1. 901 7 Acknowledgments 903 We would like to thank Tom La Porta and Jonathan Rosenberg for their 904 comments and suggestions. 906 8 Authors' Addresses 908 Jonathan Lennox 909 Lucent Technologies, Bell Laboratories 910 Rm. 4F-520 911 101 Crawfords Corner Road 912 Holmdel, NJ 07733 913 USA 914 electronic mail: lennox@dnrc.bell-labs.com 916 Henning Schulzrinne 917 Dept. of Computer Science 918 Columbia University 919 1214 Amsterdam Avenue 920 New York, NY 10027 921 USA 922 electronic mail: schulzrinne@cs.columbia.edu 924 9 Bibliography 926 [1] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: session 927 initiation protocol," Internet Draft, Internet Engineering Task 928 Force, May 1998. Work in progress. 930 [2] International Telecommunication Union, "Visual telephone systems 931 and equipment for local area networks which provide a non-guaranteed 932 quality of service," Recommendation H.323, Telecommunication 933 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 935 [3] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, and et 936 al, "A feature interaction benchmark for IN and beyond," Feature 937 Interactions in Telecommunications Systems, IOS Press , pp. 1--23, 938 1994. 940 [4] T. Showalter, "Sieve -- a mail filtering language," Internet 941 Draft, Internet Engineering Task Force, Jan. 1998. Work in progress. 943 Full Copyright Statement 945 Copyright (c) The Internet Society (1998). All Rights Reserved. 947 This document and translations of it may be copied and furnished to 948 others, and derivative works that comment on or otherwise explain it 949 or assist in its implementation may be prepared, copied, published 950 and distributed, in whole or in part, without restriction of any 951 kind, provided that the above copyright notice and this paragraph are 952 included on all such copies and derivative works. However, this 953 document itself may not be modified in any way, such as by removing 954 the copyright notice or references to the Internet Society or other 955 Internet organizations, except as needed for the purpose of 956 developing Internet standards in which case the procedures for 957 copyrights defined in the Internet Standards process must be 958 followed, or as required to translate it into languages other than 959 English. 961 The limited permissions granted above are perpetual and will not be 962 revoked by the Internet Society or its successors or assigns. 964 This document and the information contained herein is provided on an 965 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 966 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 967 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 968 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 969 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 971 Table of Contents 973 1 Introduction ........................................ 1 974 2 Motivating examples ................................. 2 975 3 Architecture ........................................ 4 976 3.1 Network components .................................. 4 977 3.2 Model of normal use ................................. 5 978 3.3 Purpose of a call processing language ............... 6 979 3.4 Creation and transport of a call processing 980 language script ................................................ 7 981 3.5 Execution process of a CPL script ................... 8 982 3.6 Feature interaction behavior ........................ 9 983 3.7 Relationship with existing languages ................ 10 984 4 Related work ........................................ 11 985 5 Necessary language features ......................... 11 986 5.1 Language characteristics ............................ 11 987 5.2 Base features -- call signalling .................... 12 988 5.3 Base features -- non-signalling ............ 15 989 5.4 Higher-level features ............................... 16 990 5.5 Contingent features ................................. 17 991 5.6 End-system specific features ........................ 18 992 5.7 Language features ................................... 18 993 5.8 Future features ..................................... 19 994 5.9 Control ............................................. 19 995 6 Security considerations ............................. 19 996 7 Acknowledgments ..................................... 19 997 8 Authors' Addresses .................................. 20 998 9 Bibliography ........................................ 20