Internet DRAFT - draft-mukundan-sipping-dpnss
draft-mukundan-sipping-dpnss
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
<draft-mukundan-sipping-dpnss-02.txt>
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: <sip:dummy@wipro.com>
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]
