[要約] RFC 4715は、tel URIのためのISDNサブアドレスエンコーディングタイプについての規格です。このRFCの目的は、ISDNサブアドレスをtel URIにエンコードする方法を定義することです。

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

統合サービスデジタルネットワーク(ISDN)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).

Copyright(c)The IETF 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.

エンコードタイプの統合サービスデジタルネットワーク(ISDN)SubAddressを運ぶTel URIパラメーターがない場合、ISDNユーザーパーツ(ISUP)ネットワークとセッション開始プロトコル(SIP)ネットワーク間のインターワーキングは、場合によっては不可能です。この問題を解決するために、このドキュメントは、新しいオプションのTelURIパラメーターを指定して、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
1. はじめに

RFC 3966 [2] defines a tel URI parameter "isub" that is designed to carry Integrated Services Digital Network (ISDN) subaddresses.

RFC 3966 [2]は、Integrated Services Digital Network(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アドレスで使用されるさまざまなエンコードタイプの中でエンコードタイプの1つにすぎません。したがって、「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エンコード」パラメーターを定義して、「iSub」パラメーターの値がNSAPアドレスとそのエンコードタイプであるかどうかを説明する情報を伝達します。さらに、このドキュメントは、使用される各エンコーディングタイプの「iSub」パラメーターに掲載される収容値を指定します。

2. Terminology
2. 用語

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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。

3. Problem Statement
3. 問題文

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.

EncodingタイプのISDNサブアドレスを携帯するTel URIパラメーターがない場合、セクション3.1で説明されている問題。および3.2。観察される可能性があります。

3.1. SIP-ISDN Interconnection
3.1. SIP-ISDN相互接続

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」パラメーターを使用してリクエストを送信して、ISDNサブアドレスのエンコードタイプの現在指定できません。したがって、SIPネットワークとISDNネットワークの間にあるゲートウェイは、ISDNサブアドレスのエンコーディングタイプ情報が欠落しているため、「iSub」の値をISUP初期アドレスメッセージ(IAM)に適切に変換することはできません。

                                                     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
        

Note: SETUP is an ISDN message used between ISDN switch and ISDN end terminal.

注:セットアップは、ISDNスイッチとISDNエンド端子の間で使用されるISDNメッセージです。

3.2. ISDN-SIP-ISDN Interconnection
3.2. ISDN-SIP-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サブアドレスを含むメッセージをエンコードタイプ情報とともに送信すると、Gateway 1はSIPメッセージのサブアドレスを「iSub」パラメーターに変換します。ただし、SIPメッセージにエンコードタイプのプレースホルダーがないため、エンコードタイプ情報は削除されます。Gateway 2が「iSub」を受信すると、ISDNサブアドレスのエンコードタイプ情報が欠落しているため、「iSub」パラメーターの値をIAMメッセージに適切に変換することはできません。

                                                           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
        
4. Requirements
4. 要件

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-Encoding」パラメーターが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:TelURISで「iSub」パラメーターを使用する場合、ISDNサブアドレスのエンコードがIA5(AFI = 0x50)でない限り、オプションの「ISUBエンコード」パラメーターを使用してエンコードを指定する必要があります。

5. Parameter Definition
5. パラメーター定義

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 [2]で定義されている「iSub」パラメーターに欠けている情報の一部に対応するために、Tel URIのオプションのパラメーターです。ABNF [3]構文は次のとおりです。

   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-Encoding」値のセマンティクスについては、以下に説明します。

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:IA5(AFI = 0x50)またはBCD(AFI = 0x48)以外のISO 8348 [6]で定義されたエンコードタイプを使用して、「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
        
6. Usage
6. 使用法

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パラメーターは、ISUPネットワークとSIPネットワーク間でインターワーキングするときにRFC 3966 [2]で定義された「iSub」パラメーターとともに使用されると予想されます。ここで定義されている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サブアドレス情報要素は、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.

AFI、IDI、IDP、およびDSPの定義を含むISDNサブアドレス情報要素と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-encoding」が存在しない場合、メッセージがSIPネットワーク上のエンティティによって解釈される場合、この仕様に準拠したエンティティは、ISUPメッセージの元のISDNサブアドレスが、エンコードタイプのIA5を持つNSAPアドレスであると仮定する必要があります。(AFI = 0x50)。そのうちDSP値が翻訳され、「iSub」パラメーター値に設定されており、それに応じてメッセージを処理する必要があります。

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-Encoding」が存在しない場合、メッセージがSIPメッセージをISUPメッセージに変換するゲートウェイによって処理される場合、この仕様に準拠したゲートウェイは、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-Encoding」の値が「NSAP」に設定されている場合、エンコードタイプ(AFI)は、US-ASCII文字0-9およびA-Fとして表される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-Encoding」または「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」パラメーターでメッセージを処理する場合、パラメーターとその値を単に無視します。

6.1. Gateway Behavior
6.1. ゲートウェイの動作

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アドレスである場合、エンティティは「iSub-Encoding」パラメーターを値「NSAP-IA5」に設定し、NSAPアドレスのDSP値を設定し、値として設定することができます。RFC 3966 [2]で指定されている「ISUB」パラメーターに許可されている文字を使用して、「iSUB」パラメーターを使用するか、「iSub-Encoding」パラメーターを省略します。

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アドレス全体が、us-ascii文字(0-9およびa-f)として表される16進数の「isub」パラメーターの値として。

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-Encoding」または「iSub」パラメーターを生成してはなりません。

6.2. SIP Entity Behavior
6.2. SIPエンティティの動作

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アドレスである場合、エンティティは「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(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)として表される16進数である必要があります。この場合、「iSub」パラメーターの最初の2文字はエンコードタイプ(AFI)でなければなりません。

7. Security Considerations
7. セキュリティに関する考慮事項

The parameter defined here adds no new security considerations to those discussed in RFC 3966 [2].

ここで定義されているパラメーターは、RFC 3966 [2]で説明したものに新しいセキュリティ上の考慮事項を追加しません。

8. IANA Considerations
8. IANAの考慮事項

This document requires no action by IANA.

このドキュメントでは、IANAによるアクションは必要ありません。

Further information on a registry for tel parameters is covered in [8].

電話パラメーターのレジストリの詳細については、[8]で説明しています。

9. Acknowledgements
9. 謝辞

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.

著者は、ジョン・エルウェル、ジェームズ・ラファティ、スティーブ・ノリーズ、マイケル・ハンマー、レイ・フォーブス、マーティン・ドリー、カレン・ジェニングス、ヘニング・シュルツリンヌに、広範で建設的なレビューとフィードバックを提供してくれたことに感謝します。

Appendix A. Structure of an ISDN Subaddress Information Element
付録A. ISDNサブアドレス情報要素の構造

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.

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.

1番目のOctetは、この情報要素がパーティーサブアドレスと呼ばれることを識別する、パーティーサブアドレス情報要素識別子と呼ばれるものです。2番目のオクテットは、党と呼ばれるサブアドレスの内容の長さを表します。

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番目のオクテットの5〜7ビットは、サブアドレスのタイプを識別します。サブアドレスが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.

3番目のオクテットの4番目のビットは、奇妙な/偶数のインジケーターです。SubAddressのタイプが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
付録B. NSAPアドレスの構造

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は、2つのフィールド、権限とフォーマット識別子(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)

図5 NSAPアドレスの構造(AFI = 0x50またはAFI = 0x48)

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[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。、「電話番号のためのTel 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 4234、2005年10月。

10.2. Informative References
10.2. 参考引用

[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:SESSION INTIATION Protocol"、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] International Telecommunication Union、「International Reference Alphabet(IRA)(以前の国際アルファベットNo. 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] International Telecommunication Union、「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] Jennings、C。and V. Gurbani、「インターネットが番号を割り当てた(IANA)Tel Uniform Resource Identifier(URI)パラメーターレジストリ」、2006年5月の作業。

Authors' Addresses

著者のアドレス

Mayumi Munakata NTT Corporation

Mayumi Munakata ntt Corporation

   Phone: +81 422 36 7565
   EMail: munakata.mayumi@lab.ntt.co.jp
        

Shida Schubert NTT Corporation

Shida Schubert NTT Corporation

   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、Tokyo 180-8585 Japan

   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).

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.

この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。