RFC4715 日本語訳

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

The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI

Status of This Memo

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.

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 Notice

   Copyright (C) The IETF Trust (2006).

Copyright (C) The IETF Trust (2006).

Abstract

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.

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.

Munakata, et al.             Informational                      [Page 1]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 1]  RFC 4715 ISDN for tel URI November 2006

Table of Contents

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

1.  Introduction

1. Introduction

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

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

   In an ISDN User Part (ISUP) message, a Network Service Access Point
   (NSAP) address [6] or a "user specified" address can be carried as an
   ISDN subaddress.  The NSAP address accommodates various types of
   address information along with an identifier for the address type and
   its encoding type.

In an ISDN User Part (ISUP) message, a Network Service Access Point (NSAP) address [6] or a "user specified" address can be carried as an ISDN subaddress. The NSAP address accommodates various types of address information along with an identifier for the address type and its encoding type.

   The "isub" parameter can carry any type 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.

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.

   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.

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.

Munakata, et al.             Informational                      [Page 2]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 2]  RFC 4715 ISDN for tel URI November 2006

      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.

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.

   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.

To solve the issues presented, this specification defines an "isub- encoding" parameter to carry information describing whether the value of the "isub" parameter is an NSAP address as well as its encoding type. In addition, this document specifies the accommodating values to be carried in the "isub" parameter for each encoding type used.

2.  Terminology

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

3.  Problem Statement

3. Problem Statement

   Without a tel URI parameter to carry an encoding type of ISDN
   subaddress, the problems described in Sections 3.1. and 3.2. might be
   observed.

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.

3.1.  SIP-ISDN Interconnection

3.1. SIP-ISDN Interconnection

   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.

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.

Munakata, et al.             Informational                      [Page 3]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 3]  RFC 4715 ISDN for tel URI November 2006

                                                     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

Figure 1: SIP-ISDN Interconnection

         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.

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

3.2.  ISDN-SIP-ISDN Interconnection

3.2. ISDN-SIP-ISDN Interconnection

   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.

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.

Munakata, et al.             Informational                      [Page 4]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 4]  RFC 4715 ISDN for tel URI November 2006

                                                           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

Figure 2: ISDN-SIP-ISDN Interconnection

             INVITE tel:+17005554141;isub=12345 SIP/2.0

INVITE tel:+17005554141;isub=12345 SIP/2.0

4.  Requirements

4. Requirements

   The followings are requirements for a solution to carry an ISDN
   subaddress along with information of subaddress encoding type.

The followings are requirements for a solution to carry an ISDN subaddress along with information of subaddress encoding type.

   Req 1:   When the "isub" parameter is present but no "isub-encoding"
            parameter is present in a tel URI, the encoding of the ISDN
            subaddress in the original message MUST be assumed to be IA5
            (AFI=0x50).

Req 1: When the "isub" parameter is present but no "isub-encoding" parameter is present in a tel URI, the encoding of the ISDN subaddress in the original message MUST be assumed to be IA5 (AFI=0x50).

   Req 2:   When using the "isub" parameters in tel URIs, the encoding
            SHOULD be specified by using the optional "isub-encoding"
            parameter unless the encoding of the ISDN subaddress is IA5
            (AFI=0x50).

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

Munakata, et al.             Informational                      [Page 5]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 5]  RFC 4715 ISDN for tel URI November 2006

5.  Parameter Definition

5. Parameter Definition

   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.

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.

   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:

The semantics of these "isub-encoding" values are described below:

   nsap-ia5: Indication that the "isub" parameter value needs to be
             encoded using IA5 (AFI=0x50) when translated to an ISUP
             message.

nsap-ia5: Indication that the "isub" parameter value needs to be encoded using IA5 (AFI=0x50) when translated to an ISUP message.

   nsap-bcd: Indication that the "isub" parameter value needs to be
             encoded using Binary Coded Decimal (BCD) (AFI=0x48) when
             translated to an ISUP message.

nsap-bcd: Indication that the "isub" parameter value needs to be encoded using Binary Coded Decimal (BCD) (AFI=0x48) when translated to an ISUP message.

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

      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.

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.

   An example of the syntax of the "isub-encoding" parameter (in a small
   fragment of a SIP [4] message) is given below:

An example of the syntax of the "isub-encoding" parameter (in a small fragment of a SIP [4] message) is given below:

      INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0
        To: <tel:+17005554141;isub=12345;isub-encoding=nsap-ia5>
          From: "Bob"<sip:bob@biloxi.example.com>;tag=1928301774

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

   It is anticipated that a tel URI parameter defined in this document
   will be used along with an "isub" parameter defined in RFC 3966 [2]
   when interworking between an 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.

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.

Munakata, et al.             Informational                      [Page 6]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 6]  RFC 4715 ISDN for tel URI November 2006

   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.

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.

   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.

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.

   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.

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.

   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.

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.

   If the value of "isub-encoding" is set to "nsap", the encoding type
   (AFI) is assumed to be in the first two characters of the "isub"
   parameter in hexadecimal represented as US-ASCII characters 0-9 and
   A-F.

