The following documents describe proposals for allowing SIP to carry ISUP messages and describe how SIP and PSTN signaling protocols can interwork. Note: The current drafts are draft-zimmerer-sip-bcp-t-00, draft-ietf-sip-isup, and draft-ietf-sip-isup-mime-04. Other drafts dealing with ISUP interworking are obsolete and should not be used. (These obsolete drafts include draft-zimmerer-mmusic-sip-bcp-t-00, draft-camarillo-mmusic-sip-isup-bcp-00, draft-ietf-mmusic-sip-isup-mime-00.) Implementors should be aware that is likely that even the above drafts will change significantly before being standardized. A summary of efforts in this area.
A test specification is at Telenor Signalling System No. 7 Norwegian national interconnect - Test descriptions for Version 2 interface additional tests: ISDN-SIP end-to-end.
July 2000. (approved August 2000 as Proposed Standard)
This document proposes an extension to the Session Initiation Protocol
(SIP). This extension adds the INFO method to the SIP protocol. The
intent of the INFO method is to allow for the carrying of session
related control information that is generated during a session. One
example of such session control information is ISUP and ISDN signaling
messages used to control telephony call services. This and other
example uses of the INFO method may be standardized in the future.
This document describes a way to map ISUP overlap signalling to SIP.
This document demonstrates a way for interested SIP User Agents which
are not a party to the media of a call or session, to receive SIP event
notifications when signaled digits, or other specific telephony-related
events are detected. This is useful for a variety of applications that
monitor calls for a specific event (e.g.: a long pound, special
sequence of digits, or a fax signal) and--only then--take an active role
in the monitored calls.
Jon Peterson and Lyndon Ong
This document defines procedures within SIP-T for translation of ISUP
call context to SIP call context and vice versa to allow ISUP calls to
pass through SIP networks while preserving feature transparency.
If Internet Telephony is to offer a full replacement for traditional
telephone services, it needs to provide emergency call services. In the
United States, emergency calls are known as 911 services, based on the
number dialed. This note desccribes some options for providing enhanced
emergency service, i.e., emergency calls that allow emergency response
centers to determine the address where the caller is located. This is
made more difficult by the temporary nature of IP addresses, the large
number of ISPs and their lack of legal responsibility for emergency
services and the ability of many Internet terminals to be connected to
the Internet at different locations. This note explores some of the
requirements and design choices.
This document describes how SIP may use the DNS to resolve services
associated with E.164 numbers, as specified in draft-ietf-enum-e164-dns.
This draft gives a first input on the SIP-IN Interworking Protocol
Architecture and Procedures for further discussion into the IETF as
part of the SIP-IN Interworking (SIN design team).
SIP is an excellent vehicle for the converged network services of the
future; of that there is no doubt. However, even in the near term, SIP
is an equally powerful solution to bridge the PSTN and VoIP networks by
its application to the IN (Intelligent Network) services domain. This
Internet Draft details our experiences of applying SIP to the said
domain. We use a SIP call controller to execute IN services by mapping
IN call model states to those of the SIP protocol state machine. 
uses the notion of call model integration, an example of which is to use
the IN call model as a canonical call model to map the protocol states
of IP (Internet Protocol) based call controllers (SIP, H.323,...) to
those of the IN call model.
In Internet telephony, the call control functions of a traditional
circuit switch are replaced by a IP-based call controller that must
provide features normally provided by the traditional switch, including
operating as a SSP for IN features. A traditional switch is armed with
an IN call model that provides it a means to reach out and make service
decisions based on intelligence stored elsewhere. Internet call
controllers, by contrast, do not have an IN call model. Furthermore,
since there are many Internet call models with varying number of states
than the IN call model, there has to be a mapping from the IN call model
states to the equivalent states of the Internet call model if existing
services are to be accessed transparently. To leverage the existing IN
services from the Internet domain, this draft proposes a mapping from
the states of the IN call model to the states of SIP, an Internet call
This document describes a mechanism by which an appropriate ringback
tone may be played to the calling party when the called party's device
is alerting. It is written specifcally to address the case where the
Session Initiation Protocol (SIP) is used to initiate voice-over-IP
calls. It also lists ringback characteristics for several countries.
The Session Initiation Protocol allows the establishment of real-
time Internet fax communications as defined by the ITU-T T.38
recommendation. This document attempts to clarify the options
available to Internet telephony gateway vendors to handle real-time
fax calls using SIP.
SIP-T (earlier referred to as the SIP-BCP-T) is a mechanism that uses
SIP to facilitate the interconnection of the PSTN with IP. This
document explains the context and the architectures in which SIP-T may
be used. This document has to be studied in conjunction with the
existing SIP-T (referred to in some older documents as SIP-BCP-T)
This document describes MIME types for application/ISUP and
application/QSIG objects for use in SIP applications, according to the
rules defined in RFC 2048 . These types can be used to identify ISUP
and QSIG objects within a SIP message such as INVITE or INFO, as might
be implemented when using SIP between legacy systems.
The goal of this document is to identify a new IETF work item. The
document defines the term 'soft switch' as a mechanism by which PSTN
Intelligent Network (IN) service control can be accessed by VoIP
gateways and associated SIP servers. The document mechanism for
interworking of the Session Initiation Protocol (SIP) and Intelligent
Network Application Part Protocol (INAP).
The goal of this document is to identify and propose a new work item for
the IETF. This document describes the PSTN Intelligent Network (IN)
Architecture support of Session Initiation Protocol (SIP) networks. The
concept of the 'Soft-SSF' is introduced which acts as an overlay between
the IP telephony call control and the Intelligent Network layer provided
by the IN Service Switching Function (SSF) and the IN Service Control
Function (SCF). This 'Soft-SSF' provides the necessary mapping between
the SIP protocol state machine and the IN Basic Call State Model (BCSM).
Also introduced is the Call Manager Function (CMF) which acts as a
Mediation Node. The CMF entity is responsible for passing service
related information to and from IN service layer, namely the SCF, and
managing the service control relationship. As such, the CMF may contain
a SSF-like functionality or subset thereof, to model the pre and post
conditions that are required to interact with an SCF. The document
specifically deals with the proposed standardized interfaces between the
functional entities identified in the IN Network with associated
functional entities represented in the SIP network. A mapping of
parameters of the SIP protocol to the Intelligent Network Application
Part Protocol(INAP) may be required for the support of the SIP Proxy
Server call control protocol, states and events. Thereby enabling the
Mediation Node (CMF) to model a SIP Proxy server. It is the proposal of
this document to define the Mediation Node(CMF)to Soft SSF interface as
a work item in the IETF as it is presently not a subject for
This document describes the use of the SIP INFO Method for communicating
mid-call events in SIP sessions. Two new MIME types are described,
according to the rules defined in RFC 2046 , for use in the INFO
message. These media types can be used within a SIP INFO message to
request, and report, event detection between SIP network entities.
Emphasis is placed on DTMF signaling to communicate user indications
when using SIP between a Media Gateway Controller (MGC) and a SIP
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
ISDN User Part (ISUP) of SS7.
Last updated by Henning Schulzrinne