Internet DRAFT - draft-donovan-sip-gw-client
draft-donovan-sip-gw-client
MMUSIC WG Steve Donovan
Internet Draft Matthew Cannon
MCIWorldcom
draft-donovan-sip-gw-client-00.txt
November 15, 1998
Expires: May 15, 1999
A Functional Description of a SIP-PSTN Gateway
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
1 Abstract
This document describes a functional model of a gateway between the
Public Switched Telephony Network (PSTN) and a SIP-based IP network
providing telephony service. In this document, the SIP-based IP
network will be referred to as Telephony over IP Service (TIPS).
The primary function of the gateway is to handle connections involving
one or more PSTN phones (i.e.; PSTN black phones) as if those
PSTN phones are SIP clients. The goal of this approach is to ensure
that SIP-based TIPS service logic applies to both native Internet-
based SIP clients and PSTN phones without modification.
2 Introduction
There is currently significant effort being put into defining how the
existing PSTN networks will interwork with the Internet. The current
focus of these efforts is to define how voice-based services will
work between these networks.
There are two primary approaches emerging in this definition. The
first attempts to model the Internet-based telephony solutions on the
existing PSTN architecture. With this approach, all Internet-based
telephone devices would be put under the control of PSTN like control
entities. While this approach will likely work, as it builds on what
<draft-donovan-sip-gw-client.txt> Page 1
Internet Draft November 17, 1998
has proven to be successful, albeit with limitations, from the PSTN
networks, it unnecessarily constrains the solutions that can be
implemented on the TIPS.
The incredible growth of the WWW argues for an approach that is not
modeled on PSTN-like hierarchical control elements but rather on a
distributed model similar to generic WEB services.
It is this model that was the genesis of the Session Initiation
Protocol, which is built on the HTTP protocol.
Using this model, all users of the TIPS are modeled as SIP clients.
This includes clients that access the TIPS from PSTN phones. This
requires the gateway function that implements the interworking
between the PSTN and the TIPS to provide SIP client functions for all
calls passing through the gateway.
Based on this architectural direction, this paper proposes both a
functional decomposition and network model for the reference network
elements defined in draft-greene-ss7-arch-frame-01.txt.
3 Gateway Functional Elements
The following is a description of the functional elements of the PSTN
to SIP TIPS gateway.
Signaling Gateway - This function terminates the signaling associated
with a given PSTN channel/circuit. There are multiple types of SGs in
this model. The following is a partial list of such Signaling
Gateways:
SS7 Signaling Gateway - This SG type terminates call associated SS7
signaling. One example of the SS7 signaling is ISUP. Note that in
this model the SG does not handle TCAP messaging, although a TCAP SG
could easily be added to the model.
ISDN Signaling Gateway - This SG type terminates ISDN call associated
signaling.
CAS Signaling Gateway - This SG type terminates signaling associated
with CAS circuits. Examples include MF and R2-based circuits.
Media Gateway - This function is very similar to that proposed in the
SS7 architecture framework. This function will implement the media
level interworking between the PSTN circuit and an RTP flow.
SIP Client - This function will handle the session initiation
signaling on the IP side of the gateway.
RTP Client - This function will handle the RTP flow.
<draft-donovan-sip-gw-client.txt> Page 2
Internet Draft November 17, 1998
Media Control - In this model the function of Media Control is split
between the gateway and a SIP server. However, the SIP server
function is not required in this model, in which case the full MC
function would be imbedded in the gateway.
4 Gateway Types
Although the functions of the gateway do not depend on the type of PSTN
signaling used, the following functional models of the gateways are
provided for illustrative purposes.
Note that this description of gateway types does not assume that they
would be deployed separately. It is expected that a single gateway
instance would be able to handle multiple PSTN signaling types.
4.1 ISDN Gateway
An ISDN Gateway will handle the interface to ISDN-based PSTN trunks and
lines.
+-----------------------+
| |
| +------+ +--------+ | +--------+
D-Channel | | ISDN | | SIP | | SIP | SIP |
<----------->| SG |<->| Client |<---------->| Server |
| +------+ +--------+ | | or |
| ^ | | Client |
| | | +--------+
| v |
| +------+ +--------+ | +--------+
B-Channel | | ISDN | | RTP | | RTP | SIP |
<--------->| | MG |<->| Client |<---------->| Client |
| +------+ +--------+ | | |
| | +--------+
+-----------------------+
<draft-donovan-sip-gw-client.txt> Page 3
Internet Draft November 17, 1998
4.2 CAS Gateway
A Channel Assocated Signaling Gateway will handle the interface to CAS-
based PSTN trunks and lines.
+-----------------------+
| |
| +------+ +--------+ | +--------+
| | CAS | | SIP | | SIP | SIP |
| | SG |<->| Client |<---------->| Server |
| +------+ +--------+ | | or |
| ^ | | Client |
| | | +--------+
| v |
| +------+ +--------+ | +--------+
Circuit | | CAS | | RTP | | RTP | SIP |
<--------->| | MG |<->| Client |<---------->| Client |
| +------+ +--------+ | | |
| | +--------+
+-----------------------+
4.3 SS7 Gateway
A SS7 Gateway will handle the interface to PSTN trunks that are
controlled by ISUP, TUP or other SS7-based call signaling methods.
This type of gateway is differentiated from the ISDN and CAS gateways
by the fact that it must be implemented in a fashion that allows the
SG function can be deployed separately from the MG function. This is
due to the relative expense of the SS7 link and the scarcity of SS7
point codes.
+-----------------------+
| |
| +------+ +--------+ | +--------+
SS7 Link | | SS7 | | SIP | | SIP | SIP |
<----------->| SG |<->| Client |<---------->| Server |
| +------+ +--------+ | | or |
| ^ | | Client |
| | | +--------+
+-----------------------+
|
|
+-----------------------+
| | |
| v |
| +------+ +--------+ | +--------+
Circuit | | SS7 | | RTP | | RTP | SIP |
<--------->| | MG |<->| Client |<---------->| Client |
| +------+ +--------+ | | |
| | +--------+
+-----------------------+
<draft-donovan-sip-gw-client.txt> Page 4
Internet Draft November 17, 1998
5 Interfaces
The definition of the internal interfaces is outside of the scope of
this document and is assumed to be an implementation issue.
It is important that all other interfaces be standardized. The SIP and
RTP standards are already in various stages of standardization.
The interface between the SS7 SG and the SS7 MG will require
standardization. The current work on the MGCP protocol is one
candidate for this interface. Another option is extensions to the SIP
protocol.
6 DTMF Handling
An important function of the gateway is to convey all signaling
information received from the PSTN to the TIPS. In all three gateway
types defined, signaling information can occur as DTMF digits encoded
into the voice stream.
This "inband" call control information can be used for communications
between the PSTN user and another end device, for example a service
node or the user's at-home answering machine. In this case, it is
envisioned that the DTMF information will be carried in the TIPS as
part of the RTP stream.
This call control information can also be used for interactions with
service control logic generally deployed in the PSTN in Service Control
Points. It is envisioned that the same method of communication between
PSTN-based clients of the TIPS and the TIPS-based service control will
be required. As such, it is important that the gateway be able to
detect and report on the presence of DTMF digits in the voice stream.
Note that it is expected that a similar method of communicating between
native SIP clients and TIPS service logic will be required for SIP
clients with nothing more than a telephone keypad available to control
service logic.
There is work currently underway to define extensions to the SIP
protocol that will allow for an interested IP host, for instance a SIP
server, to request notification of call events. One such use of this
extension will be to request notification of the detection of DTMF
digits. This would allow the SIP server, or other interested host,
to use the DTMF digits for service control logic.
7 Conclusion
It is important that the definition of the interface between the PSTN
and the Internet for telephony-based services take advantage of the
richness of services made possible by the Internet and the World Wide
Web. In order to ensure that this is possible, it is necessary to
model the telephony services on the Internet first and then determine
how to interwork with the PSTN.
<draft-donovan-sip-gw-client.txt> Page 5
Internet Draft November 17, 1998
This paper proposes doing this by treating all PSTN devices as SIP
clients. In doing so, services developed for native Internet SIP
clients can be offered to PSTN clients without modification. In
addition, new services can be added to the TIPS with the relative ease
of adding a WEB page.
8 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP: Session Initiation Protocol", Internet Draft, Internet
Engineering Task Force, October 14, 1998. Work in progress.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
[3] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema, "SS7-
Internet Interworking - Architectural Framework", Internet
Draft, Internet Engineering Task Force, July, 1998.
9 Author's Address
Steve Donovan
MCI Worldcom
1493/678
901 International Parkway
Richardson, Texas 75081
Email: steven.r.donovan@mci.com
Matthew Cannon
MCI Worldcom
9514/107
2400 North Glenville Drive
Richardson, Texas 75082
Email: matt.cannon@mci.com
<draft-donovan-sip-gw-client.txt> Page 6
