Network Working Group A. Vemuri
Internet-Draft Qwest
Expires: August 2, 2002 J. Peterson
NeuStar
February 2002
SIP for Telephones (SIP-T): Context and Architectures
draft-ietf-sipping-sipt-01
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.
This Internet-Draft will expire on August 2, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
Vemuri & Peterson Expires August 2, 2002 [Page 1]
Internet-Draft SIP-T February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP-T for PSTN-IP Interconnections . . . . . . . . . . . . . 5
3. SIP-T Configurations and Roles . . . . . . . . . . . . . . . 9
3.1 SIP-T Configurations . . . . . . . . . . . . . . . . . . . . 9
3.1.1 SIP bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . 9
3.1.2 PSTN origination - IP termination . . . . . . . . . . . . . 11
3.1.3 IP origination - PSTN termination . . . . . . . . . . . . . 12
3.2 SIP-T Roles . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Components of the SIP-T Protocol . . . . . . . . . . . . . . 17
4.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Support for mid-call signaling . . . . . . . . . . . . . . . 18
5. SIP Content Negotiation . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
A. Future Work . . . . . . . . . . . . . . . . . . . . . . . . 26
B. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . . 24
D. Revision History . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . 30
Vemuri & Peterson Expires August 2, 2002 [Page 2]
Internet-Draft SIP-T February 2002
1. Introduction
The Session Initiation Protocol (SIP [1]) 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 Voice over IP (VoIP).
Although performing telephony call signaling and transporting the
associated audio media over IP yields significant advantages over
traditional telephony, a VoIP network cannot exist in isolation from
traditional telephone networks. It is vital for a SIP telephony
network to be smoothly interfaced to the PSTN.
The popularity of gateways that interwork between the PSTN and SIP
networks has motivated the publication of a set of common practices
that can assure consistent behavior across implementations. The
scarcity of SIP expertise outside the IETF suggests that the IETF is
the best place to stage this work, especially since SIP is in a
relative state of flux compared to the core protocols of the PSTN.
Moreover, the IETF working groups that focus on SIP (SIP and SIPPING)
are best positioned to ascertain whether or not any new extensions to
SIP are justified for PSTN interworking. This framework addresses
the overall context in which PSTN-SIP interworking gateways might be
deployed, provides use cases and identifies the mechanisms necessary
for interworking.
An important characteristic of any VoIP SIP network is FEATURE
TRANSPARENCY with respect to the PSTN. Traditional telecom services
such as call waiting, freephone numbers, etc. implemented in PSTN
protocols such as Signaling System No. 7 (SS7 [2]) should be offered
by a SIP network in a manner that precludes any debilitating
difference in 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)
rather than a device that is fluent in SS7. However, it is also
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 SS7 parameters to transmit
certain information through their networks. Another requirement is
ROUTABILITY in the SIP network - a SIP request that sets up a
telephone call should contain sufficient information to enable it to
be appropriately routed to its destination by proxy servers in the
SIP network; this routing may possibly be influenced by mechanisms
such as TRIP [3] or ENUM [4].
Vemuri & Peterson Expires August 2, 2002 [Page 3]
Internet-Draft SIP-T February 2002
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
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-
messages call signaling
Table 1: SIP-T features that fulfil PSTN-IP inter-connection
Requirements
Note that many modes of signaling are used in telephony (SS7 ISUP,
BTNUP, ISDN, etc.). This document concentrates only on SS7 ISUP and
aims to specify the behavior across ISUP-SIP interfaces only.
Also note that 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.
Vemuri & Peterson Expires August 2, 2002 [Page 4]
Internet-Draft SIP-T February 2002
2. SIP-T for PSTN-IP Interconnections
SIP-T is not a new protocol - it is a set of mechanisms for
interfacing traditional telephone signaling with SIP. 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 Appendix B item 1.)
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
Vemuri & Peterson Expires August 2, 2002 [Page 5]
Internet-Draft SIP-T February 2002
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.
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
Figure 1: Necessity for SIP-T in PSTN-IP inter-connection
In Figure 2 the IP network (see Appendix B item 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
Vemuri & Peterson Expires August 2, 2002 [Page 6]
Internet-Draft SIP-T February 2002
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
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
Vemuri & Peterson Expires August 2, 2002 [Page 7]
Internet-Draft SIP-T February 2002
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:
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 Section 3.
Vemuri & Peterson Expires August 2, 2002 [Page 8]
Internet-Draft SIP-T February 2002
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 illustrations 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. Originator, terminator and proxy
requirements are addressed in Section 3.1.1.
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)
********************
*** ***
* *
* ------- *
* |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
Vemuri & Peterson Expires August 2, 2002 [Page 9]
Internet-Draft SIP-T February 2002
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=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
Vemuri & Peterson Expires August 2, 2002 [Page 10]
Internet-Draft SIP-T February 2002
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---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
Vemuri & Peterson Expires August 2, 2002 [Page 11]
Internet-Draft SIP-T February 2002
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.
Vemuri & Peterson Expires August 2, 2002 [Page 12]
Internet-Draft SIP-T February 2002
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
3.2 SIP-T Roles
Requirements for the Section 3.2.1, Section 3.2.2 and Section 3.2.3
intermediary roles in a SIP-T call are described in the following
sections.
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 (Figure 3 and Figure 5),
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
Appendix B item 3), so as to enable the SIP message to be routed.
This might, for instance, involve setting the 'To' field in the
Vemuri & Peterson Expires August 2, 2002 [Page 13]
Internet-Draft SIP-T February 2002
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 7) 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
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 (Figure 3 and Figure 7) 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 Appendix B item 4.)
Vemuri & Peterson Expires August 2, 2002 [Page 14]
Internet-Draft SIP-T February 2002
In case of an IP termination (Figure 5) 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 Section 4.2), 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
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. 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 Appendix B
item 5.) 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 Appendix B item
6.) 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 Appendix B item 7) that spawns an application to perform the
Vemuri & Peterson Expires August 2, 2002 [Page 15]
Internet-Draft SIP-T February 2002
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
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:
o The ISUP may be extracted from the SIP message body, or,
o 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.
Vemuri & Peterson Expires August 2, 2002 [Page 16]
Internet-Draft SIP-T February 2002
4. Components of the SIP-T Protocol
The key items of the specification that would address each of the
requirements in detail are as follows:
4.1 Core SIP
SIP-T uses the methods and procedures of SIP as defined by RFC 2543.
4.2 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 [5].
4.3 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 connections
may be established appropriately.
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.
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
Vemuri & Peterson Expires August 2, 2002 [Page 17]
Internet-Draft SIP-T February 2002
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 Appendix A), 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.
4.4 Support for mid-call signaling
Pure SIP does not have any provision for carrying any mid-call
control information that is generated during a session. The INFO [6]
method should be used for this purpose. Note that INFO is not
suitable for managing overlap dialing. Also note that the use of
INFO for signaling mid-call DTMF signals is not recommended (see
RFC2833 [8] for a recommended mechanism).
Vemuri & Peterson Expires August 2, 2002 [Page 18]
Internet-Draft SIP-T February 2002
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 ISUP MIME
type using the Content-Disposition header has been defined in [5].
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.
Vemuri & Peterson Expires August 2, 2002 [Page 19]
Internet-Draft SIP-T February 2002
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-->
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 that these call-flows are not complete. Only the messages
relevant to this discussion are shown. Specifics of the ISUP MIME
type can be obtained from [5]. The 'version' and 'base' parameters
Vemuri & Peterson Expires August 2, 2002 [Page 20]
Internet-Draft SIP-T February 2002
are not shown here, but must be used in accordance with the rules of
[5].
Vemuri & Peterson Expires August 2, 2002 [Page 21]
Internet-Draft SIP-T February 2002
6. Security Considerations
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 (perhaps with S/MIME [7]) 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 Appendix B item 8.)
Vemuri & Peterson Expires August 2, 2002 [Page 22]
Internet-Draft SIP-T February 2002
7. IANA Considerations
This document introduces no new considerations for IANA.
Vemuri & Peterson Expires August 2, 2002 [Page 23]
Internet-Draft SIP-T February 2002
References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, September 1999.
[2] International Telecommunications Union, "Signaling System No. 7;
ISDN User Part Signaling procedures", ITU-T Q.764, September
1997, <http://www.itu.int>.
[3] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing over
IP (TRIP)", RFC 3219, January 2002.
[4] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[5] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and m. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC 3204, December 2001.
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP
Mapping", draft-ietf-sipping-isup-00 (work in progress),
November 2001.
Authors' Addresses
Aparna Vemuri
Qwest Communications
6000 Parkwood Pl
Dublin, OH 43016
US
EMail: Aparna.Vemuri@Qwest.com
Vemuri & Peterson Expires August 2, 2002 [Page 24]
Internet-Draft SIP-T February 2002
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Vemuri & Peterson Expires August 2, 2002 [Page 25]
Internet-Draft SIP-T February 2002
Appendix A. 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.
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.
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 Expires August 2, 2002 [Page 26]
Internet-Draft SIP-T February 2002
Appendix B. 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 Appendix B item 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.
Vemuri & Peterson Expires August 2, 2002 [Page 27]
Internet-Draft SIP-T February 2002
Appendix C. Acknowledgments
We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan
Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan and
Allison Mankin for their valuable comments.
Vemuri & Peterson Expires August 2, 2002 [Page 28]
Internet-Draft SIP-T February 2002
Appendix D. Revision History
Changes from draft-vemuri-sip-t-context-00 version:
1. Addition of a section on SIP content negotiation.
2. Several editorial changes.
Changes from draft-vemuri-sip-t-context-01 version:
1. Changes in the security section (encryption, presentation
restriction, etc.).
2. Several editorial changes.
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.
Changes from draft-ietf-sipping-sipt-00 version:
1. Integrated some AD comments.
2. Several miscellaneous clarifications have been made in the text.
Vemuri & Peterson Expires August 2, 2002 [Page 29]
Internet-Draft SIP-T February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vemuri & Peterson Expires August 2, 2002 [Page 30]
