Internet Engineering Task Force SIPPING WG
Internet Draft Aparna Vemuri
draft-ietf-sipping-sipt-00.txt Qwest
November 2001 Jon Peterson
Expires: May 2001 NeuStar, Inc
SIP for Telephones (SIP-T): Context and Architectures
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
SIP-T (earlier referred to as 'SIP-BCP-T') is a mechanism that uses
SIP to facilitate the interconnection of the PSTN with SIP networks.
This document explains the context and the architectures in which
SIP-T may be used.
1. Introduction
The Session Initiation Protocol (SIP) is an application-layer control
protocol that can establish, modify and terminate multimedia sessions
or calls. These multimedia sessions include multimedia conferences,
Internet telephony and similar applications. SIP is one of the key
protocols used to implement VoIP. Although performing telephony call
signaling and transporting the associated audio media over IP beget
significant advantages, a VoIP network cannot exist in isolation. It
is vital for a SIP network to be smoothly interfaced to the PSTN.
Vemuri/Peterson [Page 1]
Internet-Draft SIP-T Context & Architectures Feb 2001
An important characteristic of any VoIP SIP network is FEATURE
TRANSPARENCY with respect to the PSTN. Traditional telecom services
such as call waiting, 800 numbers, etc. implemented in SS7 should be
offered by a SIP network in a manner that precludes any debilitating
difference in the user experience. It is necessary that SIP support
the primitives for the delivery of such services where the
terminating point is a regular SIP-phone (see definition in section 2
below). However, it is essential that SS7 information be available at
the points of PSTN-IP interconnection to ensure transparency of
features not otherwise supported in SIP. SS7 information should be
available in its entirety and without any loss to the SIP network
across the PSTN-IP interface. A compelling need to do so also arises
from the fact that certain networks utilize proprietary ISUP
parameters to transmit certain information through their networks.
Another requirement is ROUTABILITY in the SIP network - a SIP message
that is used to set up a telephone call should bear sufficient
information that would enable it to be appropriately routed to its
destination by proxy servers in the SIP network. The SIP-T (SIP for
Telephones) effort provides a framework for the integration of legacy
telephony signaling into SIP messages. SIP-T fulfils the above two
requirements through ENCAPSULATION and TRANSLATION respectively. At
the point of inter-connection SS7 ISUP messages are encapsulated
within SIP in order that information necessary for services is not
discarded. Also, certain information is translated from an SS7 ISUP
message to generate the corresponding SIP header information in order
to facilitate the routing of SIP messages.
While pure SIP has all the requisite instruments for the
establishment and termination of calls, it does not have any
mechanism to carry any MID-CALL CONTROL INFORMATION along the SIP
signaling path during the session. This mid-call information does not
result in any change in the state of SIP calls or the parameters of
the sessions that SIP initiates. A provision to transmit such
optional application layer information is also needed. Thus, SIP-T
also has to cater to this requirement of transferring mid-call
signaling information.
Problem definition: To provide ISUP transparency across PSTN-IP
------------------- inter-connections
PSTN-IP Inter-connection Requirements SIP-T Functions
==================================================================
Availability of ISUP Encapsulation of ISUP in the
information SIP body
Routability of SIP messages with Translation of ISUP information
ISUP dependencies into the SIP header
Vemuri/Peterson [Page 2]
Internet-Draft SIP-T Context & Architectures Feb 2001
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-
messages call signaling
(See section 4.d)
Table 1: SIP-T features that fulfil PSTN-IP inter-connection
requirements
Note:
1. Many modes of signaling are used in telephony (SS7 ISUP, BTNUP,
ISDN, etc.). This ocument concentrates only on SS7 ISUP and aims to
specify the behavior across ISUP-SIP interfaces only.
2. SIP-T details the methods and tools necessary for the PSTN and
VoIP networks to inter-operate via the SIP protocol. This paper
provides a context for the usage of SIP-T and characterizes
architectures that employ SIP-T. It also highlights the functions of
the different elements in a SIP-T-enabled network.
2. SIP-T for PSTN-IP Interconnections
SIP-T is not a new protocol. It embodies the manner in which SIP must
be used to provide ISUP transparency across PSTN-IP inter-
connections. It is to be used in situations where an IP network (SIP
network, for the purposes of our discussion) interfaces with the
PSTN. Such a network may frequently need to hand a call over to
another network in order to terminate it. Therefore, such networks do
not normally exist in isolation. They have business relationships
with each other resulting in them being peered together in order to
terminate calls. Thus, SIP-T originates from networks and it
terminates at other sites within the network or at a peer network. It
is therefore an intra- network or inter-network mechanism that uses
SIP. Networks that are peered together adhere to certain rules as
specified in their agreements with each other. Thus, SIP-T may not
traverse networks arbitrarily. The originator of a SIP-T message
could have a relationship with the receiver of the message.
It follows that a network should have PSTN access in order to
originate SIP-T (PSTN origination). However, a network need not have
PSTN access in order to receive SIP-T. A network can terminate calls
directed at IP-based end-user devices that are homed to it or to the
PSTN. Or, a network may just serve as a transit network with IP
inter-connections to other networks that have PSTN interfaces. Such a
transit network will accept VoIP calls from one network and hand them
off to another network where they may be terminated. And, the
originating network most often will not know whether the receiving
(i.e. next-hop) network is a terminating network or a transit
network. (See Note 1.)
Vemuri/Peterson [Page 3]
Internet-Draft SIP-T Context & Architectures Feb 2001
The PSTN interfaces that a particular network is associated with
define the ISUP variants that that network supports. This capability
of a network to be able to support a particular version of ISUP
determines whether it can provide feature transparency while
terminating a call.
The following are the components of a SIP-T-enabled network.
1. PSTN: This is the Public Switched Telephone Network. It may
either refer to the entire inter-connected collection of local,
long- distance and international phone companies or some subset
thereof.
2. IP endpoint: Any sort of device that serves as a point in the
network of SIP calls originating or termination may be considered
an IP endpoint for the purposes of this document. Thus, the
following devices may classify as IP endpoints:
a. MGC UA: A Media Gateway Controller (MGC) is an entity used to
control a gateway (that is typically used to provide conversion
between the audio signals carried on telephone circuits and data
packets carried over packet networks). The term MGC is thus used
in this document to typify entities that control the point of
inter-connection between the PSTN and the IP-network. An MGC
speaks ISUP to the PSTN and SIP to the IP-network and converts
between the two.
b. SIP-phone: The term used to represent all end-user devices
that originate SIP calls.
c. Interface points between networks where administrative
policies are enforced (potentially middleboxes, proxy servers, or
gateways).
3. Proxy: A proxy is a SIP entity that helps route SIP signaling
messages to their destinations. Consequently, a proxy might route
SIP messages to other proxies (some of which may be co-located with
firewalls), MGCs and SIP-phones.
Vemuri/Peterson [Page 4]
Internet-Draft SIP-T Context & Architectures Feb 2001
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
Figure 1: Necessity for SIP-T in PSTN-IP inter-connection
In the above figure the IP network (see Note 2) bridges two LECs
together. SIP is employed as the VoIP protocol used to set up and
tear down VoIP sessions and calls. The VoIP network receives SS7
messages from one PSTN interface (the PSTN origination) and sends
them out on another (PSTN termination). Let a call originate from
LEC1 and be terminated by LEC2. The originator is defined as the
generator of the SIP setup signaling and the terminator is defined as
the consumer of the SIP setup signaling. MGC1 is thus the originator
and MGC2, the terminator. One or more proxies may be used to route
the call from the originator to the terminator.
In order to seamlessly integrate the IP network with the PSTN, it is
important to retain the SS7 information at the points of inter-
connection and use this information for the purpose of call
establishment. By including ISUP information in the SIP signaling the
network automatically leverages the call establishment capability of
SIP while trying to establish a session whose attributes may be
influenced by the ISUP information.
SIP-T is employed in order to leverage the intrinsic benefits of
utilizing SIP: call control and establishment via proxies, capability
to enable new services, etc. However, if only the transportation of
ISUP was relevant here, any protocol for the transport of signaling
information may be used to achieve this, obviating the need for SIP
and consequently that of SIP-T. SIP-T thus facilitates call
establishment and the enabling of new services over the IP network
while simultaneously providing a method of inter- connection with the
PSTN.
SIP-T preserves the ISUP information received by the originator by
Vemuri/Peterson [Page 5]
Internet-Draft SIP-T Context & Architectures Feb 2001
encapsulating it in the SIP messages that it uses to establish a
session with the terminator. Translation of information from the
received ISUP messages to the SIP header fields enables these
messages to be effectively routed to the terminator. The terminator
then generates the ISUP message from the received SIP message and
sends it to the PSTN at the terminating end.
Voice calls do not always have to originate and terminate in the PSTN
(via MGCs). They can also originate and terminate in SIP phones. The
alternatives for call origination and termination suggest the
following possibilities for calls that traverse through an IP
network:
Note: The words 'originator' and 'terminator' used in the following
text are used with reference to the SIP setup signaling (as explained
above). The words origination and termination as in 'PSTN
origination', 'IP termination', etc. are used to refer to the call
from the actual, physical origination to the termination, i.e.,
between the two end-users that communicate.)
1. PSTN origination - PSTN termination: The originator (ingress-MGC)
receives ISUP from the PSTN and it retains this information (via
encapsulation and translation) in the SIP messages that it
transmits towards the terminator (egress-MGC). The terminator
extracts the ISUP content from the SIP message that it receives
and it dispatches this to the PSTN.
2. PSTN origination - IP termination: The originator (MGC) receives
ISUP from the PSTN and it preserves this ISUP information in the
SIP messages (via encapsulation and translation) that it directs
towards the terminator (SIP-phone). The terminator has no use for
the encapsulated ISUP and ignores it.
3. IP origination - PSTN termination: A SIP-phone originates the call
towards the network. A SIP message is thus received at the point
of entry to the IP network and is routed to the appropriate
terminating endpoint (terminator). The terminator (MGC) tries to
terminate the call to the appropriate PSTN interface, based on
information that is present in the received SIP header. The ISUP
message that is to be sent to the LEC must be generated from
information gleaned from the SIP header.
4. IP origination - IP termination: This is a case for pure SIP.
SIP-T does not come into play as there is no PSTN involvement.
Thus, there are three distinct elements (from a functional point of
view) in a SIP VoIP network offering PSTN inter-connection:
Vemuri/Peterson [Page 6]
Internet-Draft SIP-T Context & Architectures Feb 2001
1. The originator of SIP signaling
2. The terminator of SIP signaling
3. The network of proxies that routes calls from the originator to
the terminator.
The capabilities required of these entities are ascertained by
exploring the path that a SIP message takes from its generation to
its final consumption. This is discussed in the next section.
3. SIP-T Configurations and Roles
For the purposes of this document, an MGC is the point of inter-
connection between the PSTN and the IP network and ISUP is the
protocol used for call signaling in SS7 networks. SIP is the protocol
used for the establishment and termination of sessions in the IP
world. The IP body (as portrayed in all the illus- -trations in this
document) may encompass a mass of distinct SIP-enabled IP networks,
inter-connected to each other through SIP proxies and a firewall
infrastructure. Proxies are employed to facilitate the routing of the
SIP messages, both within and across the IP networks. Firewalls may
be deployed at the point of inter-connection in order to insure that
the transfer of calls does not constitute a security breach for
either network.
The different configurations that are possible in a SIP-T network are
presented in section 3.1 below. Originator, terminator and proxy
requirements are addressed in section 3.2.
3.1 SIP-T Configurations
The different configurations that are possible in PSTN-IP inter-
connections are presented below.
3.1.1 SIP bridging (PSTN - IP - PSTN)
Vemuri/Peterson [Page 7]
Internet-Draft SIP-T Context & Architectures Feb 2001
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
Figure 2: PSTN origination - PSTN termination (SIP Bridging)
A situation in which a SIP network connects two instances of the
telephone network is an example of 'SIP bridging'. A telephone call
originates in the PSTN and an SS7 ISUP message is dispatched to the
MGC that is the point of interconnection with the PSTN network. This
MGC is the point of origination (or ingress) for message flows over
the IP network for this call. The call progresses in the IP network
(through proxies that route the call) until it is terminated at the
appropriate PSTN interface. The MGC that interconnects to the PSTN at
the egress is the point of termination of the IP message flow. This
egress-MGC then uses ISUP to communicate with the PSTN at the
terminating end. SIP is used in the IP network to determine the
appropriate point of termination and to establish a session between
the origination and termination in order to carry the call through
the IP network.
A very elementary call-flow for SIP bridging is as shown below.
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
Vemuri/Peterson [Page 8]
Internet-Draft SIP-T Context & Architectures Feb 2001
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
3.1.2 PSTN origination - IP termination
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP-phone |
-------- ********************* -------------
Figure 3: PSTN origination - IP termination
A call originates from the PSTN and terminates at a SIP-phone.
A simple call-flow depicting the ISUP and SIP signaling for a PSTN-
originated call terminating in IP is follows:
PSTN MGC Proxy SIP-phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
Vemuri/Peterson [Page 9]
Internet-Draft SIP-T Context & Architectures Feb 2001
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
3.1.3 IP origination - PSTN termination
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP-phone | ** ** | PSTN |
------------ ********************* ---------
Figure 4: IP origination - PSTN termination
A call originates from a SIP-phone and terminates in the PSTN. There
is no telephony interface at call-origination.
A simple call-flow illustrating the different legs in the call is as
shown below.
SIP-phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
Vemuri/Peterson [Page 10]
Internet-Draft SIP-T Context & Architectures Feb 2001
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
3.2 SIP-T Roles
Originator and terminator requirements are derived in sections 3.2.1
and 3.2.2 respectively. Proxy requirements are described in section
3.2.3.
3.2.1 Originator
The fundamental function of the originator is to generate the SIP
call-setup signaling. The MGC is the originator for PSTN
originations, while the SIP-phone is the originator for IP-
originations. In either case, it should be noted that the originator
is not certain of the nature of the termination, i.e. whether it is
in IP or the PSTN.
In the case of calls originating in the PSTN (figures 2 and 3), the
originator (MGC) takes the necessary steps to preserve the ISUP
information. It formulates the SIP INVITE from the ISUP that it has
received from the PSTN. The originator is entrusted with the
responsibility of identifying the nature of the ISUP (ETSI, ANSI,
etc.) that it has received, depending on the nature of the PSTN
interface. This ISUP is correctly classified to be a particular ISUP
variant that the originating network supports. The MGC then
translates certain ISUP information into the SIP headers (see Note
3), so as to enable the SIP message to be routed. This might, for
instance, involve setting the 'To' field in the INVITE to the dialed
number (Called Party Number) of the ISUP IAM. The MGC then
encapsulates the ISUP IAM into the SIP INVITE and ships it out.
The originator is not certain of the entity that will terminate the
call - the fact that the terminating entity could be a SIP-phone that
does not need ISUP is not known to the originator, and it proceeds
with ISUP encapsulation. It is the responsibility of the terminator
to determine whether it wants to utilize the encapsulated ISUP or
not.
In case of an IP-origination (figure 4) the SIP-phone is the
originator. The SIP-phone issues the SIP signaling that is directed
to a SIP proxy that allows it entry into the network. There is no
ISUP to encapsulate, as there is no PSTN interface. Although the call
may terminate in the telephone network and need ISUP in order that
that may take place, the originator may not be aware of this and
consequently, should not be burdened with the task of generating the
Vemuri/Peterson [Page 11]
Internet-Draft SIP-T Context & Architectures Feb 2001
ISUP. It is the responsibility of the terminator to generate ISUP if
necessary (i.e. for PSTN terminations only, and not for IP
terminations).
Thus, an originator must generate the SIP signaling while performing
ISUP encapsulation and translation (ISUP to SIP) wherever possible
(PSTN originations). This must be done irrespective of the nature of
the termination (whether SIP or SS7).
Originator requirements: encapsulate ISUP, translate information from
ISUP to SIP
3.2.2 Terminator
The terminator is the consumer of the SIP signaling. The terminator
is a SIP UA that must be capable of standard SIP processing. The MGC
is the terminator in case of PSTN terminations and is responsible for
terminating the call to the LEC via ISUP. The SIP-phone is the
terminator for IP terminations.
In case of PSTN terminations (figures 2 and 4) the MGC at the egress
tries to terminate the call to the appropriate PSTN interface. The
terminator generates the ISUP from the incoming SIP message. The ISUP
may either be extracted directly from the SIP message that
encapsulates it or gleaned from the SIP headers . In order to make
the determination about the PSTN termination the terminator looks
either into the encapsulated ISUP that it has received, or the SIP
header. In some instances the ISUP that has been retrieved from the
SIP message may need to be modified before it is sent out to the LEC.
(See Note 4)
In case of an IP termination (figure 3) the SIP-phone that receives
ISUP-encapsulated SIP messages from the network disregards the ISUP
as it does not hold any significance for an IP-termination.
Terminator requirements: standard SIP processing, interpretation of
encapsulated ISUP (multi-part MIME; see 4.b.1), ignorance of unknown
MIME content (specifically ISUP)
3.2.3 Proxy
Proxies are entrusted with the task of routing messages to other
proxies, both within and at the edges of the network (the latter may
be co-located with firewalls that monitor the point of inter-
connection with external elements), MGCs and SIP-phones.
A call that enters a given network (say network A) may be terminated
at the appropriate PSTN interface (MGC) or SIP-phone homed to network
Vemuri/Peterson [Page 12]
Internet-Draft SIP-T Context & Architectures Feb 2001
A (intra-network), or, it may be handed off to a peer network for
termination through an edge proxy (inter-network). The proxies make
this determination based on their evaluation of the routable elements
in the SIP message. The routable elements could be the dialed number
or the ISUP variant or any other parameter (See Note 5.) The edge
elements (both MGCs and proxies) must be cognizant of the potential
(capabilities) of their interfaces (PSTN interfaces and peer proxies
respectively) in order to facilitate routing.
Feature transparency of ISUP is central to the notion of SIP-T.
Compatibility between the ISUP variants of the originating and
terminating PSTN interfaces automatically leads to feature
transparency. The termination of a call at a point that results in
greater proximity to the final destination (rate considerations) is
also preferable. The preference of one over the other results in a
trade-off between simplicity of operation and cost. (See Note 6.) The
requirement of procuring a reasonable rate may dictate that a SIP-T
call spans dissimilar PSTN interfaces (SIP bridging across different
ISUP variants). Two different possibilities arise here:
a) The need for ISUP feature transparency may necessitate ISUP
translation (conversion), i.e. conversion from one version of ISUP
to another in order to facilitate the termination of that call over
an interface (MGC) that does not support the ISUP variant of the
originating PSTN interface. (See Note 7.) Although in theory
conversion may be performed at any point in the path, it is viable
to perform it at a point that is at the greatest proximity to the
terminating MGC. This may be accomplished by transferring the call
to an Application Server (See Note 8) that spawns an application to
perform the conversion. Feature transparency in this case is
contingent on the availability of resources to perform ISUP
conversion, and, is secured as a result of an increase in the call-
set up time.
b) The alternative would be to sacrifice ISUP transparency by
handing the call off to an interface (MGC) that does not support
the version of the originating ISUP. The terminating MGC would then
just ignore the encapsulated ISUP and use the information in the
SIP header to terminate the call.
Thus, the proxy must have the intelligence to make a judicious choice
given the options available to it. The task of determining which peer
proxy or MGC to hand off the call to is a routing problem that is
contingent upon the choice of the routable elements.
Proxy requirements: ability to route based on choice of routable
elements
Vemuri/Peterson [Page 13]
Internet-Draft SIP-T Context & Architectures Feb 2001
3.2.4 Summary
The ORIGINATOR must try to perform ISUP encapsulation and translation
irrespective of the nature of the termination.
The TERMINATOR must either interpret the multipart MIME or ignore it
while performing standard SIP processing. The TERMINATOR must
regenerate the ISUP if the call terminates in the PSTN. Two
possibilities arise:
a) The ISUP may be extracted from the SIP message body, or,
b) The ISUP may be generated from information in the SIP headers.
The TERMINATOR must ignore any ISUP present in the SIP-T message in
case of IP termination.
A PROXY must be able to route a call based on the choice of routable
elements.
4. Components of the SIP-T proposal:
The key items of the specification that would address each of the
requirements in detail are as follows:
a. Core SIP
SIP-T uses the methods and procedures of SIP as defined by RFC
2543.
b. Encapsulation
The ISUP MIME type Encapsulation of the PSTN signaling is one of
the major requirements of SIP-T. SIP-T uses MIME multi-part to
enable SIP messages to contain multiple payloads (SDP, ISUP,
etc.). Numerous ISUP variants are in existence today and the
ISUP MIME type should be such that it enables ISUP recognition in
the simplest manner possible. The ISUP nomenclature scheme should
meet the design goals of simplicity and extensibility while
providing a complete ISUP description. A scheme for performing
ISUP encapsulation using multi-part MIME has been described in
[2].
c. Translation
ISUP is used between the IP network and the PSTN, while SIP is
used within the IP network. The MGC acts as a protocol converter
between SIP and ISUP. This dictates that signaling information be
shared across the two protocols so that VoIP sessions and SS7
Vemuri/Peterson [Page 14]
Internet-Draft SIP-T Context & Architectures Feb 2001
connections may be established appropriately.
c.1 ISUP SIP message mapping
This describes a mapping between ISUP and SIP. At the PSTN-IP
interface the MGC is entrusted with the task of generating an
ISUP message for each SIP message received and vice versa. It is
necessary to specify the rules that govern the mapping between
ISUP and SIP messages (i.e., what ISUP messages may be
encapsulated in a particular SIP message: an IAM must be
encapsulated in an INVITE, a REL in a BYE, etc.)
A potential mapping between ISUP and SIP messages has been
described in draft-ietf-sipping-isup-00.txt.
c.2 ISUP parameter-SIP header mapping
A SIP message that is used to set up a telephone call should
contain sufficient information that would enable it to be
appropriately routed to its destination by proxy servers in the
SIP network. This implies that a certain amount of ISUP
information would have to be present in the SIP headers. It is
important to lay down a set of rules that defines the procedure
for translation of information from ISUP to SIP (for example, the
Called Party Number in an ISUP IAM must be mapped onto the SIP To
field, etc.) and also the interpretation of both elements (SIP
headers and encapsulated ISUP) at the terminating entity. This
issue becomes inherently more complicated by virtue of the fact
that a message (especially an INVITE) may undergo transformation
at the hands of an Application Server (AS), and consequently, one
or both of the following may result:
a) the SIP headers and ISUP content are in conflict (an example
in the Future Work section), or, b) a part of the encapsulated
ISUP may be rendered irrelevant and obsolete.
Rules that delineate the preferred behavior of the entities in
question (whether originating or terminating) and under the
specific circumstances surrounding each such case need to be
outlined.
d. Support for mid-call signaling The INFO method Pure SIP does not
have any provision for carrying any mid-call control information
that is generated during a session. The INFO method (defined in
RFC2976) should be used for this purpose.
Vemuri/Peterson [Page 15]
Internet-Draft SIP-T Context & Architectures Feb 2001
5. SIP Content Negotiation
The originator of a SIP-T request might package both SDP and ISUP
elements into the same SIP message by using the MIME multipart
format. If the terminator device did not support a multipart payload
(multipart/mixed) or the ISUP MIME type, it would reject the SIP
request with a 415 Unsupported Media Type specifying the media types
it supports (default - SDP). The originator would then have to re-
send the SIP request after stripping out the ISUP payload (i.e. with
only the SDP payload) and this would then be accepted.
This is a rather cumbersome flow and it is highly desirable to have a
mechanism by which the originator could signify which bodies are
required and which are optional so that the terminator can silently
discard optional bodies that it does not understand (like a SIP-phone
ignoring the ISUP payload). This is contingent upon the terminator
having support for a Content-type of multipart/mixed. The Content-
Disposition header referenced in [1] should be applied to each of the
MIME bodies in a MIME multipart to correctly specify how a given body
must be interpreted by the UAS. The ISUP MIME type using the
Content-Disposition header has been defined in [2]. An INVITE with a
multipart payload (such as SDP and ISUP) can thus specify how each of
the payloads may be processed, leading to call-flows such as the
following:
1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE
irrespective of whether it can process the ISUP.
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
<--18x
2. Support for ISUP is preferred. UA2 does not support the ISUP and
rejects the INVITE with a 415 Unsupported Media Type. UA1 strips off
the ISUP and re-sends the INVITE with SDP only and this is then accepted.
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Vemuri/Peterson [Page 16]
Internet-Draft SIP-T Context & Architectures Feb 2001
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
INVITE-->
(Content-type: application/sdp)
<--18x
3. Support for ISUP is mandatory for call establishment. UA2 does
not support the ISUP and rejects the INVITE with a 415 Unsupported
Media type. UA1 then directs its request to UA3.
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
UA1 UA3
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
Note:
1. These call-flows are not complete. Only the messages relevant to
this discussion are shown.
2. Specifics of the ISUP MIME type can be obtained from [2]. The
'version' and 'base' parameters are not shown here, but must be
used in accordance with the rules of [2].
Vemuri/Peterson [Page 17]
Internet-Draft SIP-T Context & Architectures Feb 2001
6. Security
SIP-T is an intra-network or inter-network signaling mechanism that
may be subject to pre-existing relationships between the networks.
The originator of a SIP-T message could have a relationship with the
receiver of the message. Each network should have the adequate
security apparatus (firewalls, etc.) in place to ensure that the
transfer of calls does not result in any security violations.
It has to be noted that the transit of ISUP in SIP bodies may provide
opportunities for abuse and fraud, especially by SIP-phones. The ISUP
could be encrypted to alleviate this problem. The ISUP could also be
deleted by specialized entities within the network (like Application
Servers, for example) before the SIP messages get terminated at the
SIP-phone. It would also help if networks that have SIP-phones homed
to them managed the registration of these endpoints and enforced
trust relationships and policy with users. (See Note 9.)
7. Future Work
There are many issues associated with SIP-T that need resolution.
Some of these have been identified and are presented below. This is
in no way an exhaustive list. Additions to this list are anticipated
as study progresses in the SIP-T space.
7.1 Network inter-connection architecture: The SIP-T mechanism may
be used between peer networks. The structure of inter-connection of
the peers (use of a NAP architecture, etc.) may affect the manner
in which an edge- proxy selects the next-hop network, and
consequently, the routing process.
7.2 Application architecture: A SIP-T message is a SIP message
produced as a result of ISUP encapsulation and translation via a
PSTN-originated call. Not only does it enclose ISUP within its
body, but it also has some of its header fields populated with
information that has been translated from the ISUP message. When a
call invokes a number translating application in an AS (Application
Server) the application would normally only modify the fields in
the SIP-T header to reflect a change in the call-destination. This
could result in a SIP-T message in which the information in the
header does not agree with the encapsulated ISUP and this is a
violation. A possible solution is to have the application alter the
encapsulated ISUP (or even delete it in case of termination to a
SIP-phone) in addition to amending the SIP-T header.
Vemuri/Peterson [Page 18]
Internet-Draft SIP-T Context & Architectures Feb 2001
8. List of notes:
1. A call that originates in the IP domain (IP origination) and
terminates in the PSTN (PSTN termination) needs special consideration
and is explored in detail in a subsequent section of this document.
2. The IP network depicted here is representative of an inter-
connected mesh of SIP-enabled networks. Call hand-off procedures
between any two networks that are inter-connected are subject to the
terms and conditions of the contractual agreements between them.
3. This document only details the functions of the different entities
in the SIP-T signaling path. The specifics of the translation from
ISUP to SIP and vice versa are to be addressed in the forthcoming
ISUP parameter-SIP header mapping and other associated documents. See
the SIP-T Components section for details.
4. Some terminating MGCs may alter the encapsulated ISUP (or might
even delete it if necessary (see Note 7 below)) in order to remove
any conditions specific to the originating circuit; for example,
continuity test flags in the Nature of Connection Indicators, etc.
5. It is not the intention of this document to lay down rules for
inter-network call hand-off. This document attempts only to assess
the relative merits and demerits of a routing policy based on each
choice.
6. Even so, the relevance of ANSI-specific information in an ETSI
network (or vice versa) is questionable. Clearly, the strength of
SIP-T is realized when the encapsulated ISUP involves the usage of
proprietary parameters.
7. An Application Server (AS) is an entity that hosts applications
that offer calls enhanced services. An AS receives SIP signaling from
the network and invokes applications that produce certain
application-layer responses to the signaling, before transferring the
call back to the network.
8. These and other security-related issues will be explored in a
draft (forthcoming) dealing with security in networks that employ
SIP-T.
9. Revision history
9.1 Changes from draft-vemuri-sip-t-context-00 version:
1. Addition of a section on SIP content negotiation.
Vemuri/Peterson [Page 19]
Internet-Draft SIP-T Context & Architectures Feb 2001
2. Several editorial changes.
9.2 Changes from draft-vemuri-sip-t-context-01 version:
1. Changes in the security section (encryption, presentation
restriction, etc.).
2. Several editorial changes.
9.3 Changes from draft-vemuri-sip-t-context-02 version:
1. The Abstract has been retooled a bit to reflect current
thinking.
2. Formatting errors have been cleaned up.
3. Document references (some of which had become positively
historical) have been brought up to date.
4. Several miscellaneous clarifications have been made in the text.
10. References:
[1] Handley, et al, 'SIP: Session Initiation Protocol', RFC 2543,
Internet Engineering Task Force, March 1999.
[2] Zimmerer, et al, "MIME Media Types for ISUP and QSIG Objects',
draft-ietf-sip-isup-mime-10.txt, Internet Engineering Task Force,
January 2001. (work in progress)
[3] Donovan, "The SIP INFO Method", RFC 2976, Internet Engineering
Task Force, October 2000
[4] Camarillo, et al, "ISUP to SIP Mapping", draft-ietf-sipping-
isup-00.txt, Internet Engineering Task Force, November 2001 (work in
progress)
11. Acknowledgements:
We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan
Rosenberg, Dean Willis, Robert F. Penfield and Steve Donovan for
their valuable comments.
12. Authors' addresses
Aparna Vemuri
Qwest Communications
6000 Parkwood Pl
Vemuri/Peterson [Page 20]
Internet-Draft SIP-T Context & Architectures Feb 2001
Dublin, OH 43016
Aparna.Vemuri@Qwest.com
Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520
Jon.Peterson@NeuStar.com
Full Copyright Statement
Copyright (c) The Internet Society (2000). 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.
Vemuri/Peterson [Page 21]
