Network Working Group M. Munakata
Request for Comments: 4715 S. Schubert
Category: Informational T. Ohba
NTT
November 2006
Network Working Group M. Munakata
Request for Comments: 4715 S. Schubert
Category: Informational T. Ohba
NTT
November 2006
The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI
电话URI的综合业务数字网（ISDN）子地址编码类型
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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.
如果没有携带编码类型的综合业务数字网（ISDN）子地址的tel URI参数，在某些情况下，ISDN用户部分（ISUP）网络和会话发起协议（SIP）网络之间的互通是不可能的。为了解决这个问题，本文指定了一个新的可选tel-URI参数来携带ISDN子地址的编码类型。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Problem Statement ...............................................3
3.1. SIP-ISDN Interconnection ...................................3
3.2. ISDN-SIP-ISDN Interconnection ..............................4
4. Requirements ....................................................5
5. Parameter Definition ............................................6
6. Usage ...........................................................6
6.1. Gateway Behavior ...........................................7
6.2. SIP Entity Behavior ........................................8
7. Security Considerations .........................................9
8. IANA Considerations .............................................9
9. Acknowledgements ................................................9
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Problem Statement ...............................................3
3.1. SIP-ISDN Interconnection ...................................3
3.2. ISDN-SIP-ISDN Interconnection ..............................4
4. Requirements ....................................................5
5. Parameter Definition ............................................6
6. Usage ...........................................................6
6.1. Gateway Behavior ...........................................7
6.2. SIP Entity Behavior ........................................8
7. Security Considerations .........................................9
8. IANA Considerations .............................................9
9. Acknowledgements ................................................9
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
RFC 3966 [2] defines a tel URI parameter "isub" that is designed to carry Integrated Services Digital Network (ISDN) subaddresses.
RFC 3966[2]定义了一个tel URI参数“isub”，该参数设计用于承载综合业务数字网（ISDN）子地址。
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.
在ISDN用户部分（ISUP）消息中，网络服务接入点（NSAP）地址[6]或“用户指定”地址可以作为ISDN子地址携带。NSAP地址容纳各种类型的地址信息以及地址类型及其编码类型的标识符。
The "isub" parameter can carry any type of address, but RFC 3966 [2] does not define a solution to carry information on a subaddress type (whether the subaddress is NSAP or user specific) or an identifier for the encoding type used.
“isub”参数可以携带任何类型的地址，但是RFC 3966[2]没有定义一个解决方案来携带子地址类型的信息（无论子地址是NSAP还是用户特定的）或所使用编码类型的标识符。
The most commonly used encoding type for the ISDN subaddress is an International Alphabet 5 (IA5) [5]. RFC 3966 does state, "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. Therefore, "isub" parameter alone is not sufficient to describe ISDN subaddresses, and additional information is needed.
ISDN子地址最常用的编码类型是国际字母表5（IA5）[5]。考虑到这一事实，RFC 3966确实指出，“ISDN子地址通常包含IA5字符，但可能包含任何八位字节值”。然而，IA5只是NSAP地址中使用的各种编码类型中的一种。因此，“isub”参数本身不足以描述ISDN子地址，需要额外的信息。
Lack of information describing the encoding type of ISDN subaddress will make it 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 be lost, and reconstructing the intended ISDN subaddress value is nearly impossible.
缺少描述ISDN子地址编码类型的信息将使从SIP网络（SIP-ISDN互连）接收ISDN子地址的ISDN终端难以解释“isub”参数值，因为网关可能会使用错误的编码类型对其进行转换，并且由于所使用的编码类型不一致而导致子地址值错误。当ISUP消息转换为SIP消息并转换回ISUP消息（ISDN-SIP-ISDN互连）时，也将使恢复原始ISDN子地址值变得困难。由于SIP消息中没有携带编码类型的占位符，原始ISUP消息中存在的编码类型信息将丢失，重建预期的ISDN子地址值几乎是不可能的。
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.
为了解决上述问题，本规范定义了一个“isub encoding”参数，以携带描述“isub”参数的值是否为NSAP地址及其编码类型的信息。此外，本文件还规定了在“isub”参数中为使用的每种编码类型携带的适应值。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Without a tel URI parameter to carry an encoding type of ISDN subaddress, the problems described in Sections 3.1. and 3.2. might be observed.
如果没有携带ISDN子地址编码类型的tel URI参数，则会出现第3.1节中描述的问题。和3.2。可以观察到。
The diagrams 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 currently cannot be specified. Therefore, gateway sitting between the SIP network and ISDN network cannot translate the value of "isub" into an ISUP Initial Address Message (IAM) properly as the encoding type information of the ISDN subaddress is missing.
图1中的图表显示了SIP网络和具有ISDN子地址的ISDN网络之间互通时将观察到的问题。当SIP设备发送带有“isub”参数的请求以寻址专用交换机（PBX）后面的ISDN终端时，当前无法指定ISDN子地址的编码类型。因此，位于SIP网络和ISDN网络之间的网关无法将“isub”的值正确转换为ISUP初始地址消息（IAM），因为ISDN子地址的编码类型信息丢失。
ISDN Terminal
+-----+
|--->| Bob |
SIP Network <---|---> ISDN | |12345|
| +-----+
SIP Equipment |
+-----+ +-----+ +----+ +-----+ | +-----+
|Alice|------->|Proxy|----->| GW |----->| PBX |----->|Carol|
+-----+ +-----+ +----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
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 |
| | | | |---------->|
| | | | | |
Alice Proxy GW Switch PBX Bob
| | | | | |
| INVITE | | | | |
|------------>| INVITE | | | |
| |------------>| IAM | | |
| | |----->|SETUP| |
| | | |---->| SETUP |
| | | | |---------->|
| | | | | |
Figure 1: SIP-ISDN Interconnection
图1:SIP-ISDN互连
INVITE tel:+17005554141;isub=12345 SIP/2.0
INVITE tel:+17005554141;isub=12345 SIP/2.0
Note: SETUP is an ISDN message used between ISDN switch and ISDN end terminal.
注：设置是在ISDN交换机和ISDN终端之间使用的ISDN消息。
The diagrams 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", it cannot translate the value of the "isub" parameter back into the IAM message properly because the encoding type information of the ISDN subaddress is missing.
图2中的图表显示了在通过SIP网络的两个ISDN网络之间使用ISDN子地址互通消息时将观察到的问题。当ISDN终端发送包含ISDN子地址及其编码类型信息的消息时，网关1将该子地址转换为SIP消息中的“isub”参数。但是，由于SIP消息中没有编码类型的占位符，因此会删除其编码类型信息。当网关2接收到“isub”时，它无法将“isub”参数的值正确地转换回IAM消息，因为ISDN子地址的编码类型信息丢失。
ISDN Terminal
+-----+
|--->| Bob |
ISDN <---|---> SIP Network <---|---> ISDN | |12345|
| +-----+
ISDN Terminal |
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol|
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
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 |
| | | | | | |----------->|
| | | | | | | |
Alice Switch GW1 Proxy GW2 Switch PBX Bob
| | | | | | | |
| SETUP | | | | | | |
|------>| IAM | | | | | |
| |---->| INVITE | | | | |
| | |---------->| INVITE | | | |
| | | |---------->| IAM | | |
| | | | |---->|SETUP| |
| | | | | |---->| SETUP |
| | | | | | |----------->|
| | | | | | | |
Figure 2: ISDN-SIP-ISDN Interconnection
图2:ISDN-SIP-ISDN互连
INVITE tel:+17005554141;isub=12345 SIP/2.0
INVITE tel:+17005554141;isub=12345 SIP/2.0
The followings are requirements for a solution to carry an ISDN subaddress along with information of subaddress encoding type.
以下是携带ISDN子地址以及子地址编码类型信息的解决方案的要求。
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 1：当tel URI中存在“isub”参数但不存在“isub encoding”参数时，原始消息中ISDN子地址的编码必须假定为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).
Req 2：在tel URI中使用“isub”参数时，应使用可选的“isub encoding”参数指定编码，除非ISDN子地址的编码为IA5（AFI=0x50）。
The parameter defined in this document 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.
本文档中定义的参数表示为tel URI参数，该参数描述ISDN子地址的编码类型信息。它是tel URI的可选参数，用于容纳RFC 3966[2]中定义的“isub”参数中缺少的一些信息。ABNF[3]语法如下所示。
isub-encoding = isub-encoding-tag "=" isub-encoding-value
isub-encoding-tag = "isub-encoding"
isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token
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:
这些“isub编码”值的语义描述如下：
nsap-ia5: Indication that the "isub" parameter value needs to be encoded using IA5 (AFI=0x50) when translated to an ISUP message.
nsap-ia5：表示转换为ISUP消息时需要使用ia5（AFI=0x50）对“isub”参数值进行编码。
nsap-bcd: Indication that the "isub" parameter value needs to be encoded using Binary Coded Decimal (BCD) (AFI=0x48) when translated to an ISUP message.
nsap bcd：表示在转换为ISUP消息时，需要使用二进制编码十进制（bcd）（AFI=0x48）对“isub”参数值进行编码。
nsap: Indication that the "isub" parameter value needs to be encoded using the encoding type defined in ISO 8348 [6] other than IA5 (AFI=0x50) or BCD (AFI=0x48).
nsap：表示需要使用ISO 8348[6]中定义的编码类型（IA5（AFI=0x50）或BCD（AFI=0x48）除外）对“isub”参数值进行编码。
Note: Q.931 [7] defines a "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.
注：Q.931[7]定义了“用户指定”子地址类型，但本文档未指定“用户指定”子地址类型的任何行为或值。因此，“用户指定”子地址超出了本文档的范围。
An example of the syntax of the "isub-encoding" parameter (in a small fragment of a SIP [4] message) is given below:
下面给出了“isub encoding”参数的语法示例（在SIP[4]消息的小片段中）：
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
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
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 ISUP network and a SIP network. The URI parameter defined here is an optional parameter to the tel URI and is useful only when it's accompanying the "isub" parameter.
预计在ISUP网络和SIP网络之间互通时，本文档中定义的tel URI参数将与RFC 3966[2]中定义的“isub”参数一起使用。这里定义的URI参数是teluri的可选参数，仅当它与“isub”参数一起使用时才有用。
An ISDN subaddress information element carried in the ISUP message consists of a 3-octet header followed by either an NSAP address or a user-specified address. The NSAP address consists of an Initial Domain Part (IDP) (Authority and Format Identifier (AFI) and conditionally Initial Domain Identifier (IDI)) that identifies an encoding type of the subaddress, and a Domain Specific Part (DSP) that represents the subaddress value itself.
ISUP消息中携带的ISDN子地址信息元素由一个3-octet头，后跟一个NSAP地址或用户指定的地址组成。NSAP地址由标识子地址编码类型的初始域部分（IDP）（授权和格式标识符（AFI）和条件初始域标识符（IDI））和表示子地址值本身的域特定部分（DSP）组成。
To find out more about the ISDN subaddress information element and the NSAP address including definition of AFI, IDI, IDP, and DSP, please refer to Appendices A and B.
有关ISDN子地址信息元素和NSAP地址（包括AFI、IDI、IDP和DSP的定义）的更多信息，请参阅附录A和附录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" parameter value, and MUST handle the message accordingly.
如果isub的初始值为“IS50”，则假定isub的初始值为“ISUN编码”，且ISUN的初始值为“ISUN编码”，且ISUN的初始值为“ISUN编码”中的“ISUN编码”值，并且必须相应地处理消息。
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) and set the encoded value into the DSP part of the NSAP address when translating the message into an ISUP message.
如果缺少“isub编码”，并且消息由将SIP消息转换为isub消息的网关处理，则符合本规范的网关必须使用IA5（AFI=0x50）对“isub”参数中的值进行编码，并在将消息转换为isub消息时将编码值设置为NSAP地址的DSP部分。
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.
如果“isub encoding”的值设置为“nsap”，则编码类型（AFI）假定为十六进制的“isub”参数的前两个字符，表示为US-ASCII字符0-9和A-F。
If the ISDN subaddress is not an NSAP address, the entity translating the message SHOULD treat the message as if neither the "isub-encoding" nor the "isub" parameters existed, unless it has a prior knowledge of the encoding method used.
如果ISDN子地址不是NSAP地址，则翻译消息的实体应将消息视为“isub编码”或“isub”参数均不存在，除非其事先了解所使用的编码方法。
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.
当不符合此规范的实体使用“isub encoding”参数处理消息时，它将忽略该参数及其值。
A gateway compliant to this specification that receives a 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.
符合本规范的网关从包含ISDN子地址的ISDN网络接收消息/信号时，必须检查用于子地址的编码，并且必须遵循以下给出的过程。
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.
如果ISDN子地址是使用IA5编码的NSAP地址（AFI=0x50），实体可将“isub编码”参数设置为值“NSAP-IA5”，并使用RFC 3966[2]中规定的“isub”参数允许的字符将NSAP地址的DSP值设置为“isub”参数的值，或省略“isub编码”参数。
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.
如果ISDN子地址是使用BCD（AFI=0x48）编码的NSAP地址，则实体必须将“isub encoding”参数设置为值“NSAP BCD”，并使用数字将NSAP地址的解码DSP值设置为US-ASCII字符中的“isub”参数值。
Note: Each semi-octet should be translated into numbers (e.g. 01011001 would be translated as 5 and 9).
注：每个半八位组应翻译成数字（例如，01011001将翻译成5和9）。
If the ISDN subaddress is an NSAP address but is not encoded using either IA5 (AFI=0x50) or 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).
如果ISDN子地址是NSAP地址，但未使用IA5（AFI=0x50）或BCD（AFI=0x48）进行编码，则翻译消息的实体必须将“isub encoding”参数设置为值“NSAP”，并将整个NSAP地址设置为“isub”参数的值，十六进制表示为US-ASCII字符（0-9和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.
如果ISDN子地址不是NSAP地址，则翻译邮件的实体不应生成任何“isub编码”或“isub”参数，除非它与收件人就这种情况下的操作达成了私人协议。
An entity compliant to this specification setting an "isub" parameter MUST follow the procedures given below.
符合本规范并设置“isub”参数的实体必须遵循以下步骤。
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].
如果ISDN子地址是使用IA5编码的NSAP地址（AFI=0x50），则实体可将“isub编码”设置为“NSAP-IA5”。“isub”参数值不得超过19个字符。使用的字符必须遵循RFC 3966[2]中为“isub”参数定义的语法。
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).
如果ISDN子地址是使用BCD编码的NSAP地址（AFI=0x48），则实体必须将“isub编码”设置为“NSAP BCD”。“isub”参数值不得超过38个US-ASCII字符（数字）。
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" 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 and A-F). The first two characters of the "isub" parameter MUST be the encoding type (AFI) in this case.
如果ISDN子地址是使用IA5（AFI=0x50）或BCD（AFI=0x48）以外的编码类型编码的NSAP地址，则实体必须将“isub编码”设置为“NSAP”。“isub”参数值不得超过40个US-ASCII字符，并且必须以十六进制表示为US-ASCII字符（0-9和A-F）。在这种情况下，“isub”参数的前两个字符必须是编码类型（AFI）。
The parameter defined here adds no new security considerations to those discussed in RFC 3966 [2].
此处定义的参数没有为RFC 3966[2]中讨论的安全注意事项添加新的安全注意事项。
This document requires no action by IANA.
本文件无需IANA采取任何行动。
Further information on a registry for tel parameters is covered in [8].
有关tel参数注册表的更多信息，请参见[8]。
The authors thank John Elwell, James Rafferty, Steve Norreys, Michael Hammer, Ray Forbes, Martin Dolly, Cullen Jennings, and Henning Schulzrinne for providing extensive and constructive reviews and feedback.
作者感谢John Elwell、James Rafferty、Steve Norreys、Michael Hammer、Ray Forbes、Martin Dolly、Cullen Jennings和Henning Schulzrinne提供了广泛和建设性的评论和反馈。
The structure of an ISDN subaddress information element in ISUP messages is defined in Q.931 [7] as follows.
ISUP消息中ISDN子地址信息元素的结构在Q.931[7]中定义如下。
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
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
图3:ISDN子地址信息元素的结构
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.
虽然长度不同，但上图中显示的ISDN子地址信息元素的最大长度为23个八位字节。前3个八位字节是标题。其余的八位字节包含子地址信息，该信息是NSAP地址或“用户指定”地址。
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 octet identify 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".
第三个八位组的第5到第7位标识子地址的类型。当子地址为NSAP地址时，此字段设置为0。当子地址为“用户指定”时，它被设置为0 1 0。
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 (last 4 bits of the subaddress information) when the number of digits composing the subaddress is odd.
第三个八位字节的第四位是奇偶指示符。当子地址类型为“用户指定”且编码类型为BCD时，使用奇数/偶数指示符，以便在组成子地址的位数为奇数时，实体能够填充缺少的位（子地址信息的最后4位）。
Note: When interworking with SIP, it is recommended not to translate the padding bits to "isub" parameter.
注意：与SIP交互时，建议不要将填充位转换为“isub”参数。
In ISUP messages, the ISDN subaddress is generally represented as an NSAP address. The NSAP address is defined as follows in ISO 8348 [6].
在ISUP消息中，ISDN子地址通常表示为NSAP地址。NSAP地址在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地址由初始域部分（IDP）和域特定部分（DSP）组成。IDP由两个字段组成，一个权限和格式标识符（AFI）和一个初始域标识符（IDI）。NSAP地址的最大长度为20个八位字节。
<------------------ NSAP Address ------------------>
<------------------ NSAP Address ------------------>
+--------------------------------------------------+
| I D P | |
|-------------| D S P |
| AFI | IDI | |
+--------------------------------------------------+
0 1 k ... Octets ... max. 20
+--------------------------------------------------+
| I D P | |
|-------------| D S P |
| AFI | IDI | |
+--------------------------------------------------+
0 1 k ... Octets ... max. 20
Figure 4: Structure of NSAP Addresses
图4:NSAP地址的结构
The AFI value is 2 hexadecimal digits (00-FF), and it identifies the IDI format and the DSP syntax.
AFI值为2个十六进制数字（00-FF），用于标识IDI格式和DSP语法。
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 and depends on the value of AFI.
IDI值以十进制数字表示，它标识负责分配DSP值的网络寻址域或机构。IDI的长度不同，取决于AFI的值。
The typical encoding type of the ISDN subaddress, IA5, is identified as AFI=0x50. When the AFI value is 0x50, the length of IDI is zero; therefore, the length of IDP is 2 digits (1 octet). In this case, the DSP value is a subaddress encoded by IA5, 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 when the AFI value is set to either 0x50 or 0x48 is shown below. As shown, DSP starts from the 2nd octet of the NSAP address.
ISDN子地址的典型编码类型IA5标识为AFI=0x50。当AFI值为0x50时，IDI的长度为零；因此，IDP的长度为2位（1个八位字节）。在这种情况下，DSP值是由IA5编码的子地址，其最大长度为19个八位字节。当编码类型为BCD（AFI=0x48）时，IDI的长度也为零。当AFI值设置为0x50或0x48时的NSAP地址如下所示。如图所示，DSP从NSAP地址的第二个八位字节开始。
+--------------------------------------------------+
| IDP | |
|-----| D S P |
| AFI | |
+--------------------------------------------------+
0 1 ... Octets ... max. 20
+--------------------------------------------------+
| IDP | |
|-----| D S P |
| AFI | |
+--------------------------------------------------+
0 1 ... Octets ... max. 20
Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)
图5 NSAP地址的结构（AFI=0x50或AFI=0x48）
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[2] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[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.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] International Telecommunication 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.
[5] 国际电信联盟，“国际参考字母表（IRA）（原国际字母表5或IA5）-信息技术-信息交换用7位编码字符集”，建议T.501992。
[6] International Standard, "Information technology - Open Systems Interconnection - Network service definition", ISO/IEC 8348, 2002.
[6] 国际标准，“信息技术.开放系统互连.网络服务定义”，ISO/IEC 83482002。
[7] International Telecommunication Union, "ISDN User-Network Interface Layer 3 Specification for Basic Call Control", Recommendation Q.931, 1998.
[7] 国际电信联盟，“基本呼叫控制的ISDN用户网络接口第3层规范”，建议Q.9311998。
[8] Jennings, C. and V. Gurbani, "The Internet Assigned Numbers Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Work in Progress, May 2006.
[8] Jennings，C.和V.Gurbani，“互联网分配号码管理局（IANA）电话统一资源标识符（URI）参数注册表”，正在进行的工作，2006年5月。
Authors' Addresses
作者地址
Mayumi Munakata NTT Corporation
日本新界东道明明株式会社
Phone: +81 422 36 7565
EMail: munakata.mayumi@lab.ntt.co.jp
Phone: +81 422 36 7565
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
Shida舒伯特NTT公司
Phone: +1 604 762 5606
EMail: shida@ntt-at.com
Phone: +1 604 762 5606
EMail: shida@ntt-at.com
Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
Takumi Ohba NTT Corporation 9-11，Midori cho 3-Chome Musashino shi，东京180-8585
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。