Internet DRAFT - draft-sigdevctrl
draft-sigdevctrl
Internet Engineering Task Force TBD WG
Internet Draft Authors:
draft-sigdevctrl-00.txt Henry Sinnreich,
November 1998 MCI Worldcom
Expires: April 1998 Francois Menard,
Mediatrix Telecom
Service Requirements for
Internet Telephony Signaling and Device Control Protocols
<draft-sigdevctrl-00.txt>
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work
in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
unnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Sinnreich, Menard Expires April 1999 [PAGE 1]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
ABSTRACT
This memorandum discusses the requirements for telephony
signaling and device control over the Internet from the
perspective of meeting the needs of Internet service providers
(ISPs) and telecom carriers wishing to provide Internet services
that include telephony. The requirements apply equally to various
Internet telephony and non-Internet telephony devices. For the
purpose of this Internet draft, the notion of telephony is
broadened to include control of other types of streaming media
sessions, such as RTSP based media server device control. Rather
than severely restricting the device control framework to a
particular set of devices, such as IP telephony gateways and
telephony network access servers, this Internet draft presents
requirements that are broad enough to satisfy the needs of any
device that is expected to provide telephony and related
services on the Internet.
Sinnreich, Menard Expires April 1999 [PAGE 2]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
Table of Contents
1. Introduction ............................................... 4
2. IP Telephony in the Internet Context ....................... 6
3. Telephony Signaling ........................................ 7
3.1. Tunneling of telephony signaling over the Internet........ 7
3.2. Common Denominator Signaling over the Internet ........... 7
4. Telephony Devices .......................................... 9
5. Telephony Device Control and Signaling Requirements........ 11
6. Internet Requirements ..................................... 12
6.1. Transport ............................................... 12
6.2. DTMF Signaling Issues ................................... 12
6.3. Security ................................................ 13
6.3.1.Network Level Security ................................. 13
6.3.2.User Level Security .................................... 14
6.4. Network Management ...................................... 14
7. Using Internet and Web State of the Art ................... 14
7.1. Policy and Accounting ................................... 15
7.2. Migrating from SDP to XML ............................... 15
7.3. Scalability of Call Processing Syntaxes ................. 16
8. Concluding Remarks ........................................ 16
9. Authors Address ........................................... 16
10. COPYRIGHT ................................................ 17
11. References ............................................... 18
Sinnreich, Menard Expires April 1999 [PAGE 3]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
1. Introduction
This draft discusses the requirements for telephony signaling and
device control over the Internet from the perspective of meeting
the needs of Internet service providers (ISP's) and telecom
carriers wishing to provide Internet services that include
telephony.
The advent of Internet Telephony has recently generated
significant work in transposing the functionality of telephony
signaling and of various telephony devices onto IP networks and
onto the public Internet. Telephony on the Internet can be
considered a logical subset of Internet multimedia developed with
the Internet Conferencing Architecture [1]. An alternative is the
ITU H.323 multimedia conferencing architecture for packet
networks [2].
The IP Telephony to PSTN Gateway type of device has attracted
most of the attention, generating a significant number of
contributions to the IETF with the objective to establish a
standards framework. This interest has led to the significant
efforts on telephony signaling transport and device control [3],
[4], [5]. As a result of recent work and discussions on mailing
lists, there is now a better understanding of the requirements
for IP telephony to PSTN gateways.
There are however many other known telephony devices besides the
IP telephony gateway. New ones are also emerging in the IP
domain.
It is the objective of this Internet Draft to translate the
requirements for telephony signaling and device control from the
telephony world of the Public circuit Switched Telephone Network
(PSTN) to generic requirements for the Internet and the World
Wide Web.
One of the principal requirements for such an IP telephony device
control framework is that it should be independent from a particular
call control model. Current attempts, and to this date, there has been a
significant number of them, at developing a protocol suitable IP
telephony device control have mainly focused on device control that is
heavily tied to a master/slave call control model. One can only observe
that such an approach severely limits the capacity of a multitude of
other Internet hosts to perform device control. By contrast, of
particular interest to service providers, is the capability on
implementing distributed control models, such as required for example
when outsourcing certain network services, such as in virtual private
networks. Distributed models are native to the Internet and need
Sinnreich, Menard Expires April 1999 [PAGE 4]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
also to be ported to IP telephony. Finally, the service model,
control model and architecture may be different for IP telephony
gateways (1) integrated into a telephony switch, (2) being part
of a cable network or (3) an all IP oriented services network. It
has been well indicated by those interested in deploying Internet
Telephony services in a traditional manner similar to the way
that telephony has evolved on the GSTN, that the capacity of the
network operator to enforce certain services is a key requirement
for deployment. Unfortunately, this conflicts with the need of
intelligent Internet Telephony endpoints to make decisions by
themselves, without requiring that the network be aware of them.
We are beginning to see differences in IETF proposals between an
Internet telephony architecture based on SDP [6], RTP, [7], [8],
SIP [9], RTSP [10] and SNMP [11] versus centrally controlled
architectures such as: MGCP [5] under the Call Agent Call
Control, or H.323 Gatekeeper-Routed Call Control, model. This
document aims to focus attention back to the distributed Internet
model.
The authors believe that telephony signaling and device control
over the Internet mandates the development of a generic
architecture capable of accommodating the needs of both
distributed and centralized call control models. The authors
believe that it would be counterproductive limit the architecture
of a device control protocol to centralized call control
environments. We propose instead the deployment of Internet
protocols that are generic and extensible enough to satisfy the
requirements of both centralized and distributed call control
architectures.
The authors believe that it is technically feasible to develop
and deploy protocols generic enough to control all these devices
using existing technologies. More specifically, the extendable
Framework provided by the eXtended Markup Language (XML) [12],
the Session Initiation Protocol (SIP) and the Simple Network
Management Protocol (SNMP) can be used to meet the requirement
stated above.
Throughout this architecture, media streaming will be done with
the Real Time Protocol and the Real Time Control Protocol.
Keeping this in perspective will keep the complexity of
RTP-endpoints basic device control to a minimum.
Sinnreich, Menard Expires April 1999 [PAGE 5]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
2. IP Telephony in the Internet Context
Voice for Internet Telephony can be more than the plain point to
point 3.1 kHz PSTN/ISDN audio stream that everyone is used to.
Internet Telephony allows this voice stream to be associated with
video and other types of media, such as mail, chat, whiteboards,
etc., in various applications, that may not necessarily be
associated with conventional telephone service. The voice media
of Internet Telephony is therefore only a subset of a larger
class of Internet media, and the telephony service is a subset of
many other Internet services.
The successful integration of telephony on the Internet requires
the use of the same set of controls - protocols - both on global
scale, and across multiple applications and services. Current
predictions show than even when telephony traffic will migrate to
a large extent on the Internet, it will represent a very small
part of the overall traffic, thus not justifying the building of
a separate infrastructure with significantly different protocols.
The Internet Conferencing Architecture is a framework for a
series of applications using various media for conferencing.
There are several parts of the Internet Conferencing Architecture
that are applicable for telephony, such as the Real Time Protocol
(RTP) for the packetized transport of media streams, the Session
Initiation Protocol (SIP) for signaling and the Real Time
Streaming Protocol (RTSP) for audio/video client server play-out
control.
World Wide Web technology, such as URL's, HTTP, XML and SMIL [13]
are a complementary framework for IP telephony, that solves many
hard problems encountered in PSTN/ISDN telephony, such as
addressing and service creation.
We recommend in this draft to use the protocols of the Internet
architecture and the World Wide Web for the full integration of
Internet Telephony with all other existing Internet and Web
Multimedia services for voice, video and data. This includes
other aspects, such as security, policies, service levels, etc.
Sinnreich, Menard Expires April 1999 [PAGE 6]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
3. Telephony Signaling
IP Telephony Signaling must encompass all the capabilities of
such diverse signaling categories as T1/E1 channel associated
signaling, ISDN signaling and SS7 signaling in its various
regional flavors and industry implementations. End-to-end
signaling can be accomplished in several ways. 3.1. Tunneling of
telephony signaling over the Internet This has the advantage of
simplicity, but is not suitable when there are different types of
signaling flavors at the endpoints on the IP network, when for
example:
o The tunnel stretches between two countries with different
regional flavors of SS7, or
o There is an SS7 point at one boundary of the IP network and an
ISDN signaling end point at the other,
o PSTN endpoint needs to connect to an IP host.
Tunneling may also have some transport issues, such as balancing
between the need for small delay vs. the use of TCP for reliable
signaling. Finally, establishing secure tunnels and QoS between
various devices may require additional operational resources.
Tunneling may therefore be applicable in a limited context, but
presents problems as a general method for signaling transport.
3.2. Common Denominator Signaling over the Internet
The use of a common denominator signaling over the Internet, such
as SIP, will allow the connection with other non-telephony
devices and will also serve as a translator between telephony
signaling options. In the case of SIP, the additional security
features of SIP do not require operational resources for every
new set of endpoints. However the translation of telephony
signaling into SIP require the mapping of protocols, such as the
mapping of SS7 ISUP to SIP [14].
The large number of signaling flavors in telecom networks raises
a number of issues.
One situation occurs when a call originating on PSTN is signaled
via ISUP to a Gateway on the Internet, then signaled back to ISUP
at another Gateway on the Internet, then terminated back to PSTN.
The problem is that many ISUP parameters not necessarily required
for signaling in the Internet may be needed to correctly handle
Sinnreich, Menard Expires April 1999 [PAGE 7]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
the call at the destination. This is compounded by the many
varieties of ISUP in general use.
Two possible options can be considered:
1. Transport (tunnel) the telephony network protocol data
unchanged over the Internet through another media session,
while letting the telephony edge devices (i.e. gateways) take
care of all issues relating to ensuring the interface to the
telephone network is correct, such as proper DTMF timing,
circuit/trunk selection and other considerations. The protocol
for transporting this data transparently and in real time can
be RTP, but as for fax data, such a protocol has far more
features than required.
2. Map telephony protocol data (of which there are many
varieties) to some sort of meta-data description (such as an
XML DTD for telephony network protocol data), which would
provide the basis for translations. Then carry this data
description in a protocol over this Internet. The first
proposal keeps the Internet Telephony Signaling using SIP
simple, but could make the gateways very complex as they may
be held responsible for interpreting "alien" telephony network
protocol data, if there are divergent terminations such as in
different countries, or SS7 and ISDN.
The second proposal may require significant development work, but
provides much simpler gateways, as only a single, locally
applicable translation need be understood by each gateway. The
second proposal also has the benefit of exposing telephony
network protocol data for the benefit of Internet applications
through an interface that is familiar for Internet applications.
One could imagine, as an example, a Q.773 TCAP transaction
exposed as an XML DTD sent along with a SIP INVITE as opposed to
an X.209 ASN.1, BER-encoded, MIME-encoded, TCAP attachment sent
along with a SIP INVITE.
The addition of another media stream along with a SIP session
keeps Internet Telephony signaling protocols unchanged as the
telephony network protocol data is sent transparently.
The second option involves translating from a local variant of
the telephony network protocol to a meta-data description common
format that is understood by both the ingress gateway and the
egress gateway.
Sinnreich, Menard Expires April 1999 [PAGE 8]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
Note: The issue of multiple telephony signaling flavors is
independent of the "protocol in the middle", and applies equally
to H.323.
>From the Internet perspective, Internet telephony signaling must
meet all the requirements for Internet addressing, transport,
security and service level support. Such capabilities are not
existent in the telephone network. Other such capabilities
include the signaling of the RTP packet options (how many voice
frames in the RTP packet), header compression data, and RTP
multiplex data. Other Internet specific signaling requirements
are Unicast/Multicast, Quality of Service, Policy Framework [15]
and Internet Accounting data as part of AAA. The last items are
of special interest for service providers.
Also of interest for Internet service providers is to keep the
Internet free of telecom network signaling details that the
Internet does not need to be burdened with. The Internet clearly
does not need to know about the PSTN inter-machine trunks, their
numbers, their timers, etc. Given the complexity and variety of
telecom signaling implementations, a top system design priority
is not to carry this unnecessary burden over to the Internet. A
good example of arcane and inconsistent signaling across the
globe is in-band DTMF signaling to various PSTN telephony
devices. Here the alpha-numeric information is encoded in analog
DTMF signals, encoded in PCM, and ideally encoded in RTP packets.
Though the information is mostly one single alpha-numeric digit,
the encoding adds difficult timing requirements on the signaling
receiver, that have no meaning to the alpha-numeric information
to be transmitted. Clearly none of this should be part of any
Internet signaling standard.
4. Telephony Devices
As mentioned, the IP telephony gateway has enjoyed considerable
attention in the form of proposals for the gateway architecture,
signaling and device control. There are various schemes to place
the functionality of IP telephony gateways in functional
components, such as the signaling gateway, the media gateway
controller and the media conversion gateway. Please see [4] for
such functional placements.
Sinnreich, Menard Expires April 1999 [PAGE 9]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
In either schema, a large number of distributed media gateways
must be controlled from a small number of signaling gateways and
gateway controllers, or from a centrally located "Intelligent
Network" server. That is, the various control schemas have to be
fully network enabled as when an ISP installs a number of media
gateways in another country, they have to be under the "control"
of a single or small number of gateway controllers.
It is not desirable to install extra control networks for new
services, such as IP telephony. Even when sharing a control
network with other services, additional security is desirable.
Therefore the protocols for gateway control should be full size
Internet strength, that is deal with addressing, transport,
security and QoS.
Full size Internet protocols are however not required when all
the components of an IP telephony gateway are packaged within one
single box or on a dedicated, secure high-speed LAN. In such
instances, no interoperability across the network is required and
for these applications no network standards are required either.
>From the perspective of SIP, the aggregation of call control,
media control, media gateway and signaling gateway functions into
a single entity, forms a single SIP client. Therefore, SGCP,
MGCP, IPDC or other efforts are helpful designing the inside of
the SIP client, and do not change the Internet architecture that
we describe in this Internet Draft.
There are other telephony devices that also require signaling and
device control. More specifically, below is a relevant list of
devices that are expected to be part of any comprehensive
deployment of Internet telephony. This list is not meant to
preclude other devices, which are limited only by imagination.
This list is simply provided to let everyone consider the work
required developing 23 or more different protocols to control the
following 23 or more devices:
1. Announcement Server
2. Automatic Call Distributor
3. Call Agent
4. IP Telephone
5. IP Telephony Appliance
6. IP Telephony Gateway
7. RTP Multiplexer
8. Interactive Voice Response Systems
9. Voice Web Browser
10. Key System
11. MBONE Appliances
12. Network Access Server
Sinnreich, Menard Expires April 1999 [PAGE 10]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
13. Pay Phone
14. LAN PBX
15. Routers
16. RTP Mixer
17. RTSP Media Server
18. Service Control Point
19. Signaling Gateway
20. SIP Server
21. Telephone Switch
22. Voice Recognition and Synthesis system
23. Web Kiosk
x.-y. Talking Car or Talking Home Security System.
5. Telephony Device Control and Signaling Requirements In the
circuit switched telephone network, signaling for telephony
devices and their control does in general not require device
specific protocols, though for some applications, richer
signaling such as SS7 for call centers is more desirable. This
property must be ported to Internet Telephony devices. New
telephony devices on the Internet may also require either
signaling, or at least new capability exchange such as specifying
the parameters of an RTP Multiplexer or control of an RTSP
Server.
But for those devices, which need to be controlled, there are
sets of requirements that now become evident:
1. The Control protocol must be agnostic about the call
control model, whether distributed or centralized
2. The Control protocol should be simple, yet extensible
3. The Control protocol design should keep in mind what is being
done in the IETF Authentication, Authorization and Accounting
(AAA) work [16]. Earlier proposals, such as IPDC, already take
this into account.
4. The Control protocol(s) must reuse as much of existing
protocols, such as SNMPv3 and others, as possible. There needs
to be an analysis of what cannot be performed with SNMP before
the work can even be assigned working-group status.
5. The Control protocol should be first specified as meta-data
grammar using XML if possible.
6. This Control meta-data grammar has to be protocol-independent
if possible, and vice-versa.
7. Only as a last resort should new port numbers be required
outside of RTP, SIP, RTSP and SNMP, so as to keep firewall
requirements down.
8. It is very possible that no Internet wide protocol will be
needed in the end. That is, only a meta-data grammar
Sinnreich, Menard Expires April 1999 [PAGE 11]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
for telephony device control will emerge. This meta-data
grammar can thus be sent using SIP event notification or
rendered available through SNMP MIBs.
9. Ultimately, someone could say that developing this meta-data
grammar is similar to developing an SNMPv3 MIB for telephony
devices, therefore such a grammar would actually meet the
goals envisaged for telephony device control.
6. Internet Requirements
There are two options when providing telephony services over the
Internet:
1. Provide the equivalent of telecom telephony services. This
will be the 1st step and it is mandatory, for the successful
introduction of any IP telephony service.
2. Make IP telephony part of a rich, integrated portfolio of
Internet and Web based services. This is required to keep an
IP telephony service alive and competitive.
For option 2, a number of generic requirements have to be
satisfied. We provide here only a very short overview, given the
complexity for each of the individual topics.
6.1. Transport
Transport (tunneling) of telephony network signaling over the
Internet should use, as far as it is possible, existing
mechanisms, such as SIP, RTP, UDP & TCP and avoid duplication of
functions such as retransmissions and packet re-ordering. If new
transport protocols for signaling are proposed, a reasonably
compelling case should be made for the new protocol.
6.2. DTMF Signaling Issues
The use of the Internet for placing telephone calls often
mandates the use of low-bit rate voice compression algorithms.
Because of the nature of certain voice-compression algorithms,
Dual Tones Multiple Frequency (DTMF, i.e. the well known
0123456789*#ABCD tones) information cannot be sent across the
compressed audio channel without corruption.
One of the contentious issues raised recently is the transport of
DTMF information as a media stream parallel to the audio stream.
The standards bodies seem to have stayed quiet on the DTMF
transport issues until recent discussions on the IETF mailing
lists.
Sinnreich, Menard Expires April 1999 [PAGE 12]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
In the GSTN, DTMF is in-band signaling. In H.323, as part of the
VoIP Implementors Agreement 1.0, the VoIP Forum agreed to
transport DTMF information using the H.245 UserInputIndication
function to get around the fact that G.723.1 does not transport
DTMF tones properly. SGCP introduced a method based on digit
collection in the actual PSTN gateway or in residential gateways,
at the edge of the network.
The fact of the matter is that until DTMF in-band signaling is
treated as in-band information on the same basis as the voice
information, the solution will not be acceptable to control PSTN
devices which rely on precise DTMF length/duration. Thus Internet
Telephony to PSTN gateways will ideally be able to relay the
length/duration information as reliably as possible.
Clearly, intelligent IP telephony end-points have the capability
of collecting this length, and such information can then be
carried across the Internet. However, multiple Internet Telephony
Gateways in tandem gathering DTMF length/duration information
across PSTN interfaces will introduce severe timing problems.
The gathering of DTMF length/duration and the expression of such
information through a protocol grammar are evidently far from
ideal for the reasons stated above. However, from the perspective
of a modern architecture, when the end-to-end media stream is
incapable of transmitting DTMF information, it is more scalable
and easier to send the DTMF information as events than through a
parallel RTP media stream.
In our opinion, to carry DTMF digit length duration information
correctly in an end-to-end manner, DTMF has to be carried over
RTP as proposed in the RTP DTMF [17] draft. When this is not a
requirement, then DTMF information is better sent as events.
6.3. Security
6.3.1. Network Level Security
To avoid multiple private control networks, signaling and device
control participants have to use secure mechanisms both for
authentication and for message exchange, using as appropriate
either the transport layer [18] or network layer [19] security
protocols.
Sinnreich, Menard Expires April 1999 [PAGE 13]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
6.3.2. User Level Security
User level authentication should be based on the emerging IETF
architecture for Authentication, Authorization and Accounting
[20].
6.4. Network Management
Use existing protocols and the SNMP v3 framework.
7. Using Internet and Web State of the Art
Internet technology is a fast moving target. When designing
protocols for IP telephony, we have to separate what can be
accomplished short term, using more mature Internet standards,
versus emerging standards that are still under development. We
will look in this section at emerging Internet standards that
will affect Internet telephony, and where the Internet telephony
community in its turn will have to provide input to meet
telephony requirements.
A top priority for service providers is the rapid deployment of
new services. Possible options are:
A. Static standards option
o Centralized service control and no change in network
elements,
o Proprietary implementation,
o Wait for new standard version before launching a new
interoperable/global service.
B. Or make use of W3C tools such as SIP 'Require', or XML for
device control and signaling
o Dynamic extensions for new methods,
o Self describing tags,
o Fast rollout of either proprietary or open new services and
features.
It is of interest to note two approaches for the fast rollout of
new services.
A. Services and feature rollout using centralized servers, such
as in the telecom IN/AIN model. This approach works quite well
as long as no interaction between different services, such as
voice and e-mail are required. It is possible only when no
changes are required to the network elements (features
embedded in PSTN switches).
Sinnreich, Menard Expires April 1999 [PAGE 14]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
Web based feature rollout using SIP "Require" or XML, where the
protocol extensions are used for dynamic use of new features.
7.1. Policy and Accounting
The rollout of IP telephony services is tied to the notion of who
has access to what services and network resources [21].
Signaling and IP telephony devices will have to carry and enforce
policies regarding certain services and user access privileges.
The multiple types of devices which must work together across
even a single domain to achieve the desired policy can include
hosts (clients and servers), routers, firewalls, bandwidth
brokers, subnet bandwidth managers, network access servers, and
policy servers, to name just a few. As a result, telephony
signaling and device control has to support generic Internet
policy administration and distribution.
7.2. Migrating from SDP to XML
Actual Internet Telephony signaling protocols, such as SIP, SGCP
and MGCP rely heavily on extending the use of the Session
Description Protocol (SDP). The authors believe that the use of
SDP, as a way to speed the time to market of these protocols, is
done at the expense of using the full potential of Web-based
tools.
A paper from W3C presented at the 42nd IETF by Philipp Hoschka of
W3C [22], proposes as a graceful migration from SDP to XML-based
meta-data description, an implementation of SDP using SMIL
syntax.
Furthermore, recently, all references to SDP as a mandatory element of
SIP implementations MUST have been removed from the SIP draft for this
reason, among others.
Finally, migrating to XML in this architecture for meta-data
description, permits to introduce the notion of the call setup
protocol transmitting the settlement information. Internet
payment systems will also accommodate the needs of
telecommunications providers, while unifying the architecture of
electronic commerce on telecommunication networks.
XML provides thus the basis for a common API across the web for
servers, data bases, etc., and also for telephony devices. It
will allow to link Internet telephony directly to business
processes.
Sinnreich, Menard Expires April 1999 [PAGE 15]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
7.3. Scalability of Call Processing Syntaxes
As it has been suggested by Masataka Ohta [23], it scales much
better to let humans beyond distributed endpoints make decisions
based on natural language than to try to express natural language
rules using mere computer semantics. However, for basic set of
functions, it may be feasible to develop a few sets of XML tags.
8. Concluding Remarks
IP telephony signaling and device control represents two
opportunities:
o Re-engineering the telephony system, and
o Absorbing telephony into the Internet.
It can be seen from the above, that this implies getting rid of
PSTN telephony complexity that is irrelevant to the Internet, but
also that absorbing telephony into the Internet is a complex
development.
9. Authors Address
Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
USA
E-mail: henry.sinnreich@mci.com
Francois Menard
Mediatrix Telecom, Inc.
4229 Garlock St.
Sherbrooke, Quebec
J1L 2C8
Canada
E-mail: fmenard@mediatrix.com
Sinnreich, Menard Expires April 1999 [PAGE 16]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
10. COPYRIGHT
Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
Sinnreich, Menard Expires April 1999 [PAGE 18]
Sinnreich, Menard Expires April 1999 [PAGE 17]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
11. References
[1] The Internet Multimedia Conferencing Architecture by Mark
Handley, Jon Crowcroft, Carsten Bormann, Joerg Ott (Internet-draft,
Sept 1997) at http://north.east.isi.edu/~mjh/papers.html
[2] ITU-T Recommendation H.323: Packet-Based Multimedia
Communications Systems, Geneva, February 1998, http://www.itu.ch
[3] Bi-Directional Session Setup Extension to Diameter by Nancy
Greene and F.Cuervo. Internet draft, July 1998.
http://ietf.org/internet-drafts/draft-greene-diameter-ss7-
session-00.txt
[4] SS7-Internet Interworking - Architectural Framework by F.
Cuervo, N. Greene, M. Holdredge, L. Ong and C. Huitema, IETF
draft, July 1998 at http://ietf.org/internet-drafts/draft-greene-
ss7-arch-frame-01.txt
[5] Media Gateway Control Protocol (MGCP) by M. Arango, A
Dugan, I. Elliott, C. Huitema, S. Picket. Internet Draft, October
1998. ftp://ftp.bellcore.com/pub/huitema/papers/draft-huitema-mgcp-
v0r1-00.txt
[6] M. Handley and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, Nov 1997.
[7] RTP: A Transport Protocol for Real-Time Applications by H.
Schlzrinne, S. Casner, R. Frederick, V. Jacobson. RFC 1889 at
http://info.internet.isi.edu/in-notes/rfc/files/rfc1889.txt
[8] RTP Profile for Audio and Video Conferences with Minimal
Control by H. Schulzrinne, Internet draft, August 7, 1998. At
http://ietf.org/internet-drafts/draft-ietf-avt-profile-new-03.txt
[9] SIP: Session Initiation Protocol by Mark Handley, Henning
Schulzrinne, Eve Schooler and Jonathan Rosenberg at
http://ietf.org/internet-drafts/draft-ietf-mmusic-sip-09.txt
[10] Schulzrinne, Lanphier 'Real Time Streaming Protocol (RTSP)'
RFC 2326, Internet Engineering Task Force, April 1998.
[11] SNMP v3. Home page at
http://www.ietf.org/html.charters/snmpv3-charter.html
[12] Frequently Asked Questions about the Extensible Markup
Language, W3C white paper, October 1998. http://www.ucc.ie/xml/
[13] W3C Architecture Domain: Audio, Video and Synchronized
Multimedia. http://w3c.org/AudioVideo/
[14] Mapping between ISUP and SIP. Private communication by H.
Schulzrinne and R. Kang
[15] Policy Framework BOF at the 42nd IETF
ftp://ftp.ietf.org/ietf/98aug/policy-agenda-98aug.txt
Sinnreich, Menard Expires April 1999 [PAGE 18]
INTERNET DRAFT NOVEMBER 1998
Service Requirements for Internet Telephony Signaling and Device
Control Protocols
[16] Authentication, Authorization, and Accounting BOF at the 42nd
IETF. http://ietf.org/meetings/wg_agendas_chic.html
[17] RTP Payload for DTMF Digits by H. Schulzrinne, IETF Draft,
July 1998. http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/
draft-i/draft-ietf-avt-dtmf-00.txt
[18] IETF Transport Layer Security Working Group, home page,
July 1998. http://www.ietf.org/html.charters/tls-charter.html
[19] IP Security Protocol (ipsec) Working Group home page, July
1998. http://www.ietf.org/html.charters/ipsec-charter.html
[20] DIAMETER: Policy and Accounting Extension for SIP by P.
Pan, H. Schulzrinne and P. Calhoun, IETF draft, July 1998.
http://search.ietf.org/internet-drafts/draft-pan-diameter-sip.txt
[21] "Terminology for describing network policy and services",
IETF draft by John Strassner and Ed Ellesson
http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt
[22] Integrating SDP Functionality Into SMIL by Philipp Hoschka,
IETF Draft, August 1998, http://search.ietf.org/internet-drafts/
draft-hoschka-smilsdp-01.txt
[23] Nothing Other Than A Simple Internet Phone (NOTASIP)
by Masataka Ohta and Kenji Fujikawa, IETF Draft, 1998,
http://search.ietf.org/internet-drafts/draft-ohta-notasip02.txt
Sinnreich, Menard Expires April 1999 [PAGE 19]