If the value of "isub-encoding" is set to "nsap", the encoding type (AFI) is assumed to be in the first two characters of the "isub" parameter in hexadecimal represented as US-ASCII characters 0-9 and A-F.

   If the ISDN subaddress is not an NSAP address, the entity translating
   the message SHOULD treat the message as if neither the "isub-
   encoding" nor the "isub" parameters existed, unless it has a prior
   knowledge of the encoding method used.

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.

   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.

When an entity that is not compliant to this specification handles the message with the "isub-encoding" parameter, it would simply ignore the parameter and its value.

6.1.  Gateway Behavior

6.1. Gateway Behavior

   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.

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.

Munakata, et al.             Informational                      [Page 7]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 7]  RFC 4715 ISDN for tel URI November 2006

      If the ISDN subaddress is an NSAP address encoded using IA5
      (AFI=0x50), the entity MAY set the "isub-encoding" parameter to
      the value "nsap-ia5" and set the DSP value of the NSAP address as
      the value for the "isub" parameter using characters permitted for
      the "isub" parameter as specified in RFC 3966 [2] or omit the
      "isub-encoding" parameter.

If the ISDN subaddress is an NSAP address encoded using IA5 (AFI=0x50), the entity MAY set the "isub-encoding" parameter to the value "nsap-ia5" and set the DSP value of the NSAP address as the value for the "isub" parameter using characters permitted for the "isub" parameter as specified in RFC 3966 [2] or omit the "isub-encoding" parameter.

      If the ISDN subaddress is an NSAP address encoded using BCD
      (AFI=0x48), the entity MUST set the "isub-encoding" parameter to
      the value "nsap-bcd" and set the decoded DSP value of the NSAP
      address as the value for the "isub" parameter in US-ASCII
      characters using numbers.

If the ISDN subaddress is an NSAP address encoded using BCD (AFI=0x48), the entity MUST set the "isub-encoding" parameter to the value "nsap-bcd" and set the decoded DSP value of the NSAP address as the value for the "isub" parameter in US-ASCII characters using numbers.

         Note: Each semi-octet should be translated into numbers (e.g.
               01011001 would be translated as 5 and 9).

Note: Each semi-octet should be translated into numbers (e.g. 01011001 would be translated as 5 and 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).

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

      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.

If the ISDN subaddress is not an NSAP address, the entity translating the message SHOULD NOT generate any "isub-encoding" or "isub" parameters, unless it has a private agreement with the recipient about what to do in this case.

6.2.  SIP Entity Behavior

6.2. SIP Entity Behavior

   An entity compliant to this specification setting an "isub" parameter
   MUST follow the procedures given below.

An entity compliant to this specification setting an "isub" parameter MUST follow the procedures given below.

      If the ISDN subaddress is an NSAP address encoded using IA5
      (AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5".
      The "isub" parameter value MUST NOT exceed 19 characters.  The
      characters used MUST follow the syntax defined for the "isub"
      parameter as specified in RFC 3966 [2].

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

      If the ISDN subaddress is an NSAP address encoded using BCD
      (AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd".
      The "isub" parameter value MUST NOT exceed 38 US-ASCII characters
      (numbers).

If the ISDN subaddress is an NSAP address encoded using 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).

Munakata, et al.             Informational                      [Page 8]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 8]  RFC 4715 ISDN for tel URI November 2006

      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.

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.

7.  Security Considerations

7. Security Considerations

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

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

8.  IANA Considerations

8. IANA Considerations

   This document requires no action by IANA.

This document requires no action by IANA.

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

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

9.  Acknowledgements

9. Acknowledgements

   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.

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.

Munakata, et al.             Informational                      [Page 9]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 9]  RFC 4715 ISDN for tel URI November 2006

Appendix A.  Structure of an ISDN Subaddress Information Element

Appendix A. Structure of an ISDN Subaddress Information Element

   The structure of an ISDN subaddress information element in ISUP
   messages is defined in Q.931 [7] as follows.

The structure of an ISDN subaddress information element in ISUP messages is defined in Q.931 [7] as follows.

                                Bits
            8     7     6     5     4     3     2     1     Octets
         +-----+-----------------------------------------+
         |  0  |  1     1     1     0     0     0     0  |   1
         +-----+-----------------------------------------+
         |  Length of called party subaddress contents   |   2
         +-----+-----------------------------------------+
         |  1  | Subaddress type | o/e |  0     0     0  |   3
         +-----+-----------------------------------------+
         |                                               |   4
         |            Subaddress information             |
         |                                               |
         |                                               |
         |                                               |
         +-----------------------------------------------+ max. 23

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

Figure 3: Structure of an ISDN Subaddress Information Element

   Although the length varies, the maximum length of an ISDN subaddress
   information element shown in the figure above is 23 octets.  The
   first 3 octets are the header.  The rest of the octets comprise the
   subaddress information that is either an NSAP address or a "user
   specified" address.

