Internet Engineering Task Force Adam Roach Internet Draft Ericsson Inc. Category: N/A June 1999 Expires January 2000 ISUP parameters expected in SIP messages Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract To assure inter-operability between gateways which may choose to transit ISUP messages inside a SIP network, this document seeks to outline the types of ISUP messages which an implementation can sensibly expect to arrive in each given SIP message. 1. Introduction Many implementors in the voice over IP field are exploring ways in which SIP can be used for long-haul of standard telephony traffic. In this model, SIP serves as an interim signalling protocol while the call is carried over the IP network. Unfortunately, SIP does not provide fields for most message parameters found in today's telephony networks. One of the dominant signalling protocols in use in modern telephony networks is the Signalling System No. 7 (SS7) ISDN User Part (ISUP). This general protocol is defined in ITU-T Recommendations Q.761 ( ref [7] ), Q.762 ( ref [8] ), Q.763 ( ref [9] ), and Q.764 ( ref [10] ). Adaptations of the ISUP protocol for the North American continent can be found in ANSI T1.113 ( Roach [Page 1] Internet Draft ISUP parameters expected in SIP messages June 1999 ref [6] ). To preserve this ISUP signalling when SIP is used between two ISUP gateways, it has been proposed that the messages sent over the SIP network would carry ISUP messages with roughly the same meaning as their SIP "host" messages (see ref [2] and ref [5] ). This type of transport is commonly referred to as "ISUP transparency" 2. Expected ISUP Messages This chapter outlines which ISUP messages can be expected and should be handled by SIP to ISUP gateways providing an ISUP transparency function. Any ISUP messages which arrive at times other than those described below may safely be treated as an error which terminates the call. 2.1. INVITE INVITE messages may contain IAM bodies. For overlap dialing detected by the ingress gateway, they can be expected to additionally carry one or more SAM messages; multiple ISUP messages may be attached as defined in "The multipart/sip-id media type" ( ref [3] ). [Note: it is currently unclear in this document whether such behavior is allowed] 2.2. 100 class response to INVITE INVITE 100 class responses can be expected to carry either ACM or CPG bodies. Since 100 class responses do not change the SIP call state, gateways should allow them to carry any arbitrary ISUP messages which do not cause changes to the call state. It can be reasonably expected that 100 class responses to INVITE will not contain ANM, CON, IAM, REL, or RLC messages. 2.3. 200 class response to INVITE INVITE 200 class responses will carry ANM or CON messages. If the implementor so desires, they may also carry ACM messages accompanied by ANM messages (the benefits of doing so are not obvious; however, there is no reason to prohibit such behavior). Multiple ISUP messages may be attached as defined in "The mulitpart/sip-id media type" ( ref [3] ). [Note: it is currently unclear in this document whether such behavior is allowed] 2.4. 300+ response to INVITE INVITE responses which terminate the transaction may carry any number of call terminating messages; specifically, REL, RSC, RLC, GRS, CGB, and UCIC may be expected in response to these types of Roach [Page 2] Internet Draft ISUP parameters expected in SIP messages June 1999 messages. 2.5. ACK Although normally empty, ACK messages can be expected to carry RLC messages when acknowledging a 300 class or higher response. The value of providing transparency for RLC is not immediately apparent; however, there have been proposals to include, among other things, billing information in RLC messages for certain networks. SIP gateways should not preclude this capability unless absolutely necessary. As an aside, note that intervening proxies' behavior of locally acknowledging error responses will destroy the ability to carry RLC messages end to end. 2.6. CANCEL and BYE As in the case of INVITE error responses, any call terminating ISUP message can be expected in a CANCEL or BYE request; specifically: REL, RSC, RLC, GRS, and CGB. 2.7. Response to CANCEL and BYE CANCEL and BYE responses may contain RLC messages. See section 2.5 for the rationale for transporting RLC messages. Note that proxies' behavior of locally responding to CANCEL messages has the same effect as is described in that section. 2.8. INFO See "The SIP INFO Method" ( ref [4] ) for information on the proposed semantics and syntax for INFO. Due to its nature, the INFO method can be expected to carry any arbitrary ISUP message; however, it can be reasonably expected that it will not contain messages that make a change to call state about which the SIP network should be aware; specifically, it is expected that INFO will not contain ACM, ANM, CON, IAM, REL, or RLC messages. 2.9. Other Messages It is expected that neither OPTIONS nor REGISTER requests or responses will carry ISUP payloads of any type. 3. References [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; March 1999. [2] Christian Huitema, "The application/ISUP media type", Roach [Page 3] Internet Draft ISUP parameters expected in SIP messages June 1999 Internet Draft , IETF; Feb. 1999. Work in progress. [3] Christian Huitema, "The multipart/sip-id media type", Internet Draft , IETF; Feb. 1999. Work in progress. [4] Steven R. Donovan, "The SIP INFO Method", Internet Draft , IETF; Feb. 1999. Work in progress. [5] Eric Zimmerer, "SIP+ (Inter MGC Protocol)," Edition 0.0, Draft 0.1, Level 3; Dec. 1998. Work in progress. [6] "Signalling System No. 7 (SS7) -- Integrated Services Digital Network (ISDN) User Part", ANSI T1.113-1995; Jan. 1995. [7] "Functional Description of the ISDN User Part of Signalling System No. 7", ITU-T Recommendation Q.761; Mar. 1993. [8] "General Function of Messages and Signals of the ISDN User Part of Signalling System No. 7", ITU-T Recommendation Q.762; Mar. 1993. [9] "Formats and Codes of the ISDN User Part of Signalling System No. 7", ITU-T Recommendation Q.763; Mar. 1993. [10] "Formats and Codes of the ISDN User Part of Signalling System No. 7, ISDN User Part Signalling Procedures", ITU-T Recommendation Q.764; Mar. 1993. 4. Security Considerations This document introduces no new security considerations beyond those already discussed in the referenced documents. 5. Author's Address Adam Roach Ericsson Inc. Mailstop L-04 851 International Pkwy. Richardson, TX 75081 USA Phone: 972-583-7594 Fax: 972-669-0154 E-Mail: adam.roach@ericsson.com Roach [Page 4]