this message); if a prospective destination for an INFO-encapsulated
SUS has not used encapsulated ISUP in any messages it has previously
sent, the gateway SHOULD NOT relay the INFO method, but rather should
handle the SUS and the corresponding RES without signaling their
arrival to the SIP network.
In any case, subsequent RES messages MUST be transmitted in the same
method that was used for the corresponding SUS (i.e., if an INFO is
used for a SUS, INFO should also be used for the subsequent RES).
Regardless of whether the INFO or re-INVITE mechanism is used to
carry a SUS message, neither has any implication that the originating
side will cease sending IP media. The recipient of an encapsulated
SUS message MAY therefore elect to send a re-INVITE themselves to
suspend media transmission from the MGC side if desired.
The following example uses the INVITE mechanism. Note that this flow
is informative, not proscriptive; compliant gateways are free to
implement functionally equivalent flows, as described in the
preceding paragraphs.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call
teardown is handled in Section 10.2.2.
9.2 Hold (re-INVITE)
After a call has been connected, a re-INVITE could be sent to a
gateway from the SIP side in order to place the call on hold. This
re-INVITE will have an SDP offer indicating that the originator of
the re-INVITE no longer wishes to receive media.
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
When such a re-INVITE is received, the gateway SHOULD send a CPG in
order to express that the call has been placed on hold. The CPG
SHOULD contain a Generic Notification Indicator (or, in ANSI
networks, a Notification Indicator) with a value of 'remote hold'.
If, subsequent to the sending of the re-INVITE, the SIP side wishes
to take the remote end off hold and begin receiving media again, it
SHOULD repeat the flow above with an INVITE that contains an SDP
offer with an appropriate media destination. The Generic
Notification Indicator would in this instance have a value of 'remote
retrieval' (or in some variants 'remote hold released').
Finally, note that a CPG with hold indicators may be received by a
gateway from the PSTN. In the interests of conserving bandwidth, the
gateway SHOULD stop sending media until the call is resumed and
SHOULD send a re-INVITE to the SIP leg of the call requesting that
the remote side stop sending media.
10. Normal Release of the Connection
From the perspective of a gateway, either the SIP side or the ISUP
side can release a call, regardless of which side initiated the call.
Note that cancellation of a call setup request (either from the ISUP
or SIP side) is discussed elsewhere in this document (in Section
8.2.7 and Section 7.2.3, respectively).
Gateways SHOULD implement functional equivalence with the flows in
this section.
10.1 SIP initiated release
For a normal termination of the dialog (receipt of a BYE request),
the gateway MUST immediately send a 200 response. The gateway then
MUST release any media resources in the gateway (DSPs, TCIC locks,
and so on) and send an REL with a cause code of 16 (normal call
clearing) to the PSTN. Release of resources is confirmed by the PSTN
side with an RLC message.
In SIP bridging situations, the cause code of any REL encapsulated in
the BYE request SHOULD be re-used in any REL that the gateway sends
to the PSTN.
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
10.2 ISUP initiated release
If the release of the connection was caused by the reception of a
REL, the REL SHOULD be encapsulated in the BYE sent by the gateway.
Whether the caller or callee hangs up first, the gateway SHOULD
release any internal resources used in support of the call and then
MUST confirm that the circuit is ready for re-use by sending an RLC.
10.2.1 Caller hangs up
When the caller hangs up, the SIP dialog MUST be terminated by
sending a BYE request (which is confirmed with a 200).
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
10.2.2 Callee hangs up (SUS)
In some PSTN scenarios, if the callee hangs up in the middle of a
call, the local exchange sends a SUS instead of a REL and starts a
timer (T6, SUS is network initiated). When the timer expires, the
REL is sent. This necessitates a slightly different SIP flow; see
Section 9 for more information on handling suspension. It is
RECOMMENDED that gateways implement functional equivalence with the
following flow for this case:
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
11. ISUP Maintenance Messages
ISUP contains a set of messages used for maintenance purposes. They
can be received during any ongoing call. There are basically two
kinds of maintenance messages (apart from the continuity check):
messages for blocking circuits and messages for resetting circuits.
11.1 Reset messages
Upon reception of an RSC message for a circuit currently being used
by the gateway for a call, the call MUST be released immediately
(this typically results from a serious maintenance condition). RSC
MUST be answered with an RLC after resetting the circuit in the
gateway. Group reset (GRS) messages which target a range of circuits
are answered with a Circuit Group Reset ACK Message (GRA) after
resetting all the circuits affected by the message.
The gateways SHOULD behave as if a REL had been received in order to
release the dialog on the SIP side. A BYE or a CANCEL are sent
depending of the status of the call. See the procedures in Section
10.
11.2 Blocking messages
There are two kinds of blocking messages: maintenance messages or
hardware-failure messages. Maintenance blocking messages indicate
that the circuit is to be blocked for any subsequent calls, but these
messages do not affect any ongoing call. This allows circuits to be
gradually quiesced and taken out of service for maintenance.
Hardware-oriented blocking messages have to be treated as reset
messages. They generally are sent only when a hardware failure has
occurred. Media transmission for all calls in progress on these
circuits would be affected by this hardware condition, and therefore
all calls must be released immediately.
BLO is always maintenance oriented and it is answered by the gateway
with a Blocking ACK Message (BLA) when the circuit is blocked - this
requires no corresponding SIP actions. Circuit Group Blocking (CGB)
messages have a "type indicator" inside the Circuit Group Supervision
Message Type Indicator. It indicates if the CGB is maintenance or
hardware failure oriented. If the CGB results from a hardware
failure, then each call in progress in the affected range of circuits
MUST be terminated immediately as if a REL had been received,
following the procedures in Section 10. CGBs MUST be answered with
CGBAs.
11.3 Continuity Checks
A continuity check is a test performed on a circuit that involves the
reflection of a tone generated at the originating switch by a
loopback at the destination switch. Two variants of the continuity
check appear in ISUP: the implicit continuity check request within an
IAM (in which case the continuity check takes place as a precondition
before call setup begins), and the explicit continuity check signaled
by a Continuity Check Request (CCR) message. PSTN gateways in
regions that support continuity checking generally SHOULD have some
way of accommodating these tests (if they hope to be fielded by
providers that interconnect with any major carrier).
When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT
send any corresponding SIP messages; the scope of the continuity
check applies only to the PSTN trunks, not to any IP media paths
beyond the gateway. CCR messages also do not designate any called
party number, or any other way to determine what SIP user agent
server should be reached.
When an IAM with the Continuity Check Indicator flag set within the
NCI parameter is received, the gateway MUST process the continuity
check before sending an INVITE message (and proceeding normally with
call setup); if the continuity check fails (a COT with Continuity
Indicator of 'failed' is received), then an INVITE MUST NOT be sent.
12. Construction of Telephony URIs
SIP proxy servers MAY route SIP messages on any signaling criteria
desired by network administrators, but generally the Request-URI is
the foremost routing criterion. The To and From headers are also
frequently of interest in making routing decisions. SIP-ISUP mapping
assumes that proxy servers are interested in at least these three
fields of SIP messages, all of which contain URIs.
SIP-ISUP mapping frequently requires the representation of telephone
numbers in these URIs. In some instances these numbers will be
presented first in ISUP messages, and SS7-SIP gateways will need to
translate the ISUP formats of these numbers into SIP URIs. In other
cases the reverse transformation will be required.
The most common format used in SIP for the representation of
telephone numbers is the tel URL [7]. When converting between
formats, the tel URL MAY constitute the entirety of a URI field in a
SIP message, or it MAY appear as the user portion of a SIP URI. For
example, a To field might appear as:
To: tel:+17208881000
Or
To: sip:+17208881000@level3.com
Whether or not a particular gateway or endpoint should formulate URIs
in the tel or SIP format is a matter of local administrative policy -
if the presence of a host portion would aid the surrounding network
in routing calls, the SIP format should be used. A gateway MUST
accept either tel or SIP URIs from its peers.
The '+' sign preceding the number in tel URLs indicates that the
digits which follow constitute a fully-qualified E.164 [16] number;
essentially, this means that a country code is provided before any
national-specific area codes, exchange/city codes, or address codes.
The absence of a '+' sign MAY signify that the number is merely
nationally significant, or perhaps that a private dialing plan is in
use. When the '+' sign is not present, but a telephone number is
represented by the user portion of the URI, the SIP URI SHOULD
contain the optional ';user=phone' parameter; e.g.,
To: sip:83000@sip.example.net;user=phone
However, it is strongly RECOMMENDED that only internationally
significant E.164 numbers be passed between SIP-T gateways,
especially when such gateways are in different regions or different
administrative domains. In many if not most SIP-T networks, gateways
are not responsible for end-to-end routing of SIP calls; practically
speaking, gateways have no way of knowing if the call will terminate
in a local or remote administrative domain and/or region, and hence
gateways SHOULD always assume that calls require an international
numbering plan. There is no guarantee that recipients of SIP
signaling will be capable of understanding national dialing plans
used by the originators of calls - if the originating gateway does
not internationalize the signaling, the context in which the digits
were dialed cannot be extrapolated by far-end network elements.
In ISUP signaling, a telephone number appears in a common format that
is used in several parameters, including the CPN and CIN; when it
represents a calling party number it sports some additional
information (detailed below). For the purposes of this document, we
will refer to this format as 'ISUP format' - if the additional
calling party information is present, the format shall be referred to
as 'ISUP- calling format'. The format consists of a byte called the
Nature of Address (NoA) indicator, followed by another byte which
contains the Numbering Plan Indicator (NPI), both of which are
prefixed to a variable-length series of bytes that contains the
digits of the telephone number in Binary Coded Decimal (BCD) format.
In the calling party number case, the NPI's byte also contains bit
fields which represent the caller's presentation preferences and the
status of any call screening checks performed up until this point in
the call.
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
ISUP numbering formats
The NPI field is generally set to the value 'ISDN (Telephony)
numbering plan (Recommendation E.164)', but this does not mean that
the digits which follow necessarily contain a country code; the NoA
field dictates whether the telephone number is in a national or
international format. When the represented number is not designated
to be in an international format, the NoA generally provides
information specific to the national dialing plan - based on this
information one can usually determine how to convert the number in
question into an international format. Note that if the NPI contains
a value other than 'ISDN numbering plan', then the tel URL may not be
suitable for carrying the address digits, and the handling for such
calls is outside the scope of this document.
12.1 ISUP format to tel URL mapping
Based on the above, conversion from ISUP format to a tel URL is as
follows. First, provided that the NPI field indicates that the
telephone number format uses E.164, the NoA is consulted. If the NoA
indicates that the number is an international number, then the
telephone number digits SHOULD be appended unmodified to a 'tel:+'
string. If the NoA has the value 'national (significant) number',
then a country code MUST be prefixed to the telephone number digits
before they are committed to a tel URL; if the gateway performing
this conversion interconnects with switches homed to several
different country codes, presumably the appropriate country code
SHOULD be chosen based on the originating switch or trunk group. If
the NoA has the value 'subscriber number', both a country code and
any other numbering components necessary for the numbering plan in
question (such as area codes or city codes) MAY need to be added in
order for the number to be internationally significant - however,
such procedures vary greatly from country to country, and hence they
cannot be specified in detail here. Only if a country or network-
specific value is used for the NoA SHOULD a tel URL not include a '+'
sign; in these cases, gateways SHOULD simply copy the provided digits
into the tel URL and append a 'user=phone' parameter if a SIP URI
format is used. Any non-standard or proprietary mechanisms used to
communicate further context for the call in ISUP are outside the
scope of this document.
If a nationally-specific parameter is present that allows for the
transmission of the calling party's name (such as the Generic Name
Parameter in ANSI), then generally, if presentation is not
restricted, this information SHOULD be used to populate the display-
name portion of the From field.
If ISUP calling format is being converted rather than ISUP format,
then two additional pieces of information must be taken into account:
presentation indicators and screening indicators. If the
presentation indicators are set to 'presentation restricted', then a
special URI is created by the gateway which communicates to the far
end that the caller's identity has been omitted. This URI SHOULD be
a SIP URI with a display-name and username of 'Anonymous', e.g.:
From: Anonymous <sip:anonymous@anonymous.invalid>
For further information about privacy in SIP, see Section 5.7.
If presentation is set to 'address unavailable', then gateways should
treat the IAM as if the CIN parameter was omitted. Screening
indicators should not be translated, as they are only meaningful
end-to-end.
12.2 tel URL to ISUP format mapping
Conversion from tel URLs to ISUP format is simpler. If the URI is in
international format, then the gateway SHOULD consult the leading
country code of the URI. If the country code is local to the gateway
(the gateway has one or more trunks that point to switches which are
homed to the country code in question), the gateway SHOULD set the
NoA to reflect 'national (significant) number' and strip the country
code from the URI before populating the digits field. If the country
code is not local to the gateway, the gateway SHOULD set the NoA to
'international number' and retain the country code. In either case
the NPI MUST be set to 'ISDN numbering plan'.
If the URI is not in international format, the gateway MAY attempt to
treat the telephone number within the URI as if it were appropriate
to its national or network-specific dialing plan; if doing so gives
rise to internal gateway errors or the gateway does not support such
procedures, then the gateway SHOULD respond with appropriate SIP
status codes to express that the URI could not be understood (if the
URI in question is the Request-URI, a 484).
When converting from a tel URL to ISUP calling format, the procedure
is identical to that described in the preceding paragraphs, but
additionally, the presentation indicator SHOULD be set to
'presentation allowed' and the screening indicator to 'network
provided', unless some service provider policy or user profile
specifically disallows presentation.
13. Other ISUP flavors
Other flavors of ISUP different than ITU-T ISUP have different
parameters and more features. Some of the parameters have more
possible values and provide more information about the status of the
call.
The Circuit Query Message (CQM) and Circuit Query Response (CQR) are
used in many ISUP variants. These messages have no analog in SIP,
although receipt of a CQR may cause state reconciliation if the
originating and destination switches have become desynchronized; as
states are reconciled some calls may be terminated, which may cause
SIP or ISUP messages to be sent (as described in Section 10).
However, differences in the message flows are more important. In
ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent
instead (when no ACM has been sent before the call is answered). In
call forwarding situations, CPGs MAY be sent before the ACM is sent.
SAMs MUST NOT be sent; 'en-bloc' signaling is always used. The ANSI
Exit Message (EXM) SHOULD NOT result in any SIP signaling in
gateways. ANSI also uses the Circuit Reservation Message (CRM) and
Circuit Reservation Acknowledgment (CRA) as part of its interworking
procedures - in the event that an MGC does receive a CRM, a CRA
SHOULD be sent in return (in some implementations, transmissions of a
CRA could conceivably be based on a resource reservation system);
after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and
process it normally. Any further circuit reservation mechanism is
outside the scope of this document.
Although receipt of a Confusion (CFN) message is an indication of a
protocol error, corresponding SIP messages SHOULD NOT be sent on
receipt of a CFN - the CFN should be handled with ISUP-specific
procedures by the gateway (usually by retransmission of the packet to
which the CFN responded). Only if ISUP procedures fails repeatedly
should this cause a SIP error condition (and call failure) to arise.
In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such
as a Charging Information Message (CHG) MAY be sent between ACM and
ANM. 'En-bloc' signaling is always used and there is no T9 timer.
13.1 Guidelines for sending other ISUP messages
Some ISUP variants send more messages than the ones described in this
document. Therefore, some guidelines are provided here with regard
to transport and mapping of these ISUP message.
From the caller to the callee, other ISUP messages SHOULD be
encapsulated (see [3]) inside INFO messages, even if the INVITE
transaction is still not finished. Note that SIP does not ensure
that INFO requests are delivered in order, and therefore in adverse
network conditions an egress gateway might process INFOs out of
order. This issue, however, does not represent an important problem
since it is not likely to happen and its effects are negligible in
most of the situations. The Information (INF) message and
Information Response (INR) are examples of messages that should be
encapsulated within an INFO. Gateway implementers might also
consider building systems that wait for each INFO transaction to
complete before initiating a new INFO transaction.
From the callee to the caller, if a message is received by a gateway
before the call has been answered (i.e., ANM is received) it SHOULD
be encapsulated in an INFO, provided that this will not be the first
SIP message sent in the backwards direction (in which case it SHOULD
be encapsulated in a provisional 1xx response). Similarly a message
which is received on the originating side (probably in response to an
INR) before a 200 OK has been received by the gateway should be
carried within an INFO. In order for this mechanism to function
properly in the forward direction, any necessary Contact or To-tag
must have appeared in a previous provisional response or the message
might not be correctly routed to its destination. As such all SIP-T
gateways MUST send all provisional responses with a Contact header
and any necessary tags in order to enable proper routing of new
requests issued before a final response has been received. When the
INVITE transaction is finished INFO requests SHOULD also be used in
this direction.
14. Acronyms
ACK Acknowledgment
ACM Address Complete Message
ANM Answer Message
ANSI American National Standards Institute
BLA Blocking ACK message
BLO Blocking Message
CGB Circuit Group Blocking Message
CGBA Circuit Group Blocking ACK Message
CHG Charging Information Message
CON Connect Message
CPG Call Progress Message
CUG Closed User Group
GRA Circuit Group Reset ACK Message
GRS Circuit Group Reset Message
HLR Home Location Register
IAM Initial Address Message
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU-T International Telecommunication Union
Telecommunication Standardization Sector
MG Media Gateway
MGC Media Gateway Controller
MTP Message Transfer Part
REL Release Message
RES Resume Message
RLC Release Complete Message
RTP Real-time Transport Protocol
SCCP Signaling Connection Control Part
SG Signaling Gateway
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SUS Suspend Message
TTC Telecommunication Technology Committee
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
VoIP Voice over IP
15. Security Considerations
The translation of ISUP parameters into SIP headers may introduce
some privacy and security concerns above and beyond those that have
been identified for other functions of SIP-T [9A]. Merely securing
encapsulated ISUP, for example, would not provide adequate privacy
for a user requesting presentation restriction if the Calling Party
Number parameter is openly mapped to the From header. Section 12.2
shows how SIP Privacy [9B] should be used for this function. Since
the scope of SIP-ISUP mapping has been restricted to only those
parameters that will be translated into the headers and fields used
to route SIP requests, gateways consequently reveal through
translation the minimum possible amount of information.
A security analysis of ISUP is beyond the scope of this document.
ISUP bridging across SIP is discussed more fully in [9A], but Section
7.2.1.1 discusses processing the translated ISUP values in relation
to any embedded ISUP in a request arriving at PSTN gateway. Lack of
ISUP security analysis may pose some risks if embedded ISUP is
blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust
embedded ISUP unless the request was strongly authenticated [9A], and
the sender is trusted, e.g., is another MGC that is authorized to use
ISUP over SIP in bridge mode. When requests are received from
arbitrary end points, gateways SHOULD filter any received ISUP. In
particular, only known-safe commands and parameters should be
accepted or passed through. Filtering by deleting believed-to-be
dangerous entries does not work well.
In most respects, the information that is translated from ISUP to SIP
has no special security requirements. In order for translated
parameters to be used to route requests, they should be legible to
intermediaries; end-to-end confidentiality of this data would be
unnecessary and most likely detrimental. There are also numerous
circumstances under which intermediaries can legitimately overwrite
the values that have been provided by translation, and hence
integrity over these headers is similarly not desirable.
There are some concerns however that arise from the other direction
of mapping, the mapping of SIP headers to ISUP parameters, which are
enumerated in the following paragraphs. When end users dial numbers
in the PSTN today, their selections populate the telephone number
portion of the Called Party Number parameter, as well as the digit
portions of the Carrier Identification Code and Transit Network
Selection parameters of an ISUP IAM. Similarly, the tel URL and its
optional parameters in the Request-URI of a SIP, which can be created
directly by end users of a SIP device, map to those parameters at a
gateway. However, in the PSTN, policy can prevent the user from
dialing certain (invalid or restricted) numbers, or selecting certain
carrier identification codes. Thus, gateway operators MAY wish to
use corresponding policies to restrict the use of certain tel URLs,
or tel URL parameters, when authorizing a call.
The fields relevant to number portability, which include in ANSI ISUP
the LRN portion of the Generic Address Parameter and the 'M' bit of
the Forward Call Indicators, are used to route calls in the PSTN.
Since these fields are rendered as tel URL parameters in the SIP-ISUP
mapping, users can set the value of these fields arbitrarily.
Consequently, an end-user could change the end office to which a call
would be routed (though if LRN value were chosen at random, it is
more likely that it would prevent the call from being delivered
altogether). The PSTN is relatively resilient to calls that have
been misrouted on account of local number portability, however. In
some networks, a REL message with some sort of "misrouted ported
number" cause code is sent in the backwards direction when such a
condition arises. Alternatively, the PSTN switch to which a call was
misrouted can forward the call along to the proper switch after
making its own number portability query - this is an interim number
portability practice that is still common in most segments of the
PSTN that support portability. It is not anticipated that end users
will typically set these SIP fields, and the risks associated with
allowing an adventurous or malicious user to set the LRN do not seem
to be grave, but they should be noted by network operators. The
limited degree to which SIP signaling contributes to the interworking
indicators of the Forward Call Indicators and Backward Call Indicator
parameters incurs no foreseeable risks.
Some additional risks may result from the SIP response code to ISUP
Cause Code parameter mapping. SIP user agents could conceivably
respond to an INVITE from a gateway with any arbitrary SIP response
code, and thus they can dictate (within the boundaries of the
mappings supported by the gateway) the Q.850 cause code that will be
sent by the gateway in the resulting REL message. Generally
speaking, the manner in which a call is rejected is unlikely to
provide any avenue for fraud or denial of service - to the best
knowledge of the authors there is no cause code identified in this
document that would signal that some call should not be billed, or
that the network should take critical resources off-line. However,
operators may want to scrutinize the set of cause codes that could be
mapped from SIP response codes (listed in 7.2.6.1) to make sure that
no undesirable network-specific behavior could result from operating
a gateway supporting the recommended mappings. In some cases,
operators MAY wish to implement gateway policies that use alternative
mappings, perhaps selectively based on authorization data.
If the Request-URI and the To header field of a request received at a
gateway differ, Section 7.2.1.1 recommends that the To header (if it
is a telephone number) should map to the Original Called Number
parameter, and the Request-URI to the Called Party Number parameter.
However, the user can, at the outset of a request, select a To header
field value that differs from the Request-URI; these two field values
are not required to be the same. This essentially allows a user to
set the ISUP Original Called Number parameter arbitrarily. Any
applications that rely on the Original Called Number for settlement
purposes could be affected by this mapping recommendation. It is
anticipated that future SIP work in this space will arrive at a
better general account of the re-targeting of SIP requests that may
be applicable to the OCN mapping.
The arbitrary population of the From header of requests by SIP user
agents has some well-understood security implications for devices
that rely on the From header as an accurate representation of the
identity of the originator. Any gateway that intends to use the From
header to populate the called party's number parameter of an ISUP IAM
message should authenticate the originator of the request and make
sure that they are authorized to assert that calling number (or make
use of some more secure method to ascertain the identity of the
caller). Note that gateways, like all other SIP user agents, MUST
support Digest authentication as described in [1].
There is another class of potential risk that is related to the cut-
through of the backwards media path before the call is answered.
Several practices described in this document recommend that a gateway
signal an ACM when a called user agent returns a 18x provisional
response code. At that time, backwards media will be cut through
end-to-end in the ISUP network, and it is possible for the called
user agent then to play arbitrary audio to the caller for an
indefinite period of time before transmitting a final response (in
the form of a 2xx or higher response code). There are conceivable
respects in which this capability could be used illegitimately by the
called user agent. It is also however a useful feature to allow
progress tones and announcements to be played in the backwards
direction in the 'ACM sent' state (so that the caller won't be billed
for calls that don't actually complete but for which failure
conditions must be rendered to the user as in-band audio). In fact,
ISUP commonly uses this backwards cut-through capability in order to
pass tones and announcements relating to the status of a call when an
ISUP network interworks with legacy networks that are not capable of
expressing Q.850 cause codes.
It is the contention of the authors that SIP introduces no risks with
regard to backwards media that do not exist in Q.931-ISUP mapping,
but gateways implementers MAY develop an optional mechanism (possibly
something that could be configured by an operator) that would cut off
such 'early media' on a brief timer - it is unlikely that more than
20 or 30 seconds of early media is necessary to convey status
information about the call (see Section 7.2.6). A more conservative
approach would be to never cut through backwards media in the gateway
until a 2xx final response has been received, provided that the
gateway implements some way of prevent clipping of the initial media
associated with the call.
Unlike a traditional PSTN phone, a SIP user agent can launch multiple
simultaneous requests in order to reach a particular resource. It
would be trivial for a SIP user agent to launch 100 SIP requests at a
100 port gateway, thereby tying up all of its ports. A malicious
user could choose to launch requests to telephone numbers that are
known never to answer, which would saturate these resources
indefinitely and potentially without incurring any charges. Gateways
therefore MAY support policies that restrict the number of
simultaneous requests originating from the same authenticated source,
or similar mechanisms to address this possible denial-of-service
attack.
16. IANA Considerations
This document introduces no new considerations for IANA.
17. Acknowledgments
This document existed as an Internet-Draft for four years, and it
received innumerable contributions from members of the various
Transport Area IETF working groups that it called home (which
included the MMUSIC, SIP and SIPPING WGs). In particular, the
authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada,
Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir,
Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan
Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter
Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars
Tovander, Al Varney and William T. Marshall for their help and
feedback on this document. The authors would also like to thank
ITU-T SG11 for their advice on ISUP procedures.
18. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC2119, March 1997.
[3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC3204, December 2001.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC2833, May 2000.
[6] Donovan, S., "The SIP INFO Method", RFC2976, October 2000.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC2806, April
2000.
[8] Faltstrom, P., "E.164 number and DNS", RFC2916, September 2000.
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header
Field for the Session Initiation Protocol", RFC3326, December
2002.
[9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63, RFC
3372, September 2002.
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC3323, November 2002.
19. Non-Normative References
[10] International Telecommunications Union, "Application of the ISDN
user part of CCITT Signaling System No. 7 for international ISDN
interconnection", ITU-T Q.767, February 1991,
<http://www.itu.int>.
[11] American National Standards Institute, "Signaling System No. 7;
ISDN User Part", ANSI T1.113, January 1995,
<http://www.itu.int>.
[12] International Telecommunications Union, "Signaling System No. 7;
ISDN User Part Signaling procedures", ITU-T Q.764, December
1999, <http://www.itu.int>.
[13] International Telecommunications Union, "Abnormal conditions -
Special release", ITU-T Q.118, September 1997,
<http://www.itu.int>.
[14] International Telecommunications Union, "Specifications of
Signaling System No. 7 - ISDN supplementary services", ITU-T
Q.737, June 1997, <http://www.itu.int>.
[15] International Telecommunications Union, "Usage of cause location
in the Digital Subscriber Signaling System No. 1 and the
Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998,
<http://www.itu.int>.
[16] International Telecommunications Union, "The international
public telecommunications numbering plan", ITU-T E.164, May
1997, <http://www.itu.int>.
[17] International Telecommunications Union, "Formats and codes of
the ISDN User Part of Signaling System No. 7", ITU-T Q.763,
December 1999, <http://www.itu.int>.
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in SIP", RFC3262, June 2002.
[19] Stewart, R., "Stream Control Transmission Protocol", RFC2960,
October 2000.
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC3311, October 2002.
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
Number Portability and Freephone Service", Work in Progress.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
URI: http://www.ericsson.com/
EMail: Gonzalo.Camarillo@Ericsson.com
Adam Roach
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
USA
URI: http://www.ciena.com/
EMail: lyOng@ciena.com
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 RFCEditor function is currently provided by the
Internet Society.