One document matched: draft-ietf-sigtran-mime-isup-00.txt

Internet Engineering Task Force                        Christian Huitema
INTERNET DRAFT                                                  Bellcore
February 2, 1999                                  Expires August 2, 1999
                                   <draft-ietf-sigtran-mime-isup-00.txt>


                    The application/ISUP media type




Status of this document

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."

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

This document proposes the definition of an application/ISUP media type,
according to the rules defined in RFC 2048.

1.  Motivation

Many signalling exchanges between telephony switches follow the "ISDN
User Part of Signalling System No. 7" (ISUP), that the ITU defines in
recommendation Q.761, Q.762, Q.763 and Q.764, or one of its national
variants. As gateways between the Internet and the public, there is a
need to transport ISUP messages as "content" or "body parts" of Internet
messages.

This memo proposes a definition of an "application/ISUP" media type,



Huitema                                                         [Page 1[]]

Internet draft      The application/ISUP media type     February 2, 1999


according to the rules defined in RFC 2048.

This memo does not attempt to define when and how such messages could be
used.

2.  The application/isup media type

The corresponding media type is defined by the following information:

     Media Type name: application
     Media subtype name: ISUP
     Required parameters: none
     Optional parameters: variant, headers
     Encoding considerations: binary or base64
     Security considerations: see section 5.
     Published specification: ITU recommendation Q.763

The variant parameter is used to denote the presence of a "national
variant" of the ISUP protocol.  The syntax of this parameter is defined
by the following ABNF notations (as defined in RFC 2234):

     parameter = "content" "=" value
     value =  DQUOTE national-variant-code DQUOTE

The national variant code is normally set to the 2 upper case letter
country-code of the nation defining the variant, such as "BR" for Bra-
zil.

The format of the ISUP message is specified in Q.763.  Messages confor-
maing to this specification include five parts: the Routing label, the
Circuit identification code, the Message type code, the Mandatory fixed
part, the Mandatory variable part and the Optional part. The "headers"
parameter is used to identify whether the body part includes the Routing
label and the Circuit Identification Code (CIC). The syntax of this
parameter is defined by the following ABNF notations:

     parameter = "header" "=" header-value
     header-value =  (DQUOTE "routing" DQUOTE)
                  /  (DQUOTE "CIC" DQUOTE)
                  /  (DQUOTE "none" DQUOTE)

The value "routing" indicates that both the routing label and the CIC
are included in the body part. The value "CIC" indicates that the rout-
ing label is not included, but that the CIC is included.  The value
"none" indicates that neither the routing lable nor the CIC are
included.





Huitema                                                         [Page 2[]]

Internet draft      The application/ISUP media type     February 2, 1999


3.  References

[1]  ITU-T, Recommendation Q.761, "Functional Description of the ISDN
     User Part of Signalling System No. 7", (Malaga-Torremolinos, 1984;
     modified at Helsinki, 1993)

[2]  ITU-T, Recommendation Q.762, "General Function of Messages and Sig-
     nals of the ISDN User Part of Signalling System No. 7", (Malaga-
     Torremolinos, 1984; modified at Helsinki, 1993)

[3]  ITU-T, Recommendation Q.763, "Formats and Codes of the ISDN User
     Part of Signalling System No. 7", (Malaga-Torremolinos, 1984; modi-
     fied at Helsinki, 1993)

[4]  ITU-T, Recommendation Q.764, "Formats and Codes of the ISDN User
     Part of Signalling System No. 7, ISDN User Part Signalling Pro-
     cedures", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993)

[5]  Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, November 1997.

[6]  Freed, N., J. Klensin, J. Postel. "Multipurpose Internet Mail
     Extensions (MIME) Part Four: Registration Procedures." RFC 2048,
     November 1996.

4.  Authors' Addresses

                   Christian Huitema
                   Bellcore
                   MCC 1J236B
                   445 South Street
                   Morristown, NJ 07960
                   U.S.A.

                   Phone: +1 973-829-4266
                   EMail: huitema@bellcore.com















Huitema                                                         [Page 3[]]