RFC 3398
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
9. Suspend/Resume and Hold
9.1 Suspend (SUS) and Resume (RES) Messages
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end. When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted. If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of 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 IP15. 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", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, 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", RFC 3204, December 2001.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header Field for the Session Initiation Protocol", RFC 3326, 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)", RFC 3323, 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", RFC 3262, June 2002. [19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000. [20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, 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 RFC Editor function is currently provided by the Internet Society.