Network Working Group M. Munakata
Internet-Draft S. Schubert
Expires: August 30, 2006 T. Ohba
NTT
February 26, 2006
ISDN subaddress encoding type for tel URI
draft-munakata-iptel-isub-type-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Without a tel URI parameter to carry encoding type of Integrated
Services Digital Network(ISDN) subaddress, interworking between ISDN
User Part(ISUP) network and Session Initiation Protocol(SIP) network
is impossible in some cases. To solve the problem, this document
specifies a new tel URI parameter to carry encoding type of ISDN
subaddress.
Munakata, et al. Expires August 30, 2006 [Page 1]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. SIP-ISDN Interconnection . . . . . . . . . . . . . . . . . 5
3.2. ISDN-SIP-ISDN Interconnection . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Parameter Definition . . . . . . . . . . . . . . . . . . . . . 9
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Gateway behavior . . . . . . . . . . . . . . . . . . . . . 10
6.2. Length and format of isub parameter . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Structure of NSAP Addresses . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Munakata, et al. Expires August 30, 2006 [Page 2]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
1. Introduction
RFC3966[2] defines the tel URI parameter "isub" that is designed to
carry Integrated Services Digital Network(ISDN) subaddresses.
In a ISDN User Part(ISUP) message, NSAP address[6] or user specified
address can be carried as ISDN subaddress. Network Service Access
Point(NSAP) address accommodates various types of address information
along with an identifier that shows the address type and its encoding
type.
"isub" parameter can also carry any type of address but RFC3966
doesn't define a solution to carry information of subaddress type
(whether the subaddress is NSAP address or not) and an identifier of
an encoding type.
Most commonly used encoding type for ISDN subaddress is International
Alphabet 5(IA5)[5]. RFC 3966 says "ISDN subaddresses typically
contain IA5 characters but may contain any octet value".
Nevertheless, IA5 is just one of the encoding types among various
types of encoding used in NSAP address. Therefore parameter to carry
isub value alone is not enough to describe ISDN subaddresses, and
additional information is needed.
Lack of information describing the encoding type of "isub"
parameter will most likely make it difficult for ISDN terminal
receiving ISDN subaddress from SIP network(SIP-ISDN
Interconnection) to interpret the "isub" parameter value as
gateway may translate it using the encoding type not anticipated.
It will also make it difficult to recover the original ISDN
subaddress value when ISUP message is translated to SIP message
and back to ISUP message(ISDN-SIP-ISDN Interconnection), as there
is no place holder to carry the encoding type currently in SIP
message, the encoding type that was present in the original ISUP
message will be lost.
To solve the issue, this specification defines "isub-type" parameter
to carry information whether the value of "isub" parameter is NSAP
address or not and its encoding type. In addition, this document
specifies the meaning of the value in "isub" parameter.
Munakata, et al. Expires August 30, 2006 [Page 3]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[1].
Munakata, et al. Expires August 30, 2006 [Page 4]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
3. Problem Statement
Without a tel URI parameter to carry encoding type of ISDN
subaddress, such problems shown in 3.1 and 3.2 would happen.
3.1. SIP-ISDN Interconnection
The following diagram shows an issue that will be observed when
interworking between SIP network and ISDN network addressing an ISDN
subaddress. When a SIP equipment sends a request with "isub"
parameter to address an ISDN terminal behind Private Branch
Exchange(PBX), the encoding type of ISDN subaddress currently can not
be specified. Therefore gateway between SIP network and ISDN network
can not translate the value of "isub" into ISUP Initial Address
Message(IAM) properly because the encoding type information of the
ISDN subaddress is missing.
Munakata, et al. Expires August 30, 2006 [Page 5]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
ISDN Terminal
+-----+
|--->| Bob |
SIP Network <---|---> ISDN | |12345|
| +-----+
SIP Equipment |
+-----+ +-----+ +----+ +-----+ | +-----+
|Alice|----->|Proxy|----->| GW |----->| PBX |----->|Carol|
+-----+ +-----+ +----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
Alice Proxy GW Switch PBX Bob
| | | | | |
| INVITE | | | | |
|---------->| INVITE | | | |
| |------------>| IAM | | |
| | |----->|SETUP| |
| | | |---->| SETUP |
| | | | |---------->|
| | | | | |
Figure 1: SIP-ISDN Interconnection
INVITE tel:+17005554141;isub=12345 SIP/2.0
Note: SETUP is an ISDN message used between ISDN switch and
ISDN end terminal.
Munakata, et al. Expires August 30, 2006 [Page 6]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
3.2. ISDN-SIP-ISDN Interconnection
Following diagram shows the issue that will be observed when
interworking message with ISDN subaddress between ISDN network that
traverses through SIP network. When an ISDN terminal sends a message
that contains ISDN subaddress with its encoding type information,
Gateway 1 translates the subaddress into "isub" parameter in SIP
message. However, its encoding type is dropped because there is no
room for encoding type in SIP message. When Gateway 2 receives
"isub", it can not translate "isub" value into IAM message properly
because the encoding type information of the ISDN subaddress is
missing.
ISDN Terminal
+-----+
|--->| Bob |
ISDN <---|---> SIP Network <---|---> ISDN | |12345|
| +-----+
ISDN Terminal |
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol|
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
Alice Switch GW1 Proxy GW2 Switch PBX Bob
| | | | | | | |
| SETUP | | | | | | |
|------>| IAM | | | | | |
| |---->| INVITE | | | | |
| | |---------->| INVITE | | | |
| | | |---------->| IAM | | |
| | | | |---->|SETUP| |
| | | | | |---->| SETUP |
| | | | | | |----------->|
| | | | | | | |
Figure 2: ISDN-SIP-ISDN Interconnection
INVITE tel:+17005554141;isub=12345 SIP/2.0
Munakata, et al. Expires August 30, 2006 [Page 7]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
4. Requirements
The followings are requirements for a solution to carry ISDN
subaddress along with information of subaddress encoding type.
Req 1: When "isub" parameter is present in a SIP message, the type
of ISDN subaddress (whether it is an NSAP address or not) and
its encoding type MUST be identifiable.
Req 2: It MUST be possible for entity setting the "isub" parameter
in a SIP message, to specify the type of ISDN
subaddress(whether it is an NSAP address or not) and the
encoding type used.
Munakata, et al. Expires August 30, 2006 [Page 8]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
5. Parameter Definition
The parameter defined in this draft is represented as a tel URI,
which describes the encoding type information of the ISDN
subaddress(ISUB Type). It accommodates some of the information that
is lacking in the "isub" parameter defined in RFC3966[2]. It is an
optional parameter to tel URI. The ABNF[3] syntax is as follows.
isub-type = isub-type-tag "=" isub-type-value
isub-type-tag = "isub-type"
isub-type-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token
The semantics of these "isub-type" values are described below:
nsap-ia5: Indication that the "isub" parameter value needs to be
encoded using IA5(AFI=0x50) when translated to ISUP
message.
nsap-bcd: Indication that the "isub" parameter value needs to be
encoded using Binary Coded Decimal(BCD)(AFI=0x48) when
translated to ISUP message.
nsap: Indication that the "isub" parameter value needs to be
encoded using encoding type defined in ISO8348 other than
IA5 (AFI=0x50) or BCD(AFI=0x48).
An example of the syntax of the "isub-type" parameter (in a small
fragment of a SIP[4] message) is given below:
INVITE tel:+17005554141;isub=12345;isub-type=nsap-ia5 SIP/2.0
To: <tel:+17005554141;isub=12345;isub-type=nsap-ia5>
From: "Bob" <sip:bob@biloxi.example.com>;tag=1928301774
Munakata, et al. Expires August 30, 2006 [Page 9]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
6. Usage
It is anticipated that this URI parameter will be used along with the
"isub" parameter defined in RFC3966[2] when interworking between ISUP
networks and SIP network. The URI parameter defined here is an
optional parameter to the tel URI. To find out more about the NSAP
address, please reference the Appendix in Section 8.
If the "isub-type" is absent, and the message is interpreted by an
entity on the SIP network, the entity SHOULD assume that the original
ISDN subaddress from ISUP message, which was translated to the "isub"
parameter, was decoded using IA5(AFI=0x50) and handle the message
accordingly.
If the "isub-type" is absent, and the message is handled by a gateway
translating the SIP message to ISUP message, the gateway SHOULD
encode the value in the "isub" parameter using IA5(AFI=0x50) when
translating the message into ISUP message.
If the "isub-type" value is "nsap", the encoding type is assumed to
be in the first two characters of "isub" parameter in hexadecimal
format(% HEXDIG HEXDIG).
6.1. Gateway behavior
Gateway receiving message/signal from ISDN network containing ISDN
subaddress SHOULD check the encoding used for the subaddress, and set
the equivalent "isub" parameter and "isub-type" parameter to the SIP
message in a form of tel URI parameter. Following text is a
recommended guideline when translating ISUP message containing ISDN
subaddress.
If the ISDN subaddress is encoded using IA5(AFI=0x50), the entity
translating the message SHOULD set "nsap-ia5" to the "isub-type"
and value after 5th octet of the subaddress information element in
original ISUP message as "isub" value in ASCII characters.
If the ISDN subaddress is encoded using BCD(AFI=0x48), the entity
translating the message SHOULD set "nsap-bcd" to the "isub-type"
and decode the value after 5th octet of the subaddress information
element in original ISUP message using BCD and set it as the
"isub" value in ASCII characters(numbers).
If the ISDN subaddress is an NSAP address but neither encoded by
IA5(AFI=0x50) nor BCD(AFI=0x48), the entity translating the
message SHOULD set "nsap" to the "isub-type" and value after 4th
octet of the subaddress information element in original ISUP
message as "isub" value in hexadecimal format(% HEXDIG HEXDIG).
Munakata, et al. Expires August 30, 2006 [Page 10]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
If the ISDN subaddress is not an NSAP address, the entity
translating the message MAY set any value as a token.
6.2. Length and format of isub parameter
An entity setting an "isub" parameter is RECOMMENDED to set the
"isub-type" value with the encoding type used. Following text is a
recommended guideline when setting the "isub" parameter.
If the "isub-type" is "nsap-ia5", the "isub" parameter value
SHOULD NOT exceed 19 ASCII characters.
If the "isub-type" is "nsap-bcd", the "isub" parameter value
SHOULD NOT exceed 38 ASCII characters(numbers).
If the "isub-type" is "nsap", the "isub" parameter value SHOULD
NOT exceed 40 ASCII characters and it SHOULD be in hexadecimal
format(% HEXDIG HEXDIG).
Entity MAY define other type of "isub-type" as a token.
Munakata, et al. Expires August 30, 2006 [Page 11]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
7. Security Considerations
The parameter defined here adds no new security considerations to
those discussed in [2]
Munakata, et al. Expires August 30, 2006 [Page 12]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
8. Appendix
8.1. Structure of NSAP Addresses
In ISUP messages, ISDN subaddress is represented as NSAP address.
NSAP address is defined as follows in ISO8348.
NSAP address consists of Initial Domain Part(IDP) and Domain Specific
Part(DSP). Then IDP consists of two fields, Authority and Format
Identifier(AFI) and Initial Domain Identifier(IDI). The maximum
length of NSAP address is 20 octets.
<----------------- NSAP Address ----------------->
+------------------------------------------------+
| I D P | |
|-----------| D S P |
| AFI | IDI | |
+------------------------------------------------+
Figure 3
AFI value is two hexadecimal digits(00-FF), and it identifies IDI
format and DSP syntax.
IDI value is decimal digits, and it identifies a network addressing
domain or authority responsible for allocating values of the DSP.
Typical encoding type of ISDN subaddress, IA5, is identified with
AFI=0x50. When AFI value is 0x50, IDI is null, and the length of IDP
is 2 digits(1 octet). In this case, DSP value is a subaddress
encoded by IA5 and its maximum length is 19 octets.
Munakata, et al. Expires August 30, 2006 [Page 13]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
9. References
9.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
9.2. Informative Reference
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] International Telecommunications Union, "International Reference
Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) -
Information technology - 7-bit coded character set for
information interchange", Recommendation T.50, 1992.
[6] INTERNATIONAL STANDARD, "Information technology - Open Systems
Interconnection - Network service definition", ISO/IEC 8348.
Munakata, et al. Expires August 30, 2006 [Page 14]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
Authors' Addresses
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7565
Email: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
Phone: +1 604 762 5606
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
Email: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp
Munakata, et al. Expires August 30, 2006 [Page 15]
Internet-Draft ISDN subaddress encoding type for tel URI February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Munakata, et al. Expires August 30, 2006 [Page 16]
