Internet Engineering Task Force R. Mukundan V. Seshasayee Wipro Technologies K. Morneault Cisco Systems R. Shiroor Sasken Communication Narsimuloo Mangalpally Nortel Networks S. Naganathan Hughes Software Systems Expires in December 2003 June 2003 MIME media types for DPNSS Objects 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 Abstract This document describes Multipart Internet Mail Extensions (MIME) type for application/Digital Private Network Signaling System (DPNSS) objects for use in Session Initiation Protocol (SIP) applications, according to the rules defined in RFC 2048. These types can be used to identify Digital Private Network Signaling System 1 (DPNSS 1) objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a similar need for Integrated Service Digital Network User Part (ISUP) and Q Signaling (QSIG). Mukundan, et al. [Page 1] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 1. Introduction DPNSS 1 [2], henceforth referred to as just DPNSS, is an industry standard private-Network Node Interface (NNI) - specified by Office of Telecommunication's (Oftel) Network Interoperability Consultative Committee (NICC) document, ND1301:2001/03 [2] (previously definined by British Telecom Network Requirements (BTNR) 188 [11]). It is defined between a Private Branch Exchange (PBX) and an Access Network (AN). DPNSS extends facilities normally only available between extensions on a single PBX to all extensions on PBXs that are connected together in a private network. There are configurations in which DPNSS encoded signaling information needs to be transported between SIP [3] entities as part of the payload of SIP messages, where the preservation of DPNSS data is necessary for the proper operation of DPNSS based, private network features. DPNSS call signalling and end-to-end signalling messages' semantic is similar to that of SIP - there by rendering the SIP-T [12] architecture as an appropriate mechanism of DPNSS message object carriage in SIP. There exists equivalent, currently deployed, mechanisms that allow carriage of DPNSS data transparently over an ISUP network in a SS7 environment or over an H.323 network in a IP based environment where part of the call involves interworking to DPNSS based Private Networks. The Figure 1 below depicts a typical setup where application/DPNSS media type could be used. +---+ +-----+ +---------+ / \ +---------+ +-----+ | | | | / \ | | | | |DPNSS|--DPNSS--|DPNSS-SIP|--+ SIP +--|DPNSS-SIP|--DPNSS--|DPNSS| | PBX | (E1/T1) | Gateway| | N/w | | Gateway | | PBX | +-----+ +---------+ \ / +---------+ +-----+ +-----+ Figure 1: Typical Network Configuration for application/DPNSS in SIP There could also be 'mixed' configurations, where DPNSS data may have to be transparently passed between DPNSS based private networks over intervening SIP *and* ISUP networks - where the DPNSS data encapsulated in the ISUP message could be transferred over SIP network using the application/DPNSS media type defined in this document. This document is specific to the transport of DPNSS data between SIP entities and would not apply to the transportation of DPNSS messages in other applications. This media type is intended for DPNSS application information that is used within the context of a SIP session, and not as a general purpose transport of Switched Circuit Network (SCN) signaling. Mukundan, et al. [Page 2] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 The definition of media type for DPNSS application information does not address fully how the non-SIP and SIP entities exchanging messages determine or negotiate compatibility. It is assumed that this is addressed by alternative means such as the configuration of the interworking functions. This document also does not address aspects of interworking messages and parameters between DPNSS and SIP networks. This is intended to be an IETF approved MIME type, and to be defined through an RFC. 2. The application/DPNSS media type DPNSS messages are composed of arbitrarily occurring (in terms of the octets' position in the message), heterogeneously encoded International Reference Alphabet (IRA; previously known as International Alphabet No.5 or IA5) [10] binary octets. Further, the IRA binary encoded octets could either be 1B2I-IRA or 3B4I-IRA encoded (refer to Oftel's ND1301:2001/03, Section 4, Annex 2, Issue 7, Sub-section 5 for the definition of 1B2I/3B4I-IA5 encoding) - all formatted as per the syntax defined in Oftel's ND1301:2001/03, that is transparent to SIP processing. Hence, the best way to encode application/DPNSS as a MIME object is to use binary encoding. This is in conformance with the restrictions imposed on the use of binary data for MIME (RFC 2045 [5]). Note that, the rules mentioned in the RFC 2045 apply to Internet mail messages and not to SIP messages. DPNSS layer 3 messages, as defined by ND1301:2001/03, do not have a message length field. The application/DPNSS mime encoded data shall be prepended (before DPNSS Message Group/Type message header) with a single binary coded octet message length field that represents the decimal value of the message length. Hence, though a DPNSS layer 3 message as defined by ND1301:2001/03, can only be a maximum of 45 octets, the binary encoded MIME representation of application/DPNSS can be a maximum of 46 octets. The message length field value shall indicate the actual length of DPNSS layer 3 message being MIME encoded - hence, it's decimal value can range from 1 to 45 based on the DPNSS layer 3 message length. Though the number of bytes of DPNSS data received can be computed (for example, by doing a byte count of the MIME body content) by the DPNSS layer 3 application at the receiver end, the (apparently redundant) message length field will aid easy implementation of processing the DPNSS data at the receiver end. A typical implementation would remove the message length octet before passing on the DPNSS data to the DPNSS layer 3 application; the message length can be passed on to the DPNSS layer 3 application using a primitive of local significance. Refer section 4 - 'Illustrative example' for additional details. Mukundan, et al. [Page 3] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 2.1 Message Buffering Option ND1301:2001/03, specifies the DPNSS layer 3 message length to be a maximum of 45 octets. This max limit on the layer 3 message length is arrived at based on the max limit set on the Information field of the UI(C) (Unnumbered Information-Complete), DPNSS layer 2 frame. However, for communication between two peer DPNSS layer 3 applications over an intervening SIP network, it would be desirable to buffer multiple DPNSS 'incomplete' ('incomplete' as defined in ND1303:2001/03) messages (e.g., buffer multiple EEM-Is; EEM-Is are DPNSS layer 3 End-to-End incomplete messages) at the sender's end and transfer it as a single DPNSS 'complete' ('complete' as defined in ND1301:2001/03) or 'incomplete' message (e.g., as a single EEM-C or EEM-I; an EEM-C is a DPNSS layer 3 End-to-End complete message) in the MIME body. It is up to the sending and receiving DPNSS layer 3 application to handle the 'oversized' DPNSS layer 3 messages - for e.g., the receiving DPNSS layer 3 application could fragment the 'oversized' DPNSS 'complete' message to it's constituent 'incomplete' messages at the start of message processing. It is assumed that the availability of support for this buffering option would be known beforehand by way of configuration (e.g., BUFFERING = YES/NO provisioned for a DPNSS network or interface) or other alternative means. This simple buffering method would improve the real-time performance for DPNSS layer 3 message processing and reduces the number of SIP messages required (and consequently the signaling traffic and associated overheads). For example, it would be more efficient to send one DPNSS layer 3 EEM-C of 221 octets as a MIME object in one SIP message instead of sending five DPNSS layer 3 EEM-Is of 45 Octets each as MIME object in 5 SIP messages. Note that, as is evident from this example, only the Indication fields are concatenated and the same message type octet is used for the new oversized Indication field - leaving the overall syntax of the messages unaffected, except for the overall size. Hence, with the Message Buffering option, the binary encoded MIME representation of application/DPNSS can be a maximum of 255 octets. The message length field value shall indicate the actual length of buffered DPNSS layer 3 message being MIME encoded - hence, it's decimal value can range from 1 to 255 based on the buffered DPNSS layer 3 message length. Mukundan, et al. [Page 4] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 The buffering shall be applicable only to 'incomplete' segmented DPNSS layer 3 messages. For example, multiple EEM-Is can be buffered and sent as one EEM-C or as one EEM-I (if the length of the buffered EEM-Is were to exceed 255 octets); buffering shall not be applied to multiple EEM-Cs or fragments of EEM-Is and/or EEM-Cs. Also, buffering shall not affect the syntax of the DPNSS layer 3 messages (e.g., only the Selection Field and Indication Field can be concatenated to form an oversized Selection or Indication Field) except for it's overall size. The buffering option shall not be applicable to 'incomplete' messages that are not a result of segmentation of messages - i.e., the buffering option shall not be applicable to messages such as ISRM-Is, SSRM-Is or EEM-Is that are a result of overlap signaling procedures or other such non-segmentation equivalent procedures. An exception to this is when the DPNSS <-> SIP gateway is executing a DPNSS transit function - in which case, it must buffer the EEM-Is based on a PBX specfic timer, irrespective of the buffering option. As indicated in ND1301:2001/03, segmentation of DPNSS layer 3 messages occurs, when the message Protocol Data Unit (PDU) boundary exeeds 45 octets - buffering shall only be applicable to such messages, resulting from segmentation. Implementation of the buffering mechanism for the incomplete segmented messages can be based on a PBX specific "segmentation timer" similar to the PBX specific transit timer used for concatenating multiple EEM-Is at a transit PBX. Though, buffering is specified as an option (rather than as a mandatory requirement for carriage of DPNSS objects in SIP), it is strongly recommended that this option be implemented and used, for the obvious network usage efficiency it offers. However, as there already are DPNSS gateway implementations that does not employ buffering options whilst interworking to H.323 or SS7 networks, retaining buffering as an option allows for a smoother migration path vis-a-vis mandating it. 2.2 DPNSS <-> SIP Gateway as a Transit PBX function In order to ensure the proper functioning of the various end-node procedures and timers despite the delay that an intervening IP based SIP network might potentially introduce, the DPNSS <-> SIP gateway shall be conformant to the DPNSS transit functionality as specified by ND1301:2001/03. For example, the DPNSS <-> SIP gateway shall buffer all the EEM-Is before passing it on over the SIP network irrespective of the buffering option described in the previous section - based on a PBX specific incoming EEM-I time-out timer at the DPNSS <-> SIP gateway. Similarly, the gateway shall respond with a CIM on receipt of a CRM apart from passing the CRM on the SIP side as a MIME object. Mukundan, et al. [Page 5] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 2.3 Single DPNSS call per SIP dialogue Support of multiple DPNSS calls in series and/or in parallel over a semi-permanent SIP dialogue, is not considered in this specification. This document deals with supporing just one DPNSS call per SIP dialogue. 3. The DPNSS Media Type This media type is defined by the following information: Media type name: application Media subtype name: DPNSS Required parameters: none Optional parameters: version Encoding scheme: binary Security considerations: See section 5. 3.1 The Version Parameter The use of the 'version' parameter allows identification of different versions (indicative of the issue of ND1301:2001/03 - previously BTNR 188 publication) of DPNSS protocol specification. This allows for correct interoperation amongst DPNSS PBXs supporting different issues of the DPNSS protocol. Though the DPNSS protocol is 'specification-wise' perfectly (backward/forward) compatible with the different issue versions, the introduction of an explict version parameter would help in better 'protocol de-bugging', whilst interconnecting PBXs compliant to different issues of ND1301:2001/03 [2] or BTNR [11]. Table 1 below is a list of protocol issues supported by the 'application/DPNSS' media type. Table 1: DPNSS Protocol issues version protocol ------- ------------------------------------------------ 1.00 DPNSS protocol issue 1 (BTNR 188, May 1983) 2.00 DPNSS protocol issue 2 (BTNR 188, February 1984) 3.00 DPNSS protocol issue 3 (BTNR 188, September 1984) 4.00 DPNSS protocol issue 4 (BTNR 188, March 1986) 5.00 DPNSS protocol issue 5 (BTNR 188, December 1989) 6.00 DPNSS protocol issue 6 (BTNR 188, January 1995) 7.00 DPNSS protocol issue 7 (ND1301:2001/03, March 2001) Mukundan, et al. [Page 6] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 To support new issues of DPNSS protocol specification, that may be published in the future, the 'version' field shall be a decimal value and shall have one-to-one correspondence with the ND1301:2001/03 or BTNR DPNSS protocol specification issue number. For example, if a new DPNSS protocol specification issue 8 were to be released in June 2004, then the 'version' value will be 8.00; if the one released next were to have the issue number 8.1, then the 'version' value will be 8.10; the one with sub-issue number 8.11 (in case there were to be sub-issues as well in the future) will have 'version' value of 8.11 and so on. 3.2 The Content-Disposition Header The DPNSS Media type shall use the Content-Disposition header defined in RFC 3204 [9]. The Content-Disposition header [7] may be included to describe how the encapsulated DPNSS is to be processed, and in particular what the handling should be if the received Content-Type is not recognized. The default disposition-type for a DPNSS message body is "signal". This type indicates that the body part contains signaling information associated with the session, but does not describe the session. Supplementing the description of the Content-Disposition header in [7], as well as any characterization of the Content-Disposition header in the SIP standard, is the following BNF describing disposition-types and disposition-params that may be used in the header of DPNSS MIME bodies. This is reproduced here from RFC 3204 as-is. Content-Disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-param ) disposition-type = "signal" | disp-extension-token disposition-param = "handling" "=" ( "optional" | "required" | other-handling ) | generic-param other-handling = token disp-extension-token = token The following is how a typical header would look: Content-Type: application/DPNSS; version=6.00 Content-Disposition: signal; handling=optional The handling parameter, handling-parm, describes how the SIP User Agent Server (UAS) process should react if it receives a message body whose content type or disposition type it does not understand. If the parameter has the value "optional", the UAS MUST ignore the message body; if it has the value "required", the UAS MUST return 415 (Unsupported Media Type). If the handling parameter is missing, the value "required" is to be assumed. 4. Illustrative example Mukundan, et al. [Page 7] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 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/DPNSS' media type, below is an INVITE message which has the originating SDP information and an encapsulated DPNSS Initial Service Request Message (ISRM). Note that the two payloads are demarcated by the boundary parameter (specified in RFC 2046 [6]) which in the example has the value "unique-mime-boundary". INVITE sip:91805538301@k1.wipro.com SIP/2.0 Via: SIP/2.0/UDP ec.wipro.com From: sip:91808520408@ec.wipro.com To: sip:91805538301@k1.wipro.com Call-ID: EC43234589182765500455555@ec.wipro.com CSeq: 4567 INVITE Contact: Content-Length: 384 Content-Type: multipart/mixed; boundary=unique-mime-boundary MIME-Version: 1.0 --unique-mime-boundary Content-Type: application/SDP; charset=ISO-10646 v=0 o=dummy 2890844526 2890842807 IN IP4 166.218.71.81 s=SDP seminar c=IN IP4 MG121.wipro.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-mime-boundary Content-Type: application/DPNSS; version=1; Content-Disposition: signal; handling=optional 24 00 10 2A 31 23 2A 35 30 2A 38 37 32 38 38 35 38 23 35 39 30 32 33 36 30 --unique-mime-boundary In this example: Message length = 24 Message type = 00 (ISRM) Service Indication Code (SIC) = 10 (64 kbs A-law Speech) Calling Line Category (CLC) = 1 (Ordinary) Originating Line Identity (OLI) = 872 8858 Destination Address = 590 2360 Typically, DPNSS layer 3 messages are represented using formal IA5 notation; hence, the DPNSS layer 3 message used in the example can be represented (leaving out the message type and SIC field) as: *1#*50*8728858#5902360 Mukundan, et al. [Page 8] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 Note: Since binary encoding is used in the MIME body for the DPNSS payload, each byte is encoded as a byte, and not as a two-character hex or decimal representation. In the example above, decimal representation of integer values are used to represent the message length, message type and the SIC fields; rest of the fields are represented as 1B2A-IA5 because a literal (binary) encoding of those bytes would have been confusing and unreadable. 5. Security considerations Information contained in the DPNSS MIME body may include sensitive customer information, potentially requiring use of encryption. Security mechanisms are provided in RFC 3261 (SIP - Session Initiation Protocol) and should be used as appropriate for both the SIP message and the encapsulated DPNSS body. 6. IANA considerations This document registers the "application/DPNSS" MIME media type. Registrations for the 'version' symbols used within the DPNSS MIME type must specify a definitive specification reference, identifying a particular issue of the specification, to which the new symbol shall refer. Note that where a specification is fully peer-to-peer backwards compatible with a previous issue (i.e., the compatibility mechanism is supported by both), then there is no need for separate symbols to be registered. The symbol for the original specification should be used to identify backwards-compatible upgrades of that specification as well. 7. Acknowledgements We would like to thank Prakasha M.R. (prakashar@huawei.com) for conceiving the need for DPNSS MIME type definition in SIP; and the following folks for providing useful comments/insights on the SIPPING list: John Elwell, Mark Watson, Mark Ashwort, Jonathan Rosenberg, Adam Roach & Jon Peterson. 8. References 8.1 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Oftel's ND1301:2001/03, DPNSS [188], Digital Private Signalling System No 1 (DPNSS 1). Mukundan, et al. [Page 9] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol", RFC 3261, Internet Engineering Task Force, June 2002. [4] Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [5] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [6] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [7] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. 8.2 Informative References [10] ITU-T T.50 (09/1992): International Reference Alphabet (IRA), Information Technology - 7-Bit Coded Character Set for Information Exchange. [11] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital Private Network Signaling System 1. [12] A. Vemuri, J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", RFC 3372, September 2002. 9. Authors Addresses Ranjith Mukundan Phone: +91-80-51195893 Wipro Technologies Email: ranjith.mukundan@wipro.com 72, Electronics City, Hosur Main Road, Bangalore 560100 India Venkatesh Seshasayee Phone: +91-80-8520408 x2109 Wipro Technologies Email: venkatesh.seshasayee@wipro.com 72, Electronics City, Hosur Main Road, Bangalore 560100 India Mukundan, et al. [Page 10] Internet Draft draft-mukundan-sipping-dpnss-02.txt June 2003 Ken Morneault Phone: +1-703-484-3323 Cisco Systems Inc. EMail: kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA. 20171 USA Ravi Shiroor Phone: +91-80-5355501 x2065 Sasken Comm. Tech. Ltd. EMail: ravis@sasken.com 139/25, Amar Jyothi Layout, Bangalore 560040 India Narsimuloo Mangalpally Phone: +1-613-967-5034 Nortel Networks EMail: narsim@nortelnetworks.com 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada Sudarshan Naganathan Phone: +91-80-2286390 x7065 Hughes Software Systems EMail: nsudarshan@hss.hns.com 146, Infantry Road Bangalore 560001 India Mukundan, et al. [Page 11]