Although the length varies, the maximum length of an ISDN subaddress information element shown in the figure above is 23 octets. The first 3 octets are the header. The rest of the octets comprise the subaddress information that is either an NSAP address or a "user specified" address.

   The 1st octet is a called party subaddress information element
   identifier that identifies that this information element is a called
   party subaddress.  The 2nd octet represents the length of called
   party subaddress contents.

The 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".

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

   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.

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.

      Note: When interworking with SIP, it is recommended not to
            translate the padding bits to "isub" parameter.

Note: When interworking with SIP, it is recommended not to translate the padding bits to "isub" parameter.

Munakata, et al.             Informational                     [Page 10]

RFC 4715                    ISDN for tel URI               November 2006

Munakata, et al. Informational [Page 10]  RFC 4715 ISDN for tel URI November 2006

Appendix B.  Structure of NSAP Addresses

Appendix B. Structure of NSAP Addresses

   In ISUP messages, the ISDN subaddress is generally represented as an
   NSAP address.  The NSAP address is defined as follows in ISO 8348
   [6].

In ISUP messages, the ISDN subaddress is generally represented as an NSAP address. The NSAP address is defined as follows in ISO 8348 [6].

   The NSAP address consists of an Initial Domain Part (IDP) and a
   Domain Specific Part (DSP).  The IDP consists of two fields, an
   Authority and Format Identifier (AFI) and an Initial Domain
   Identifier (IDI).  The maximum length of an NSAP address is 20
   octets.

The NSAP address consists of an Initial Domain Part (IDP) and a Domain Specific Part (DSP). The IDP consists of two fields, an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The maximum length of an NSAP address is 20 octets.

           <------------------ NSAP Address ------------------>

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

Figure 4: Structure of NSAP Addresses

   The AFI value is 2 hexadecimal digits (00-FF), and it identifies the
   IDI format and the DSP syntax.

The AFI value is 2 hexadecimal digits (00-FF), and it identifies the IDI format and the DSP syntax.

   The IDI value when present is represented as decimal digits, and it
   identifies a network addressing domain or authority responsible for
   allocating values of the DSP.  The length of IDI varies and depends
   on the value of AFI.

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.

   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.

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.

           +--------------------------------------------------+
           | IDP |                                            |
           |-----|                 D S P                      |
           | AFI |                                            |
           +--------------------------------------------------+
           0     1            ...  Octets  ...          max. 20

+--------------------------------------------------+ | IDP| | |-----| D S P| | AFI| | +--------------------------------------------------+ 0 1 ... 八重奏…最大20

        Figure 5  Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)

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

Munakata, et al.             Informational                     [Page 11]

RFC 4715                    ISDN for tel URI               November 2006

宗像、他 tel URI2006年11月のための情報[11ページ]のRFC4715ISDN

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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
        December 2004.

[2]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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]国際電気通信連合、「国際Reference Alphabet(IRA)(以前国際のAlphabet No.5かIA5)--情報技術--情報交換のための7ビットのコード化文字集合」、Recommendation T.50、1992。

   [6]  International Standard, "Information technology - Open Systems
        Interconnection - Network service definition", ISO/IEC 8348,
        2002.

[6] 国際規格、「情報技術--オープン・システム・インターコネクション--ネットワーク・サービス定義」、ISO/IEC8348、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] Progress(2006年5月)のジョニングスとC.とV.Gurbani、「インターネットAssigned民数記Authority(IANA)tel Uniform Resource Identifier(URI)パラメタRegistry」Work。

Munakata, et al.             Informational                     [Page 12]

RFC 4715                    ISDN for tel URI               November 2006

宗像、他 tel URI2006年11月のための情報[12ページ]のRFC4715ISDN

Authors' Addresses

作者のアドレス

   Mayumi Munakata
   NTT Corporation

マユミ宗像NTT社

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

以下に電話をしてください。 +81 422 36 7565はメールされます: munakata.mayumi@lab.ntt.co.jp

   Shida Schubert
   NTT Corporation

志太シューベルトNTT社

   Phone: +1 604 762 5606
   EMail: shida@ntt-at.com

以下に電話をしてください。 +1 5606年の604 762メール: shida@ntt-at.com

   Takumi Ohba
   NTT Corporation
   9-11, Midori-cho 3-Chome
   Musashino-shi, Tokyo  180-8585
   Japan

TakumiオオバNTT社の9-11テロ、美土里町の3丁目の武蔵野市、日本東京180-8585

   Phone: +81 422 59 7748
   EMail: ohba.takumi@lab.ntt.co.jp
   URI:   http://www.ntt.co.jp

以下に電話をしてください。 +81 422 59 7748はメールされます: ohba.takumi@lab.ntt.co.jp ユリ: http://www.ntt.co.jp

Munakata, et al.             Informational                     [Page 13]

RFC 4715                    ISDN for tel URI               November 2006

宗像、他 tel URI2006年11月のための情報[13ページ]のRFC4715ISDN

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Munakata, et al.             Informational                     [Page 14]

宗像、他 情報[14ページ]