[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               Adam Roach
Internet Draft                                             Ericsson Inc.
Category: N/A                                                  June 1999
                                                    Expires January 2000
                                <draft-roach-sip-isup-parameters-00.txt>

                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 <draft-ietf-sigtran-mime-isup-00.txt>, IETF;
         Feb. 1999. Work in progress.

     [3] Christian Huitema, "The multipart/sip-id media type",
         Internet Draft <draft-ietf-mmusic-sip-multipart-00.txt>,
         IETF; Feb. 1999. Work in progress.

     [4] Steven R. Donovan, "The SIP INFO Method", Internet Draft
         <draft-ietf-mmusic-sip-info-method-00.txt>, 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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/