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

Versions: 00

Internet Engineering Task Force                             Mark Watson
Internet Draft                                      Nortel Networks, UK
Document: draft-watson-sip-isup-mime-00.txt                October 1999
Expires: April 2000

                      MIME type for ISUP messages

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 made obsolete 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.

1. Abstract

   This document proposes the definition of an application/isup media
   type, according to the rules defined in RFC 2048 [1], which will
   allow the carriage of ITU-T Signalling System No. 7 ISDN User Part
   messages within MIME compliant message bodies.

2. Introduction

   Signalling System No. 7 is defined by the ITU-T for use between ISDN
   and Telephony exchanges for call control and support of
   supplementary services and features within ISDNs and PSTNs. The ISDN
   User Part supports the standard features of ISDNs and has also been
   extended by regional and national standards bodies throughout the
   world to support local and regional PSTN and ISDN services.

   In order that these same services may be supported on calls which
   traverse an Internet Protocol environment it is necessary to carry
   these messages between call control entities (e.g. `SoftSwitches').

   This draft defines a MIME type which could be used in association
   with an Internet Protocol based basic call control protocol (such as
   SIP [2]) to achieve this.

3. Regional and National Variants of ISUP

Watson                    Expires April 2000                         1
                  draft-watson-sip-isup-mime-00.txt       October 1999

   Many national and regional standards bodies around the world have
   defined extensions to ISUP which provide for support of local and
   regional ISDN and PSTN services. An ISUP standard with such
   extensions is known as a `variant'.

   There is therefore a need for the entity receiving the ISUP message
   to know the variant it is receiving in order to process it
   correctly.

   The simplest way to achieve this is by including some kind of
   `variant' indication within a parameter to the MIME type/sub-type.
   This could be a single parameter and names for the variants could be
   registered as required.

   However, the above approach has a key disadvantage in that it is
   necessary for the originating SoftSwitch to have static knowledge of
   the ISUP variants supported by all the terminating softswitchs it
   may directly communicate with.

   This is not an unusual requirement in an ISDN/PSTN network, where
   the connections to terminating switches are physical TDM circuits.
   However in an IP domain, the relationships between originating and
   terminating switch/UA are likely to be much more dynamic.

   In particular, the actual terminating softswitch may be identified
   by an intermediate SIP Proxy, and not by the originating switch at
   all. It may therefore be impossible for the originating node to
   ensure that the variant it sends out will be understood by the
   terminating node.

   It is also not possible to define a `least common denominator' to be
   used between softswitchs since this would exclude the case that the
   variant is understood by the terminating node and that
   national/regional extensions are required for the call.

   Fortunately, the structure of ISUP and its variants offers a simple
   solution to this problem. Since the definition of `White Book' ISUP
   in 1992, the protocol has included a `Compatibility Mechanism' which
   allows new parameters to be accompanied by `Instruction Indicators'
   detailing how they should be handled by nodes which do not
   understand the new information.

   In particular, parameters and messages introduced as part of a
   regional/national variant of ISUP will be accompanied by such
   indicators and therefore interworking between this national variant
   and the `base' protocol can be carried out by a node which supports
   only the `base' from which the national variant is derived.

   In fact, even if the Compatibility Mechanism is not used, it is
   possible to tell from the parameter name when it is an extension

Watson                    Expires April 2000                         2
                  draft-watson-sip-isup-mime-00.txt       October 1999

   introduced by a national standards body, as these names are
   allocated from a particular range of values.

   To support interworking from an unknown variant to the base ISUP, it
   is necessary to indicate to the terminating switch not only the
   variant name, but also the `base' version of ISUP from which it is
   derived.

4. `Base' versions of ISUP

   ISUP is ultimately defined by the ITU-T and all variants of ISUP are
   derived from ITU-T Recommendations. For the purpose described here
   is necessary only to make the distinction between those ISUP
   recommendations that include the Compatibility Mechanism and those
   which do not i.e. between `Blue Book' ISUP and `White Book' and
   later versions.

   In addition, regional standards bodies have defined extensions to
   ISUP (and perhaps more significantly, subsets to be used in that
   region). It will be of necessary for a node which understands ETSI
   ISUP for instance to be aware that an incoming unrecognised ISUP is
   based on ETSI in order to interworking it to ETSI ISUP, and not just
   the base ITU-T version. The node may wish to do this to support
   regional regulatory requirments which are defined as part of the
   regional enhancements to ISUP.

   The regional ISUP versions therefore also need to be identified.

5. The application/isup media type

   ISUP messages are composed of arbitrary binary data. The best way to
   encode these would be to use binary encoding. This is in conformance
   with the restrictions imposed on the use of binary data for MIME
   (RFC 2045 [3]). It should be noted that the rules mentioned in the
   RFC 2045 apply to Internet mail messages and not to SIP messages.
   Binary has been preferred over Base64 encoding because the latter
   would only result in adding bulk to the encoded messages as well as
   prove costly in terms of processing power.

   The binary data begins with the ISUP Message Type Code and continues
   as defined in Figure 3/Q.763 [5].

   This media type is defined by the following information:

   Media type name: application
   Media subtype name: isup
   Required parameters: none
   Optional parameters: base, version, variant
   Encoding scheme: binary
   Security considerations: See section 5.

Watson                    Expires April 2000                         3
                  draft-watson-sip-isup-mime-00.txt       October 1999

   Note: It is mandatory for SoftSwitches to specify the `base' of
   the ISUP message. Proxies, redirect servers, etc., have no need to
   process/specify this information.

   Table 1 is a partial list of the values of the `base' parameter and
   the values of `version' which are applicable to each. Values of the
   `variant' parameter should be registered by the standards body
   responsible for defining the variant.

   `base'       `version'          Specification
   ---------------------------------------------
   bluebook     etsi               ETS 300 121
                ansi               ?
   whitebook    etsi               EN 300 356
                ansi               ?
                gr317              Bellcore GR317

   The following is an example of a typical header:-

        Content-Type: application/ISUP; base=whitebook; version=etsi
        Content-Transfer-Encoding: binary

6. Illustrative example

   SIP message format requires a Request line followed by Header lines
   followed by a CRLF separator followed by the message body. To
   illustrate the use of the 'application/isup' media type, below is an
   INVITE message which has the originating SDP information and an
   encapsulated ISUP IAM.

   Note that the two payloads are demarcated by the boundary parameter
   (specified in RFC 2046 [4]) which in the example has the value
   "unique-boundary-1". This is part of the specification of MIME
   multipart and is not related to the 'application/isup' media type.

                INVITE sip:01628434456@dcs1.nortelnetworks.com SIP/2.0
        From: sip:01628434141@dcs3.nortelnetworks.com
        To: sip:01628434456@dcs1.nortelnetworks.com
        Call-ID: DCS22101999121100000001@dcs1.nortelnetworks.com
        Content-Type: Application/Multipart
        Content-Length: 327

        MIME-Version: 1.0
        Content-Type: multipart/mixed; boundary=unique-boundary-1

        --unique-boundary-1
        Content-Type: application/SDP; charset=ISO-10646

        v=0

Watson                    Expires April 2000                         4
                  draft-watson-sip-isup-mime-00.txt       October 1999

        o=mwatson 2890844526 2890842807 IN IP4 47.96.4.192
        s=SDP seminar
        c=IN IP4 MG122.nortelnetworks.com
        t= 2873397496   2873404696
        m=audio 9092 RTP/AVP 0 3 4

        --unique-boundary-1
        Content-type:application/isup; base=whitebook; version=etsi;
   variant=uk21
        Content-Transfer-Encoding: binary

        01 00 00 01 0A 00 02 09 07 03 10 16 28 43 44 56 FE 02 01 00 39
   02 FE BO 00

        --unique-boundary-1--

7. Security Considerations

   The security mechanisms described in RFC 2543 (SIP - Session
   Initiation Protocol) should suffice. No new security considerations
   are thought necessary.

9. References

   [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions
   (MIME)
   Part Four: Registration Procedures" RFC 2048, Internet Engineering
   Task Force, November 1996.

   [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session
   Initiation
   Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March
   1999.

   [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME)
   Part
   One: Format of Internet Message Bodies" RFC 2045, Internet
   Engineering
   Task Force, November 1996.

   [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME)
   Part
   Two: Media Types" RFC 2046, Internet Engineering Task Force,
   November
   1996.

   [5] ITU-T Recommendation Q.763

10.  Acknowledgments

Watson                    Expires April 2000                         5
                  draft-watson-sip-isup-mime-00.txt       October 1999

   This draft has drawn on draft-zimmerer-mmusic-sip-isup-mime-00.txt
   by Eric Zimmerer.

11. Author's Addresses

   Mark Watson
   Nortel Networks
   Foundation Park
   Maidenhead, Berks, SL6 3UD, UK
   Phone: +44 1628 434456
   Email: mwatson@nortelnetworks.com

Watson                    Expires April 2000                         6


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