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
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）ネットワーク間のインターワーキングは、いくつかのケースでは不可能です。この問題を解決するために、このドキュメントは、ISDNサブアドレスのエンコードの種類を運ぶための新しいオプションのTEL URIパラメータを指定します。
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
RFC 3966 [2] defines a tel URI parameter "isub" that is designed to carry Integrated Services Digital Network (ISDN) subaddresses.
RFC 3966 [2]は総合デジタル通信網（ISDN）のサブアドレスを運ぶように設計されたTEL URIパラメータ「Isubは」を定義します。
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のサブアドレスの符号化タイプを記述する情報の欠如は、「Isubは」パラメータ値を解釈するSIPネットワーク（SIP-ISDN相互接続）からISDNのサブアドレスを受信したISDN端末のが困難になります符号化タイプおよび使用される符号化タイプに矛盾に起因する誤ったサブアドレス値で終わります。それはまた、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は」パラメータの値は、NSAPアドレス、並びにその符号化タイプであるかどうかを記述する情報を運ぶ「Isubは符号化」パラメータを定義します。また、この文書は、使用される各符号化タイプは、「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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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の図は、ISDNのサブアドレスを有するSIPネットワークとISDNネットワーク間のインターワーキング場合に観察される問題を示します。 SIP機器が構内交換機（PBX）の背後のISDN端末に対処する「Isubは」パラメータを使用して要求を送信すると、現在ISDNのサブアドレスの符号化タイプを指定することはできません。したがって、SIPネットワークとISDNネットワークとの間座っゲートウェイ正しくISDNのサブアドレスの符号化タイプ情報としてISUP初期アドレスメッセージ（IAM）に「Isubは」の値を変換することができないが欠落しています。
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
図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ネットワークを介して横断する2つのISDNネットワーク間のISDNのサブアドレスを持つメッセージをインターワーキングするときに観察される問題を示します。 ISDN端末は、その符号化タイプ情報と共にISDNのサブアドレスを含むメッセージを送信するときに、ゲートウェイ1は、SIPメッセージ内の「Isubは」パラメータにサブアドレスを変換します。 SIPメッセージ内のエンコードタイプのためのプレースホルダがないのでしかし、その符号化タイプ情報は廃棄されます。ゲートウェイ2が「Isubは」を受信すると、ISDNのサブアドレスの符号化タイプ情報が欠落しているので、それが適切にバックIAMメッセージに「Isubは」パラメータの値を変換することができません。
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
図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：「Isubは」パラメータが存在するが、何ら「Isubは、エンコーディング」パラメータはTEL URIに存在しない、元のメッセージ内の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は」パラメータを使用する場合、ISDNのサブアドレスの符号化はIA5（AFI = 0x50を）でなければ、符号化は、オプション「Isubは、符号化」パラメータを使用して指定されるべきです。
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.
この文書で定義されたパラメータは、ISDNのサブアドレスの符号化タイプ情報を記述するTEL URIパラメータとして表されます。 RFC 3966で定義された「Isubは」パラメータに欠けている情報の一部を収容するために、TEL URIにオプションのパラメータである[2]。次のように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はエンコード= Isubは、符号化タグ= "Isubはコード" Isubはエンコード値= "NSAP-IA5" / "NSAP-BCD" / "NSAP" "=" Isubはエンコード値Isubは符号化タグ/トークン
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：「Isubは」パラメータ値がISUPメッセージに変換するときIA5（AFI = 0x50を）を使用して符号化される必要があることを示します。
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：「Isubは」パラメータ値がISUPメッセージに変換するとき値化進数（BCD）（AFI = 0x48）を使用して符号化される必要があることを示します。
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：IA5（AFI = 0x50を）またはBCD（AFI = 0x48）より[6]他の "Isubは" パラメータ値がISO 8348に定義された符号化タイプを用いて符号化される必要があるという指示を。
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:
（SIP [4]メッセージの小断片で）「Isubは符号化」パラメータの構文の例を以下に示します：
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はエンコード= NSAP-IA5 SIP / 2.0 <TEL：+17005554141; Isubは= 12345; Isubはエンコード= NSAP-IA5>から： "ボブ" <SIP：ボブ@ biloxi.example.com>;タグ= 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.
なお、本文書で定義されたTEL URIパラメータは、RFC 3966で定義された「Isubは」パラメータと共に使用されることが予想される[2] ISUPネットワークとSIPネットワーク間のインターワーキングします。ここで定義されたURIパラメータは、TEL URIにオプションのパラメータであり、それは「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のサブアドレス情報要素は、NSAPアドレスまたはユーザ指定のアドレスのいずれかに続いて3オクテットのヘッダから成ります。 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サブアドレス情報要素とAFI、IDI、IDP、およびDSPの定義を含むNSAPアドレスの詳細については、付録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は符号化」は存在せず、メッセージがSIPネットワーク上のエンティティによって解釈された場合に、この仕様に準拠したエンティティは、ISUPメッセージの元のISDNのサブアドレスがIA5の符号化タイプとNSAPアドレスであったと仮定しなければなりませんDSP値が変換及び「Isubは」パラメータ値に設定され、それに応じてメッセージを処理する必要がありますされたの（AFI = 0x50を）。
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は符号化」は存在せず、メッセージをISUPメッセージにSIPメッセージを変換するゲートウェイによって処理される場合、この仕様に準拠したゲートウェイはIA5（AFI = 0x50を）を使用して「Isubは」パラメータの値を符号化しなければならずISUPメッセージにメッセージを変換するときに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は符号化」の値が「NSAP」に設定されている場合、符号化タイプ（AFI）は、US-ASCII文字0-9とAFのように表される16進数で「Isubは」パラメータの最初の2つの文字であると仮定されます。
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は、エンコーディング」パラメータを使用してメッセージを処理するとき、それは単にパラメータとその値を無視します。
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（AFI = 0x50を）を使用して符号化されたNSAPアドレスである場合、エンティティは、値「NSAP-IA5」から「Isubは、符号化」パラメータを設定するための値としてNSAPアドレスのDSPの値を設定してもよいですRFC 3966 [2]又は省略「Isubは、エンコーディング」パラメータで指定される「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は、エンコーディング」パラメータ値を「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は、エンコーディング」パラメータ値を「NSAP」を設定しなければならない場合US-ASCII文字（0-9およびAF）のように表される16進数で「Isubは」パラメータの値として全体のNSAPアドレス。
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（AFI = 0x50を）を使用して符号化されたNSAPアドレスである場合、エンティティは「NSAP-IA5」から「Isubは符号化」を設定してもよいです。 「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（AFI = 0x48）を使用して符号化されたNSAPアドレスである場合、エンティティは「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は」パラメータの最初の2つの文字は、この場合の符号化タイプ（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.
著者は、広範かつ建設的なレビューとフィードバックを提供するために、ジョンエルウェル、ジェームズ・ラファティ、スティーブNorreys、マイケル・ハマー、レイ・フォーブス、マーティン・ドリー、カレン・ジェニングス、およびヘニングSchulzrinneと感謝します。
Appendix A. Structure of an ISDN Subaddress Information Element
ISDNサブアドレス情報要素の付録A.構造
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
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".
第3オクテットの7ビット5は、サブアドレスのタイプを識別する。サブアドレスがNSAPアドレスである場合、このフィールドは0 0 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.
第三オクテットの4ビット目は、奇数/偶数指標です。サブアドレスのタイプはBCDの符号化タイプを持つ「ユーザ指定」である場合、奇数/偶数インジケータは、桁数がサブアドレスを構成するときにパッドに欠落ビット（サブアドレス情報の最後の4ビット）エンティティを有効にするために、使用されています奇数です。
Note: When interworking with SIP, it is recommended not to translate the padding bits to "isub" parameter.
注意：SIPと相互作用するとき、「Isubと」パラメータにパディングビットを変換しないことをお勧めします。
Appendix B. Structure of NSAP Addresses
NSAPアドレスの付録B.構造
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アドレスとして表されます。 ISO 8348で次のようにNSAPアドレスが定義されている[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 ------------------>
+--------------------------------------------------+
| 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桁の16進数（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アドレスの2番目のオクテットから始まります。
+--------------------------------------------------+
| IDP | |
|-----| D S P |
| AFI | |
+--------------------------------------------------+
0 1 ... Octets ... max. 20
Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)
NSAPアドレス（AFI = 0x50を、またはAFI = 0x48）の図5の構造
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[2] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月に。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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.50、1992。
[6] International Standard, "Information technology - Open Systems Interconnection - Network service definition", ISO/IEC 8348, 2002.
[6]国際規格、 "情報技術 - 開放型システム間相互接続 - ネットワークサービス定義"、ISO / IEC 8348、2002。
[7] International Telecommunication Union, "ISDN User-Network Interface Layer 3 Specification for Basic Call Control", Recommendation Q.931, 1998.
[7]国際電気通信連合を、「基本的なコール制御のためのISDNユーザ・網インタフェースレイヤ3仕様」、勧告Q.931、1998。
[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]ジェニングス、C.およびV. Gurbani、 "IANA（Internet Assigned Numbers Authority）のTELの統一資源識別子（URI）パラメータレジストリ"、進歩、2006年5月に作業を。
Authors' Addresses
著者のアドレス
Mayumi Munakata NTT Corporation
まゆみ むなかた んっｔ こｒぽらちおん
Phone: +81 422 36 7565 EMail: munakata.mayumi@lab.ntt.co.jp
電話：+81 422 36 7565 Eメール：munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
市大SバートNTT法人
Phone: +1 604 762 5606 EMail: shida@ntt-at.com
電話：+1 604 762 5606 Eメール：shida@ntt-at.com
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
電話：+81 422 59 7748 Eメール：URI ohba.takumi@lab.ntt.co.jp：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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。