📄 rfc2824.txt
字号:
Network Working Group J. Lennox
Request for Comments: 2824 H. Schulzrinne
Category: Informational Columbia University
May 2000
Call Processing Language Framework and Requirements
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
A large number of the services we wish to make possible for Internet
telephony require fairly elaborate combinations of signalling
operations, often in network devices, to complete. We want a simple
and standardized way to create such services to make them easier to
implement and deploy. This document describes an architectural
framework for such a mechanism, which we call a call processing
language. It also outlines requirements for such a language.
Table of Contents
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Example services .................................... 4
4 Usage scenarios ..................................... 6
5 CPL creation ........................................ 6
6 Network model ....................................... 7
6.1 Model components .................................... 7
6.1.1 End systems ......................................... 7
6.1.2 Signalling servers .................................. 8
6.2 Component interactions .............................. 8
7 Interaction of CPL with network model ............... 10
7.1 What a script does .................................. 10
7.2 Which script is executed ............................ 11
7.3 Where a script runs ................................. 12
8 Creation and transport of a call processing
language script ..................................... 12
9 Feature interaction behavior ........................ 13
9.1 Feature-to-feature interactions ..................... 13
Lennox & Schulzrinne Informational [Page 1]
RFC 2824 CPL-F May 2000
9.2 Script-to-script interactions ....................... 14
9.3 Server-to-server interactions ....................... 15
9.4 Signalling ambiguity ................................ 15
10 Relationship with existing languages ................ 15
11 Related work ........................................ 17
11.1 IN service creation environments .................... 17
11.2 SIP CGI ............................................. 17
12 Necessary language features ......................... 17
12.1 Language characteristics ............................ 17
12.2 Base features -- call signalling .................... 19
12.3 Base features -- non-signalling ..................... 21
12.4 Language features ................................... 22
12.5 Control ............................................. 23
13 Security Considerations ............................. 23
14 Acknowledgments ..................................... 23
15 Authors' Addresses .................................. 23
16 Bibliography ........................................ 24
17 Full Copyright Statement ............................ 25
1 Introduction
Recently, several protocols have been created to allow telephone
calls to be made over IP networks, notably SIP [1] and H.323 [2].
These emerging standards have opened up the possibility of a broad
and dramatic decentralization of the provisioning of telephone
services so they can be under the user's control.
Many Internet telephony services can, and should, be implemented
entirely on end devices. Multi-party calls, for instance, or call
waiting alert tones, or camp-on services, depend heavily on end-
system state and on the specific content of media streams,
information which often is only available to the end system. A
variety of services, however -- those involving user location, call
distribution, behavior when end systems are busy, and the like -- are
independent of a particular end device, or need to be operational
even when an end device is unavailable. These services are still best
located in a network device, rather than in an end system.
Traditionally, network-based services have been created only by
service providers. Service creation typically involved using
proprietary or restricted tools, and there was little range for
customization or enhancement by end users. In the Internet
environment, however, this changes. Global connectivity and open
protocols allow end users or third parties to design and implement
new or customized services, and to deploy and modify their services
dynamically without requiring a service provider to act as an
intermediary.
Lennox & Schulzrinne Informational [Page 2]
RFC 2824 CPL-F May 2000
A number of Internet applications have such customization
environments -- the web has CGI [3], for instance, and e-mail has
Sieve [4] or procmail. To create such an open customization
environment for Internet telephony, we need a standardized, safe way
for these new service creators to describe the desired behavior of
network servers.
This document describes an architecture in which network devices
respond to call signalling events by triggering user-created programs
written in a simple, static, non-expressively-complete language. We
call this language a call processing language.
The development of this document has been substantially informed by
the development of a particular call processing language, as
described in [5]. In general, when this document refers to "a call
processing language," it is referring to a generic language that
fills this role; "the call processing language" or "the CPL" refers
to this particular language.
2 Terminology
In this section we define some of the terminology used in this
document.
SIP [1] terminology used includes:
invitation: The initial INVITE request of a SIP transaction, by
which one party initiates a call with another.
redirect server: A SIP device which responds to invitations and
other requests by informing the request originator of an
alternate address to which the request should be sent.
proxy server: A SIP device which receives invitations and other
requests, and forwards them to other SIP devices. It then
receives the responses to the requests it forwarded, and
forwards them back to the sender of the initial request.
user agent: A SIP device which creates and receives requests, so
as to set up or otherwise affect the state of a call. This
may be, for example, a telephone or a voicemail system.
user agent client: The portion of a user agent which initiates
requests.
user agent server: The portion of a user agent which responds to
requests.
Lennox & Schulzrinne Informational [Page 3]
RFC 2824 CPL-F May 2000
H.323 [2] terminology used includes:
terminal: An H.323 device which originates and receives calls, and
their associated media.
gatekeeper: An H.323 entity on the network that provides address
translation and controls access to the network for H.323
terminals and other endpoints. The gatekeeper may also
provide other services to the endpoints such as bandwidth
management and locating gateways.
gateway: A device which translates calls between an H.323 network
and another network, typically the public-switched telephone
network.
RAS: The Registration, Admission and Status messages communicated
between two H.323 entities, for example between an endpoint
and a gatekeeper.
General terminology used in this document includes:
user location: The process by which an Internet telephony device
determines where a user named by a particular address can be
found.
CPL: A Call Processing Language, a simple language to describe how
Internet telephony call invitations should be processed.
script: A particular instance of a CPL, describing a particular
set of services desired.
end system: A device from which and to which calls are
established. It creates and receives the call's media
(audio, video, or the like). This may be a SIP user agent or
an H.323 terminal.
signalling server: A device which handles the routing of call
invitations. It does not process or interact with the media
of a call. It may be a SIP proxy or redirect server, or an
H.323 gatekeeper.
3 Example services
To motivate the subsequent discussion, this section gives some
specific examples of services which we want users to be able to
create programmatically. Note that some of these examples are
deliberately somewhat complicated, so as to demonstrate the level of
decision logic that should be possible.
Lennox & Schulzrinne Informational [Page 4]
RFC 2824 CPL-F May 2000
o Call forward on busy/no answer
When a new call comes in, the call should ring at the user's
desk telephone. If it is busy, the call should always be
redirected to the user's voicemail box. If, instead, there's no
answer after four rings, it should also be redirected to his or
her voicemail, unless it's from a supervisor, in which case it
should be proxied to the user's cell phone if it is currently
registered.
o Information address
A company advertises a general "information" address for
prospective customers. When a call comes in to this address, if
it's currently working hours, the caller should be given a list
of the people currently willing to accept general information
calls. If it's outside of working hours, the caller should get
a webpage indicating what times they can call.
o Intelligent user location
When a call comes in, the list of locations where the user has
registered should be consulted. Depending on the type of call
(work, personal, etc.), the call should ring at an appropriate
subset of the registered locations, depending on information in
the registrations. If the user picks up from more than one
station, the pick-ups should be reported back separately to the
calling party.
o Intelligent user location with media knowledge
When a call comes in, the call should be proxied to the station
the user has registered from whose media capabilities best
match those specified in the call request. If the user does not
pick up from that station within four rings, the call should be
proxied to the other stations from which he or she has
registered, sequentially, in order of decreasing closeness of
match.
o Client billing allocation -- lawyer's office
When a call comes in, the calling address is correlated with
the corresponding client, and client's name, address, and the
time of the call is logged. If no corresponding client is
found, the call is forwarded to the lawyer's secretary.
Lennox & Schulzrinne Informational [Page 5]
RFC 2824 CPL-F May 2000
4 Usage scenarios
A CPL would be useful for implementing services in a number of
different scenarios.
o Script creation by end user
In the most direct approach for creating a service with a CPL,
an end user simply creates a script describing their service.
He or she simply decides what service he or she wants,
describes it using a CPL script, and then uploads it to a
server.
o Third party outsourcing
Because a CPL is a standardized language, it can also be used
to allow third parties to create or customize services for
clients. These scripts can then be run on servers owned by the
end user or the user's service provider.
o Administrator service definition
A CPL can also be used by server administrators to create
simple services or describe policy for servers they control.
If a server is implementing CPL services in any case, extending
the service architecture to allow administrators as well as
users to create scripts is a simple extension.
o Web middleware
Finally, there have been a number of proposals for service
creation or customization using web interfaces. A CPL could be
used as the back-end to such environments: a web application
could create a CPL script on behalf of a user, and the
telephony server could then implement the services without
either component having to be aware of the specifics of the
other.
5 CPL creation
There are also a number of means by which CPL scripts could be
created. Like HTML, which can be created in a number of different
manners, we envision multiple creation styles for a CPL script.
Lennox & Schulzrinne Informational [Page 6]
RFC 2824 CPL-F May 2000
o Hand authoring
Most directly, CPL scripts can be created by hand, by
knowledgeable users. The CPL described in [5] has a text
format with an uncomplicated syntax, so hand authoring will be
straightforward.
o Automated scripts
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -