From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3372.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc3372.txt (limited to 'doc/rfc/rfc3372.txt') diff --git a/doc/rfc/rfc3372.txt b/doc/rfc/rfc3372.txt new file mode 100644 index 0000000..3320f93 --- /dev/null +++ b/doc/rfc/rfc3372.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group A. Vemuri +Request for Comments: 3372 Qwest Communications +BCP: 63 J. Peterson +Category: Best Current Practice NeuStar + September 2002 + + + Session Initiation Protocol for Telephones (SIP-T): + Context and Architectures + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The popularity of gateways that interwork between the PSTN (Public + Switched Telephone Network) and SIP networks has motivated the + publication of a set of common practices that can assure consistent + behavior across implementations. This document taxonomizes the uses + of PSTN-SIP gateways, provides uses cases, and identifies mechanisms + necessary for interworking. The mechanisms detail how SIP provides + for both 'encapsulation' (bridging the PSTN signaling across a SIP + network) and 'translation' (gatewaying). + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. SIP-T for ISUP-SIP Interconnections . . . . . . . . . . . . . 4 + 3. SIP-T Flows . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1 SIP Bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . . 8 + 3.2 PSTN origination - IP termination . . . . . . . . . . . . . . 9 + 3.3 IP origination - PSTN termination . . . . . . . . . . . . . . 11 + 4. SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12 + 4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.4 Behavioral Requirements Summary . . . . . . . . . . . . . . . 15 + 5. Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16 + 5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . 16 + + + +Vemuri & Peterson Best Current Practice [Page 1] + +RFC 3372 SIP-T September 2002 + + + 5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17 + 6. SIP Content Negotiation . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23 + +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 interwork with 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 SIP telephony 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 [6]) should be offered + by a SIP network in a manner that precludes any debilitating + difference in user experience while not limiting the flexibility of + SIP. On the one hand, 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 gateways, the points + + + +Vemuri & Peterson Best Current Practice [Page 2] + +RFC 3372 SIP-T September 2002 + + + of SS7-SIP interconnection, to ensure transparency of features not + otherwise supported in SIP. If possible, SS7 information should be + available in its entirety and without any loss to trusted parties in + the SIP network across the PSTN-IP interface; one 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 important characteristic of a SIP telephony network is + routability of SIP requests - a SIP request that sets up a telephone + call should contain sufficient information in its headers to enable + it to be appropriately routed to its destination by proxy servers in + the SIP network. Most commonly this entails that parameters of a + call like the dialed number should be carried over from SS7 signaling + to SIP requests. Routing in a SIP network may in turn be influenced + by mechanisms such as TRIP [8] or ENUM [7]. + + The SIP-T (SIP for Telephones) effort provides a framework for the + integration of legacy telephony signaling into SIP messages. SIP-T + provides the above two characteristics through techniques known as + 'encapsulation' and 'translation' respectively. At a SIP-ISUP + gateway, SS7 ISUP messages are encapsulated within SIP in order that + information necessary for services is not discarded in the SIP + request. However, intermediaries like proxy servers that make + routing decisions for SIP requests cannot be expected to understand + ISUP, so simultaneously, some critical information is translated from + an ISUP message into the corresponding SIP headers in order to + determine how the SIP request will be routed. + + While pure SIP has all the requisite instruments for the + establishment and termination of calls, it does not have any baseline + mechanism to carry any mid-call information (such as the ISUP INF/INR + query) 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. + + + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 3] + +RFC 3372 SIP-T September 2002 + + + Problem definition: To provide ISUP transparency across SS7-SIP + interworking + + SS7-SIP Interworking Requirements SIP-T Functions + ================================================================== + Transparency of ISUP Encapsulation of ISUP in the + Signaling SIP body + + Routability of SIP messages with Translation of ISUP information + dependencies on ISUP 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 fulfill PSTN-IP inter-connection + Requirements + + While this document specifies the requirements above, it provide + mechanisms to satisfy them - however, this document does serve as an + framework for the documents that do provide these mechanisms, all of + which are referenced in Section 5. + + Note that many modes of signaling are used in telephony (SS7 ISUP, + BTNUP, Q.931, MF etc.). This document focuses on SS7 ISUP and aims + to specify the behavior across ISUP-SIP interfaces only. The scope + of the SIP-T enterprise may, over time, come to encompass other + signaling systems as well. + +2. SIP-T for ISUP-SIP Interconnections + + SIP-T is not a new protocol - it is a set of mechanisms for + interfacing traditional telephone signaling with SIP. The purpose of + SIP-T is to provide protocol translation and feature transparency + across points of PSTN-SIP interconnection. It intended for use where + a VoIP network (a SIP network, for the purposes of this document) + interfaces with the PSTN. + + Using SIP-T, there are three basic models for how calls interact with + gateways. Calls that originate in the PSTN can traverse a gateway to + terminate at a SIP endpoint, such as an IP phone. Conversely, an IP + phone can make a call that traverses a gateway to terminate in the + PSTN. Finally, an IP network using SIP may serve as a transit + network between gateways - a call may originate and terminate in the + PSTN, but cross a SIP-based network somewhere in the middle. + + + + + + + +Vemuri & Peterson Best Current Practice [Page 4] + +RFC 3372 SIP-T September 2002 + + + The SS7 interfaces of a particular gateway determine the ISUP + variants that that gateway supports. Whether or nor a gateway + supports a particular version of ISUP determines whether it can + provide feature transparency while terminating a call. + + The following are the primary agents in a SIP-T-enabled network. + + o PSTN (Public Switched Telephone Network): This refers to the + entire interconnected collection of local, long-distance and + international phone companies. In the examples below, the term + Local Exchange Carrier (LEC) is used to denote a portion (usually, + a regional division) of the PSTN. + + o IP endpoints: Any SIP user agent that can act as an originator or + recipient of calls. Thus, the following devices are classified as + IP endpoints: + + * Gateways: A telephony gateway provides a point of conversion + between signaling protocols (such as ISUP and SIP) as well as + circuit-switch and packet-switched audio media. The term Media + Gateway Controller (MGC) is also used in the examples and + diagrams in this document to denote large-scale clusters of + decomposed gateways and control logic that are frequently + deployed today. So for example, a SIP-ISUP gateway speaks ISUP + to the PSTN and SIP to the Internet and is responsible for + converting between the types of signaling, as well as + interchanging any associated bearer audio media. + + * SIP phones: The term used to represent all end-user devices + that originate or terminate SIP VoIP calls. + + * Interface points between networks where administrative policies + are enforced (potentially middleboxes, proxy servers, or + gateways). + + o Proxy Servers: A proxy server is a SIP intermediary that routes + SIP requests to their destinations. For example, a proxy server + might direct a SIP request to another proxy, a gateway or a SIP + phone. + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 5] + +RFC 3372 SIP-T September 2002 + + + ******************** + *** *** + * * + * ------- * + * |proxy| * + * ------- * + |----| |----| + /|MGC1| VoIP Network |MGC2|\ + / ---- ---- \ + SS7 / * * \ SS7 + / * ------- * \ + / * |proxy| * \ + -------- * ------- * --------- + | LEC1 | ** ** | LEC2 | + -------- ********************* --------- + + Figure 1: Motivation for SIP-T in ISUP-SIP interconnection + + In Figure 2 a VoIP cloud serves as a transit network for telephone + calls originating in a pair of LECs, where SIP is employed as the + VoIP protocol used to set up and tear down these VoIP calls. At the + edge of the depicted network, an MGC converts the ISUP signals to SIP + requests, and sends them to a proxy server which in turn routes + calls on other MGCs. Although this figure depicts only two MGCs, + VoIP deployments would commonly have many such points of + interconnection with the PSTN (usually to diversify among PSTN rate + centers). For a call originating from LEC1 and be terminating in + LEC2, the originator in SIP-T is the gateway that generates the SIP + request for a VoIP call, and the terminator is the gateway that is + the consumer of the SIP request; MGC1 would thus be the originator + and MGC2, the terminator. Note that one or more proxies may be used + to route the call from the originator to the terminator. + + In this flow, in order to seamlessly integrate the IP network with + the PSTN, it is important to preserve the received SS7 information + within SIP requests at the originating gateway and reuse this SS7 + information when signaling to the PSTN at the terminating gateway. + By encapsulating ISUP information in the SIP signaling, a SIP network + can ensure that no SS7 information that is critical to the + instantiation of features is lost when SIP bridges calls between two + segments of the PSTN. + + That much said, if only the exchange of ISUP between gateways were + 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 is employed in order to + leverage the intrinsic benefits of utilizing SIP: request routing and + call control leveraging proxy servers (including the use of forking), + + + +Vemuri & Peterson Best Current Practice [Page 6] + +RFC 3372 SIP-T September 2002 + + + ease of SIP service creation, SIP's capability negotiation systems, + and so on. Translation of information from the received ISUP message + parameters to SIP header fields enables SIP intermediaries to + consider this information as they handle requests. SIP-T thus + facilitates call establishment and the enabling of new telephony + services over the IP network while simultaneously providing a method + of feature-rich interconnection with the PSTN. + + Finally, the scenario in Figure 2 is just one of several flows in + which SIP-T can be used - voice calls do not always both originate + and terminate in the PSTN (via gateways); SIP phones can also be + endpoints in a SIP-T session. In subsequent sections, the following + possible flows will be further detailed: + + 1. PSTN origination - PSTN termination: The originating gateway + receives ISUP from the PSTN and it preserves this information + (via encapsulation and translation) in the SIP messages that it + transmits towards the terminating gateway. The terminator + extracts the ISUP content from the SIP message that it receives + and it reuses this information in signaling sent to the PSTN. + + 2. PSTN origination - IP termination: The originating gateway + receives ISUP from the PSTN and it preserves this ISUP + information in the SIP messages (via encapsulation and + translation) that it directs towards the terminating SIP user + agent. The terminator has no use for the encapsulated ISUP and + ignores it. + + 3. IP origination - PSTN termination: A SIP phone originates a VoIP + call that is routed by one or more proxy servers to the + appropriate terminating gateway. The terminating gateway + converts to ISUP signaling and directs the call to an appropriate + PSTN interface, based on information that is present in the + received SIP header. + + 4. IP origination - IP termination: This is a case for pure SIP. + SIP-T (either encapsulation or translation of ISUP) does not come + into play as there is no PSTN interworking. + +3. SIP-T Flows + + The follow sections explore the essential SIP-T flows in detail. + Note that because proxy servers are usually responsible for routing + SIP requests (based on the Request-URI) the eventual endpoints at + which a SIP request will terminate is generally not known to the + originator. So the originator does not select from the flows + + + + + +Vemuri & Peterson Best Current Practice [Page 7] + +RFC 3372 SIP-T September 2002 + + + described in this section, as a matter of static configuration or on + a per-call basis - rather, each call is routed by the SIP network + independently, and it may instantiate any of the flows below as the + routing logic of the network dictates. + +3.1 SIP Bridging (PSTN - IP - PSTN) + + ******************** + *** *** + * * + * ------- * + * |proxy| * + * ------- * + |---| |---| + /|MGC| VoIP Network |MGC|\ + / --- --- \ + / * * \ + / * ------- * \ + / * |proxy| * \ + -------- * ------- * --------- + | PSTN | *** *** | PSTN | + -------- ********************* --------- + + Figure 2: PSTN origination - PSTN termination (SIP Bridging) + + A scenario in which a SIP network connects two segments of the PSTN + is referred to as 'SIP bridging'. When a call destined for the SIP + network originates in the PSTN, an SS7 ISUP message will eventually + be received by the gateway that is the point of interconnection with + the PSTN network. This gateway is from the perspective of the SIP + protocol the user agent client for this call setup request. + Traditional SIP routing is used in the IP network to determine the + appropriate point of termination (in this instance a gateway) and to + establish a SIP dialog and begin negotiation of a media session + between the origination and termination endpoints. The egress + gateway then signals ISUP to the PSTN, reusing any encapsulated ISUP + present in the SIP request it receives as appropriate. + + + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 8] + +RFC 3372 SIP-T September 2002 + + + A very elementary call-flow for SIP bridging is 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------| + | | | | | + +3.2 PSTN origination - IP termination + + ******************** + *** *** + * * + * * + * * + * * + |----| |-----| + /|MGC | VoIP Network |proxy|\ + / ---- ----- \ + / * * \ + / * * \ + / * * \ + -------- * * ------------- + | PSTN | ** ** | SIP phone | + -------- ********************* ------------- + + Figure 3: PSTN origination - IP termination + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 9] + +RFC 3372 SIP-T September 2002 + + + A call originates from the PSTN and terminates at a SIP phone. Note + that in Figure 5, the proxy server acts as the registrar for the SIP + phone in question. + + A simple call-flow depicting the ISUP and SIP signaling for a PSTN- + originated call terminating at a SIP endpoint 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 Best Current Practice [Page 10] + +RFC 3372 SIP-T September 2002 + + +3.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. + Unlike the previous two flows, there is therefore no ISUP + encapsulation in the request - the terminating gateway therefore only + performs translation on the SIP headers to derive values for ISUP + parameters. + + A simple call-flow illustrating the different legs in the call is as + shown below. + + + + + + + + + + + + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 11] + +RFC 3372 SIP-T September 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-----| + +4. SIP-T Roles and Behavior + + There are three distinct sorts of elements (from a functional point + of view) in a SIP VoIP network that interconnects with the PSTN: + + 1. The originators of SIP signaling + + 2. The terminators of SIP signaling + + 3. The intermediaries that route SIP requests from the originator to + the terminator + + Behavior for the Section 4.1, Section 4.2 and Section 4.3 + intermediary roles in a SIP-T call are described in the following + sections. + +4.1 Originator + + The function of the originating user agent client is to generate the + SIP Call setup requests (i.e., INVITEs). When a call originates in + the PSTN, a gateway is the UAC; otherwise some native SIP endpoint is + the UAC. In either case, note that the originator generally cannot + anticipate what sort of entity the terminator will be, i.e., whether + final destination of the request is in a SIP network or the PSTN. + + + + + + + +Vemuri & Peterson Best Current Practice [Page 12] + +RFC 3372 SIP-T September 2002 + + + In the case of calls originating in the PSTN (see Figure 3 and Figure + 5), the originating gateway takes the necessary steps to preserve the + ISUP information by encapsulating it in the SIP request it creates. + The originating gateway is entrusted with the responsibility of + identifying the version of the ISUP (ETSI, ANSI, etc.) that it has + received and providing this information in the encapsulated ISUP + (usually by adding a multipart MIME body with appropriate MIME + headers). It then formulates the headers of the SIP INVITE request + from the parameters of the ISUP that it has received from the PSTN as + appropriate (see Section 5). This might, for instance, entail + setting the 'To:' header field in the INVITE to the reflect dialed + number (Called Party Number) of the received ISUP IAM. + + In other cases (like Figure 7), a SIP phone is the originator of a + VoIP call. Usually, the SIP phone sends requests to a SIP proxy that + is responsible for routing the request to an appropriate destination. + There is no ISUP to encapsulate at the user agent client, as there is + no PSTN interface. Although the call may terminate in the telephone + network and need to signal ISUP in order for that to take place, the + originator has no way to anticipate this and it would be foolhardy to + require that all SIP VoIP user agents have the capability to generate + ISUP. It is therefore not the responsibility of an IP endpoints like + a SIP phone to generate encapsulated ISUP. Thus, an originator must + generate the SIP signaling while performing ISUP encapsulation and + translation when possible (meaning when the call has originated in + the PSTN). + + Originator requirements: encapsulate ISUP, translate information from + ISUP to SIP, multipart MIME support (for gateways only) + +4.2 Terminator + + The SIP-T terminator is a consumer of the SIP calls. The terminator + is a standard SIP UA that can be either a gateway that interworks + with the PSTN or a SIP phone. + + + + + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 13] + +RFC 3372 SIP-T September 2002 + + + In case of PSTN terminations (see Figure 3 and Figure 7) the egress + gateway terminates the call to its PSTN interface. The terminator + generates the ISUP appropriate for signaling to the PSTN from the + incoming SIP message. Values for certain ISUP parameters may be + gleaned from the SIP headers or extracted directly from an + encapsulated ISUP body. Generally speaking, a gateway uses any + encapsulated ISUP as a template for the message it will send, but it + overwrites parameter values in the template as it translates SIP + headers or adds any parameter values that reflect its local policies + (see Appendix A item 1). + + In case of an IP termination (Figure 5), the SIP UAS that receives + SIP messages with encapsulated ISUP typically disregards the ISUP + message. This does introduce a general requirement, however, that + devices like SIP phones handle multipart MIME messages and unknown + MIME types gracefully (this is a baseline SIP requirement, but also a + place where vendors have been known to make shortcuts). + + Terminator requirements: standard SIP processing, interpretation of + encapsulated ISUP (for gateways only), support for multipart MIME, + graceful handling of unknown MIME content (for non-gateways only) + +4.3 Intermediary + + Intermediaries like proxy servers are entrusted with the task of + routing messages to one another, as well as gateways and SIP phones. + Each proxy server makes a forwarding decision for a SIP request based + on values of various headers, or 'routable elements' (including the + Request-URI, route headers, and potentially many other elements of a + SIP request). + + SIP-T does introduce some additional considerations for forwarding a + request that could lead to new features and requirements for + intermediaries. 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. Thus, proxy servers might take an interest in + the variants of ISUP that are encapsulated with requests - the + variant itself could become a routable element. The termination of a + call at a point that results in greater proximity to the final + destination (rate considerations) is also an important consideration. + The preference of one over the other results in a trade-off between + simplicity of operation and cost. The requirement of procuring a + reasonable rate may dictate that a SIP-T call spans dissimilar PSTN + interfaces (SIP bridging across different gateways that don't support + any ISUP variants in common). In order to optimize for maximum + feature transparency and rate, some operators of intermediaries might + want to consider practices along the following lines: + + + +Vemuri & Peterson Best Current Practice [Page 14] + +RFC 3372 SIP-T September 2002 + + + a) The need for ISUP feature transparency may necessitate ISUP + variant translation (conversion), i.e., conversion from one + variant of ISUP to another in order to facilitate the termination + of that call over a gateway interface that does not support the + ISUP variant of the originating PSTN interface. (See Appendix A + item 2.) Although in theory conversion may be performed at any + point in the path of the request, it is optimal to perform it at a + point that is at the greatest proximity to the terminating + gateway. This could be accomplished by delivering the call to an + application that might perform the conversion between variants. + Feature transparency in this case is contingent on the + availability of resources to perform ISUP conversion, and it + incurs an increase in the call-set up time. + + b) An alternative would be to sacrifice ISUP transparency by handing + the call off to a gateway 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. + + So, it may be desirable for proxy servers to have the intelligence to + make a judicious choice given the options available to it. + + Proxy requirements: ability to route based on choice of routable + elements + +4.4 Behavioral Requirements Summary + + If the SIP-T originator is a gateway that received an ISUP request, + it must always perform both encapsulation and translation ISUP, + regardless of where the originator might guess that the request will + terminate. + + If the terminator does not understand ISUP, it ignores it while + performing standard SIP processing. If the terminator does + understand ISUP, and needs to signal to the PSTN, it should reuse the + encapsulated ISUP if it understands the variant. The terminator + should perform the following steps: + + o Extract the ISUP from the message body, and use this ISUP as a + message template. Note that if there is no encapsulated ISUP in + the message, the gateway should use a canonical template for the + message type in question (a pre-populated ISUP message configured + in the gateway) instead. + + + + + + + +Vemuri & Peterson Best Current Practice [Page 15] + +RFC 3372 SIP-T September 2002 + + + o Translate the headers of the SIP request into ISUP parameters, + overwriting any values in the message template. + + o Apply any local policies in populating parameters. + + An intermediary must be able to route a call based on the choice of + routable elements in the SIP headers. + +5. Components of the SIP-T Protocol + + The mechanisms described in the following sections are the components + of SIP-T that provide the protocol functions entailed by the + requirements. + +5.1 Core SIP + + SIP-T uses the methods and procedures of SIP as defined by RFC 3261. + +5.2 Encapsulation + + Encapsulation of the PSTN signaling is one of the major requirements + of SIP-T. SIP-T uses multipart MIME bodies to enable SIP messages to + contain multiple payloads (Session Description Protocol or SDP [5], + ISUP, etc.). Numerous ISUP variants are in existence today; the ISUP + MIME type enable recipients too recognize the ISUP type (and thus + determine whether or not they support the variant) in the most + expeditious possible manner. One scheme for performing ISUP + encapsulation using multi-part MIME has been described in [2]. + +5.3 Translation + + Translation encompasses all aspects of signaling protocol conversion + between SIP and ISUP. There are essentially two components to the + problem of translation: + + 1. ISUP SIP message mapping: This describes a mapping between ISUP + and SIP at the message level. In SIP-T deployments gateways are + entrusted with the task of generating a specific 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 is sent when a particular SIP + message is received: an IAM must be sent on receipt of an INVITE, + a REL for BYE, and so on). A potential mapping between ISUP and + SIP messages has been described in [10]. + + + + + + + +Vemuri & Peterson Best Current Practice [Page 16] + +RFC 3372 SIP-T September 2002 + + + 2. ISUP parameter-SIP header mapping: A SIP request that is used to + set up a telephone call should contain information that enables + it to be appropriately routed to its destination by proxy servers + in the SIP network - for example, the telephone number dialed by + the originating user. It is important to standardize a set of + practices 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' header + field and Request-URI, etc.). This issue becomes inherently more + complicated by virtue of the fact that the headers of a SIP + request (especially an INVITE) may be transformed by + intermediaries, and that consequently, the SIP headers and + encapsulated ISUP bodies come to express conflicting values - + effectively, a part of the encapsulated ISUP may be rendered + irrelevant and obsolete. + +5.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 [3] + method should be used for this purpose. Note however that INFO is + not suitable for managing overlap dialing (for one way of + implementing overlap dialing see [11]). Also note that the use of + INFO for signaling mid-call DTMF signals is not recommended (see + RFC2833 [9] for a recommended mechanism). + +6. 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. Traditionally in SIP, if the terminating device does not + support a multipart payload (multipart/mixed) and/or the ISUP MIME + type, it would then reject the SIP request with a 415 Unsupported + Media Type specifying the media types it supports (by default, + 'application/SDP'). The originator would subsequently 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 thus 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 + (allowing a SIP phone to ignore an ISUP payload when processing ISUP + is not critical). This is contingent upon the terminator having + support for a Content-type of multipart/mixed and access to the + Content-Disposition header to express criticality. + + + + + +Vemuri & Peterson Best Current Practice [Page 17] + +RFC 3372 SIP-T September 2002 + + + 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 + the accepted. + + 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. + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 18] + +RFC 3372 SIP-T September 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--> + + 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 the exchanges of messages above are not complete; only the + messages relevant to this discussion are shown. Specifics of the + ISUP MIME type can be obtained from [2]. The 'version' and 'base' + parameters are not shown here, but must be used in accordance with + the rules of [2]. + +7. Security Considerations + + SIP-T can be employed as an interdomain signaling mechanism that may + be subject to pre-existing trust relationships between administrative + domains. In many legal environments, distribution of ISUP is + restricted to licensed carriers; SIP-T introduces some challenges in + so far as it bridges carrier signaling with end-user signaling. Any + administrative domain implementing SIP-T should have an adequate + security apparatus (including elements that manage any appropriate + policies to manage fraud and billing in an interdomain environment) + in place to ensure that the transmission of ISUP information does not + result in any security violations. + + Transporting ISUP in SIP bodies may provide opportunities for abuse, + fraud, and privacy concerns, especially when SIP-T requests can be + generated, inspected or modified by arbitrary SIP endpoints. ISUP + MIME bodies should be secured (preferably with S/MIME [4]) to + alleviate this concern, as is described in the Security + Considerations of the core SIP specification [1]. Authentication + properties provided by S/MIME would allow the recipient of a SIP-T + message to ensure that the ISUP MIME body was generated by an + + + + + +Vemuri & Peterson Best Current Practice [Page 19] + +RFC 3372 SIP-T September 2002 + + + authorized entity. Encryption would ensure that only carriers + possessing a particular decryption key are capable of inspecting + encapsulated ISUP MIME bodies in a SIP request. + + SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and + SHOULD support encryption (CMS EnvelopedData). + +8. IANA Considerations + + This document introduces no new considerations for IANA. + +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, May 2002. + + [2] 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. + + [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. + + [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC + 2633, June 1999. + + [5] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + +Non-Normative References + + [6] International Telecommunications Union, "Signaling System No. + 7; ISDN User Part Signaling procedures", ITU-T Q.764, September + 1997, . + + [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September + 2000. + + [8] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing + over IP (TRIP)", RFC 3219, January 2002. + + [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, + Telephony Tones and Telephony Signals", RFC 2833, May 2000. + + [10] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP + Mapping", Work in Progress. + + + + + +Vemuri & Peterson Best Current Practice [Page 20] + +RFC 3372 SIP-T September 2002 + + + [11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of + ISUP Overlap Signaling to SIP", Work in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vemuri & Peterson Best Current Practice [Page 21] + +RFC 3372 SIP-T September 2002 + + +Appendix A. Notes + + 1. Some terminating MGCs may alter the encapsulated ISUP in order to + remove any conditions specific to the originating circuit; for + example, continuity test flags in the Nature of Connection + Indicators, etc. + + 2. 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. + +Appendix B. Acknowledgments + + We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan + Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison + Mankin, Scott Bradner and Steve Bellovin for their valuable comments. + + The original 'SIP+' proposal for interconnecting portions of the PSTN + with SIP bridging was developed by Eric Zimmerer. + +Authors' Addresses + + Aparna Vemuri-Pattisam + Qwest Communications + 6000 Parkwood Pl + Dublin, OH 43016 US + EMail: Aparna.Vemuri@Qwest.com + vaparna10@yahoo.com + + 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 Best Current Practice [Page 22] + +RFC 3372 SIP-T September 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 Best Current Practice [Page 23] + -- cgit v1.2.3