Internet Engineering Task Force         L. Ong, F. Audet, M. Zonoun
Internet Draft                                      Nortel Networks
draft-ong-sip-qsig-mime-00.txt                          E. Zimmerer
October 1999                                          ipVerse, Inc.
Expires: April 2000                                       A. Vemuri
                                              Level3 Communications

                       The SIP QSIG/MIME type

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.  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.

1. Abstract

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

2. Introduction

The QSIG family of standards provides connectivity between corporate network
switches, Centrex switches as well as corporate network to Centrex switches.
Qsig standards also specifies a set of supplementary services, the service
specific "QSIG" signalling protocols for the exchange of information between
switches across an interface at the "Q" reference point.

QSIG basic call is essentially a symmetrical (peer-to-peer) version of ISDN
DSS1. QSIG also adds generic procedures for the support of supplementary
services. These procedures allow for standardized and proprietary
supplementary services to coexist in a graceful manner. There is a need to
transport QSIG messages between MGCs as part of the payload of SIP [2]
messages. The following discussion is specific to this usage and would not
apply to the transportation of QSIG messages in other applications.

3. The application/QSIG media type

The QSIG messages are composed of arbitrary binary data. The proposed way to
encode these is 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

draft-ong-sip-qsig-mime-00                                                  1
Internet Draft                QSIG MIME Type                 October 20, 1999

mail messages and not to SIP messages. This approach is consistent with
encoding of ISUP signalling over SIP.

The application/QSIG media type is defined by the following information:

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


The use of the 'version' parameter allows differentiation between different
QSIG variants.


This enables the terminating Connection Server to recognize and parse the
message correctly, or (possibly) to reject the message if the  particular
QSIG variant is not supported. The idea here is to allow to specify a
preference of version, so that the following scenarios are possible: "I
only like application/QSIG;version=ISO" or "I accept application/QSIG
(but don't really know the details; I just pass them on to some other tool
that displays/munges them)".

The following is how a typical header would look:-

        Content-Type: application/QSIG; Version: ISO
        Content-Transfer-Encoding: binary

Table 1 is a partial list of protocol versions supported by the
'application/QSIG' media type.

        Version         Protocol
        -------         --------
        ISO             ISO/IEC 11572


4. 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/QSIG' media type, below is an INVITE message which has the
originating SDP information and an encapsulated QSIG SETUP message.


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/QSIG' media type.




draft-ong-sip-qsig-mime-00                                                  2
Internet Draft                QSIG MIME Type                 October 20, 1999


        INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0
        From: sip:14085655675@sc10.nortelnetworks.com
        To: sip:14084955072@sc1.nortelnetworks.com
        Call-ID: 1231999021712095500999@sc12.nortelnetworks.com
        Content-Length: 393
        Content-Type: multipart/mixed; boundary=unique-boundary-1
        MIME-Version: 1.0

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

        v=0
        o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4
        s=SDP seminar
        c=IN IP4 MG141.nortelnetworks.com
        t= 2873397496 2873404696
        m=audio 9092 RTP/AVP 0 3 4

        --unique-boundary-1
        Content-type:application/QSIG;version=ISO
        Content-Transfer-Encoding: binary

        08 02 55 55 05 04 02 90 90 18 03 a1 83 01
        70 0a 89 31 34 30 38 34 39 35 35 30 37 32


        --unique-boundary-1--



5. Security considerations

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

6. Authors

L. Ong                         F. Audet / M. Zonoun
4401 Great America Parkway     2305 Mission College Blvd
Santa Clara, CA 95054          Santa Clara, CA 95054
long@nortelnetworks.com        audet@nortelnetworks.com
                               mzonoun@nortelnetworks.com

Eric Zimmerer
ipVerse, Inc.
1901 Landings Drive
Mountain View, CA 94043, USA
Phone: 650-919-0648
Email: ericz@ipverse.com




draft-ong-sip-qsig-mime-00                                                  3
Internet Draft                QSIG MIME Type                 October 20, 1999


Aparna Vemuri
Level 3 Communications
Louisville, CO, USA
Phone: 303-926-3768
EMail: aparna.vemuri@level3.com

7. 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] ISO/IEC 11572 Ed. 2 (1997-06), "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol"

[6] ISO/IEC 11582 (1995-07), "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Generic functional protocol for the support of supplementary services - Inter-exchange signalling procedures and protocol"



This draft expires April 2000.


















draft-ong-sip-qsig-mime-00                                                  4