IPTELNetwork Working Group M. MunakataInternet-DraftRequest for Comments: 4715 S. SchubertExpires: January 02, 2007Category: Informational T. Ohba NTTJul 01,November 2006ISDN subaddress encoding typeThe Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URIdraft-munakata-iptel-isub-type-04.txtStatus ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2006.this memo is unlimited. Copyright Notice Copyright (C) TheInternet SocietyIETF Trust (2006). Abstract Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 3.....................................................3 3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . 4...............................................3 3.1. SIP-ISDN Interconnection. . . . . . . . . . . . . . . . . 4...................................3 3.2. ISDN-SIP-ISDN Interconnection. . . . . . . . . . . . . . 6..............................4 4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7....................................................5 5. Parameter Definition. . . . . . . . . . . . . . . . . . . . . 7............................................6 6. Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8...........................................................6 6.1. Gateway Behavior. . . . . . . . . . . . . . . . . . . . . 9...........................................7 6.2. SIP Entity Behavior. . . . . . . . . . . . . . . . . . . 9........................................8 7. Security Considerations. . . . . . . . . . . . . . . . . . . 10.........................................9 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 10.............................................9 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Structure of ISDN Subaddress Information Element . . 10 Appendix B. Structure of NSAP Addresses . . . . . . . . . . . . . 11 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13................................................9 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13....................................................12 10.1. NormativeReference . . . . . . . . . . . . . . . . . . . 13References .....................................12 10.2. InformativeReference . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16References ...................................12 1. Introduction RFC 3966 [2] defines a tel URI parameter "isub" that is designed to carry Integrated Services Digital Network (ISDN) subaddresses. In an ISDN User Part (ISUP) message, a Network Service Access Point (NSAP) address [6] or a "user specified" address can be carried as an ISDN subaddress. The NSAP address accommodates various types of address information along with an identifier for the address type and its encoding type. The "isub" parameter can carry any type ofaddressaddress, but RFC 3966 [2]doesn'tdoes not define a solution to carry informationofon a subaddress type (whether the subaddress is NSAP orUser Specific) noruser specific) or an identifier for the encoding type used.MostThe most commonly used encoding type for the ISDN subaddress is an International Alphabet 5 (IA5) [5]. RFC 3966 doesstatestate, "ISDN subaddresses typically contain IA5 characters but may contain any octet value" considering this fact. Nevertheless, IA5 is just one of the encoding types among various encoding types used in the NSAP address.ThereforeTherefore, "isub" parameter alone is notenoughsufficient to describe ISDN subaddresses, and additional information is needed. Lack of information describing the encoding type of ISDN subaddress will make itdifficult,difficult for an ISDN terminal receiving the ISDN subaddress from the SIP network (SIP-ISDN Interconnection) to interpret the "isub" parameter value, as a gateway may translate it using a wrong encoding type and end up with a wrong subaddress value due to inconsistency in the encoding type used. It will also make it difficult to recover the original ISDN subaddress value when an ISUP message is translated to a SIP message and translated back to the ISUP message (ISDN-SIP-ISDN Interconnection). As there is no placeholder to carry the encoding type in the SIP message, the encoding type information that was present in the original ISUP message will belostlost, and reconstructing the intended ISDN subaddress value is nearly impossible. To solve the issues presented, this specification defines an "isub- encoding" parameter to carry information describing whether the value of the "isub" parameter is an NSAP address as well as its encoding type. In addition, this document specifies the accommodating values to be carried in the "isub" parameter for each encoding type used. 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]. 3. Problem Statement Without a tel URI parameter to carry an encoding type of ISDN subaddress, the problems described in Sections 3.1. and 3.2.wouldmight be observed. 3.1. SIP-ISDN Interconnection Thefollowingdiagrams in Figure 1 show an issue that will be observed when interworking between SIP network and ISDN network with an ISDN subaddress. When SIP equipment sends a request with an "isub" parameter to address an ISDN terminal behind Private Branch Exchange (PBX), the encoding type of the ISDN subaddress currentlycan notcannot be specified.ThereforeTherefore, gateway sitting between the SIP network and ISDN networkcan notcannot translate the value of "isub" into an ISUP Initial Address Message (IAM) properly as the encoding type information of the ISDN subaddress is missing. 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. 3.2. ISDN-SIP-ISDN Interconnection Thefollowingdiagrams in Figure 2 show an issue that will be observed when interworking messages with an ISDN subaddress between two ISDN networks that traverses through SIP networks. When an ISDN terminal sends a message that contains an ISDN subaddress along with its encoding type information, Gateway 1 translates the subaddress into an "isub" parameter in a SIP message. However, its encoding type information is dropped because there is no placeholder for the encoding type in the SIP message. When Gateway 2 receives the "isub", itcan notcannot translate the value of the "isub" parameter back into the 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 4. Requirements The followings are requirements for a solution to carry an ISDN subaddress along with information of subaddress encoding type. Req 1: When the "isub" parameter is present but no "isub-encoding" parameter is present in a tel URI, the encoding of the ISDN subaddress in the original message MUST be assumed to be IA5 (AFI=0x50). Req 2: When using the "isub" parameters in tel URIs, the encoding SHOULD be specified by using the optional "isub-encoding" parameter unless the encoding of the ISDN subaddress is IA5 (AFI=0x50). 5. Parameter Definition The parameter defined in thisdraftdocument is represented as a tel URI parameter, which describes the encoding type information of the ISDN subaddress. It is an optional parameter to tel URI to accommodate some of the information lacking in the "isub" parameter defined in RFC 3966 [2]. The ABNF [3] syntax is as follows. isub-encoding = isub-encoding-tag "=" isub-encoding-value isub-encoding-tag = "isub-encoding" isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token The semantics of these "isub-encoding" values are described below: nsap-ia5: Indication that the "isub" parameter value needs to be encoded using IA5 (AFI=0x50) when translated to an ISUP message. nsap-bcd: Indication that the "isub" parameter value needs to be encoded using Binary Coded Decimal (BCD) (AFI=0x48) when translated tothean ISUP message. nsap: Indication that the "isub" parameter value needs to be encoded using the encoding type defined inISO8348[6]ISO 8348 [6] other than IA5 (AFI=0x50) or BCD (AFI=0x48). Note: Q.931 [7] definesana "user specified" subaddress type, but this document does not specify any behavior or value for "user specified" subaddress type. Therefore, the "user specified" subaddress is beyond the scope of this document. An example of the syntax of the "isub-encoding" parameter (in a small fragment of a SIP [4] message) is given below: INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0 To: <tel:+17005554141;isub=12345;isub-encoding=nsap-ia5> From: "Bob"<sip:bob@biloxi.example.com>;tag=1928301774 6. Usage It is anticipated that a tel URI parameter defined in this document will be used along with an "isub" parameter defined in RFC 3966 [2] when interworking between an ISUPnetworksnetwork and a SIP network. The URI parameter defined here is an optional parameter to the telURI,URI and is useful only when it's accompanying the "isub" parameter. An ISDN subaddress information element carried in the ISUP message consists of a 3-octet header followed by either an NSAP address or auser specifieduser-specified address. The NSAP address consists of anIDP (AFIInitial Domain Part (IDP) (Authority and Format Identifier (AFI) and conditionallyIDI)Initial Domain Identifier (IDI)) that identifies an encoding type of the subaddress, and aDSPDomain Specific Part (DSP) that represents the subaddress value itself. To find out more about the ISDN subaddress information element and the NSAP address including definition of AFI, IDI, IDP, and DSP, pleasereference therefer to Appendices A and B. If the "isub-encoding" is absent, and a message is interpreted by an entity on the SIP network, the entity compliant to this specification MUST assume that the original ISDN subaddress in an ISUP message was an NSAP address with an encoding type of IA5 (AFI=0x50), of which the DSP value was translated and set to the "isub" parametervaluevalue, and MUST handle the message accordingly. If the "isub-encoding" is absent, and the message is handled by a gateway translating the SIP message to ISUP message, the gateway compliant to this specification MUST encode the value in the "isub" parameter using IA5(AFI=0x50),(AFI=0x50) and set the encoded value into the DSP part of the NSAP address when translating the message into an ISUP message. If the value of "isub-encoding" is set to "nsap", the encoding type (AFI) is assumed to be in the first two characters of the "isub" parameter in hexadecimal represented as US-ASCII characters 0-9 and A-F. If the ISDN subaddress is not an NSAP address, the entity translating the message SHOULD treat the message as if neither"isub-encoding"the "isub- encoding" nor the "isub" parameters existed, unless it has a prior knowledge of the encoding method used. When an entity that is not compliant to this specification handles the message with the "isub-encoding" parameter, it would simply ignore the parameter and its value. 6.1. Gateway BehaviorGatewayA gateway compliant to this specification that receivesmessage/signala message/ signal from an ISDN network containing an ISDN subaddress MUST check the encoding used for the subaddress and MUST follow the procedures given below. If the ISDN subaddress is an NSAP address encoded using IA5 (AFI=0x50), the entity MAY set the "isub-encoding" parameter to the value "nsap-ia5" and set the DSP value of the NSAP address as the value for the "isub" parameter using characters permitted for the "isub" parameter as specified in RFC 3966 [2] or omit the "isub-encoding" parameter. If the ISDN subaddress is an NSAP address encoded using BCD (AFI=0x48), the entity MUST set the "isub-encoding" parameter to the value "nsap-bcd" and set the decoded DSP value of the NSAP address as the value for the "isub" parameter in US-ASCII characters using numbers. Note: Each semi-octet should be translated intonumbers. e.g.)numbers (e.g. 01011001 would be translated as 5 and9.9). If the ISDN subaddress is an NSAP address butneitheris not encoded using either IA5 (AFI=0x50)noror BCD (AFI=0x48), the entity translating the message MUST set the "isub-encoding" parameter to the value "nsap" and the entire NSAP address as the value for the "isub" parameter in hexadecimal represented as US-ASCII characters (0-9 and A-F). If the ISDN subaddress is not an NSAP address, the entity translating the message SHOULD NOT generate any "isub-encoding" or "isub" parameters, unless it has a private agreement with the recipient about what to do in this case. 6.2. SIP Entity Behavior An entity compliant to this specification setting an "isub" parameter MUST follow the procedures given below. If the ISDN subaddress is an NSAP address encoded using IA5 (AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5". The "isub" parameter value MUST NOT exceed 19 characters. The characters used MUST follow the syntax defined for the "isub" parameter as specified in RFC 3966[2][2]. If the ISDN subaddress is an NSAP address encoded using BCD (AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd". The "isub" parameter value MUST NOT exceed 38 US-ASCII characters (numbers). If the ISDN subaddress is an NSAP address encoded using an encoding type other than IA5 (AFI=0x50) or BCD (AFI=0x48), the entity MUST set the"isub- encoding""isub-encoding" to "nsap". The "isub" parameter value MUST NOT exceed 40 US-ASCII characters and it MUST be in hexadecimal represented as US-ASCII characters (0-9 andA-F).A- F). The first two characters of the "isub" parameter MUST be the encoding type (AFI) in this case. 7. Security Considerations The parameter defined here adds no new security considerations to those discussed in RFC 3966 [2]. 8. IANA Considerations This document requires no action by IANA. Further information on a registry for tel parameters is covered in[8][8]. 9. Acknowledgements The authors thank John Elwell, James Rafferty, Steve Norreys, Michael Hammer, Ray Forbes, Martin Dolly, CullenJenningsJennings, and Henning Schulzrinne for providing extensive and constructive reviews andfeedbacks.feedback. Appendix A. Structure of an ISDN Subaddress Information Element The structure of an ISDN subaddress information element in ISUP messages is defined in Q.931 [7] as follows. Bits 8 7 6 5 4 3 2 1 Octets +-----+-----------------------------------------+ | 0 | 1 1 1 0 0 0 0 | 1 +-----+-----------------------------------------+ | Length of called party subaddress contents | 2 +-----+-----------------------------------------+ | 1 | Subaddress type | o/e | 0 0 0 | 3 +-----+-----------------------------------------+ | | 4 | Subaddress information | | | | | | | +-----------------------------------------------+ max. 23 Figure 3: Structure of an ISDN Subaddress Information Element Although the length varies, the maximum length of an ISDN subaddress information element shown in the figure above is 23 octets. The first 3 octets are the header. The rest of the octets comprise the subaddress information that is either an NSAP address or a "user specified" address. The 1st octet is a called party subaddress information element identifier that identifies that this information element is a called party subaddress. The 2nd octet represents the length of called party subaddress contents. The 5th to 7th bits of the 3rd octetidentifiesidentify the type of subaddress. This field is set to 0 0 0 when the subaddress is an NSAP address. It is set to 0 1 0 when the subaddress is "user specified". The 4th bit of the 3rd octet is an odd/even indicator. The odd/even indicator is used when the type of subaddress is "user specified" with the encoding type of BCD, to enable an entity to pad the missing bits (last4bits4 bits of the subaddress information) when thenumbersnumber of digits composing the subaddress is odd. Note: When interworking withSIPSIP, it is recommended not to translate the padding bits to "isub" parameter. Appendix B. Structure of NSAP Addresses In ISUP messages, the ISDN subaddress is generally represented as an NSAP address. The NSAP address is defined as follows in ISO 8348 [6]. The NSAP address consists of an Initial Domain Part (IDP) and a Domain Specific Part (DSP). The IDP consists of two fields, an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The maximum length of an NSAP address is 20 octets. <------------------ NSAP Address ------------------> +--------------------------------------------------+ | I D P | | |-------------| D S P | | AFI | IDI | | +--------------------------------------------------+ 0 1 k ... Octets ... max. 20 Figure 4: Structure of NSAP Addresses The AFI value istwo2 hexadecimal digits (00-FF), and it identifies the IDI format and the DSP syntax. The IDI value when present is represented as decimal digits, and it identifies a network addressing domain or authority responsible for allocating values of the DSP. The length of IDI varies anditdepends on the value of AFI.TypicalThe typical encoding type of the ISDN subaddress, IA5, is identified as AFI=0x50. When the AFI value is 0x50, the length of IDI iszero, thereforezero; therefore, the length of IDP is 2 digits (1 octet). In this case, the DSP value is a subaddress encoded byIA5IA5, and its maximum length is 19 octets. The length of IDI is also zero when the encoding type is BCD (AFI=0x48). The NSAP address for whenAFI'sthe AFI value is set to either 0x50 or 0x48 is shown below. As shown, DSP starts from the 2nd octet of the NSAP address. +--------------------------------------------------+ | IDP | | |-----| D S P | | AFI | | +--------------------------------------------------+ 0 1 ... Octets ... max. 20 Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)Appendix C. Change Log Changes from 00 to 01. - Many editorial fixes and grammatical correction. - Added a text on "User-Specific" address type. - Added a text on "odd/even" indicator. - Changed the requirements to clearly address the requirements this draft is trying to meet. Changes from 01 to 02. - GEN-ART provided some constructive feedbacks and we reflected some of the recommended changes. 1. Some of the SHOULD were changed to MUST to hold a better compatibility with the pre-existing implementation. 2. Fixed numerical grammatical errors. 3. Added an appendix to explain the ISDN subaddress information element. 4. Expanded the appendix on NSAP address structure to clarify some of the ambiguity that was addressed. 5. Clarified some of the text on entity behaviors.(Section 6) Changes from 02 to 03. - Reflected comments provided by IESG. 1. parameter defined in this draft was renamed from "isub-type" to "isub-encoding". 2. Added a reference to a draft handling the IANA registration.10. References 10.1. NormativeReferenceReferences [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. 10.2. InformativeReferenceReferences [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] InternationalTelecommunicationsTelecommunication 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,International Standard, "Information technology - Open Systems Interconnection - Network service definition", ISO/IEC8348.8348, 2002. [7]INTERNATIONAL TelecommunicationsInternational Telecommunication Union, "ISDN User-Network Interface Layer 3 Specification for Basic Call Control", Recommendation Q.931, 1998. [8] Jennings, C. and V. Gurbani, "The Internet AssignedNumberNumbers Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry",draft-ietf-iptel-tel-reg-02.txt,Work in Progress, May 2006. Authors' Addresses Mayumi Munakata NTT Corporation Phone: +81 422 36 7565Email: munakata.mayumi at lab.ntt.co.jpEMail: munakata.mayumi@lab.ntt.co.jp Shida Schubert NTT Corporation Phone: +1 604 762 5606Email: shida at ntt-at.comEMail: shida@ntt-at.com Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7748Email: ohba.takumi at lab.ntt.co.jpEMail: ohba.takumi@lab.ntt.co.jp URI: http://www.ntt.co.jp Full Copyright Statement Copyright (C) The IETF Trust (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. 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, THE IETF TRUST, 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. Intellectual PropertyStatementThe 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. AcknowledgmentAcknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.