GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4715

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

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.

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

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

 RFC 3966 [2] defines a tel URI parameter "isub" that is designed to
 carry Integrated Services Digital Network (ISDN) subaddresses.
 In an ISDN User Part (ISUP) message, a Network Service Access Point
 (NSAP) address [6] or a "user specified" address can be carried as an
 ISDN subaddress.  The NSAP address accommodates various types of
 address information along with an identifier for the address type and
 its encoding type.
 The "isub" parameter can carry any type 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.

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

2. Terminology

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

3. Problem Statement

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

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.

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|
                                                         +-----+
     Alice         Proxy          GW   Switch  PBX         Bob
       |             |             |      |     |           |
       |   INVITE    |             |      |     |           |
       |------------>|   INVITE    |      |     |           |
       |             |------------>| IAM  |     |           |
       |             |             |----->|SETUP|           |
       |             |             |      |---->|   SETUP   |
       |             |             |      |     |---------->|
       |             |             |      |     |           |
              Figure 1: SIP-ISDN Interconnection
       INVITE tel:+17005554141;isub=12345 SIP/2.0
       Note: SETUP is an ISDN message used between ISDN switch and
             ISDN end terminal.

3.2. ISDN-SIP-ISDN Interconnection

 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

                                                         ISDN Terminal
                                                               +-----+
                                                          |--->| Bob |
       ISDN  <---|--->  SIP Network  <---|---> ISDN       |    |12345|
                                                          |    +-----+
 ISDN Terminal                                            |
 +-----+      +-----+     +-----+     +-----+     +-----+ |    +-----+
 |Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol|
 +-----+      +-----+     +-----+     +-----+     +-----+ |    +-----+
                                                          |
                                                          |    +-----+
                                                          |--->|David|
                                                               +-----+
  Alice  Switch  GW1        Proxy        GW2  Switch  PBX         Bob
    |       |     |           |           |     |     |            |
    | SETUP |     |           |           |     |     |            |
    |------>| IAM |           |           |     |     |            |
    |       |---->|  INVITE   |           |     |     |            |
    |       |     |---------->|  INVITE   |     |     |            |
    |       |     |           |---------->| IAM |     |            |
    |       |     |           |           |---->|SETUP|            |
    |       |     |           |           |     |---->|   SETUP    |
    |       |     |           |           |     |     |----------->|
    |       |     |           |           |     |     |            |
              Figure 2: ISDN-SIP-ISDN Interconnection
           INVITE tel:+17005554141;isub=12345 SIP/2.0

4. Requirements

 The followings are requirements for a solution to carry an ISDN
 subaddress along with information of subaddress encoding type.
 Req 1:   When the "isub" parameter is present but no "isub-encoding"
          parameter is present in a tel URI, the encoding of the ISDN
          subaddress in the original message MUST be assumed to be IA5
          (AFI=0x50).
 Req 2:   When using the "isub" parameters in tel URIs, the encoding
          SHOULD be specified by using the optional "isub-encoding"
          parameter unless the encoding of the ISDN subaddress is IA5
          (AFI=0x50).

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

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.
 isub-encoding           = isub-encoding-tag "=" isub-encoding-value
 isub-encoding-tag       = "isub-encoding"
 isub-encoding-value     = "nsap-ia5" / "nsap-bcd" / "nsap" / token
 The semantics of these "isub-encoding" values are described below:
 nsap-ia5: Indication that the "isub" parameter value needs to be
           encoded using IA5 (AFI=0x50) when translated to an ISUP
           message.
 nsap-bcd: Indication that the "isub" parameter value needs to be
           encoded using Binary Coded Decimal (BCD) (AFI=0x48) when
           translated 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).
    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:
    INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0
      To: <tel:+17005554141;isub=12345;isub-encoding=nsap-ia5>
        From: "Bob"<sip:bob@biloxi.example.com>;tag=1928301774

6. Usage

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

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

 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

    If the ISDN subaddress is an NSAP address encoded using IA5
    (AFI=0x50), the entity MAY set the "isub-encoding" parameter to
    the value "nsap-ia5" and set the DSP value of the NSAP address as
    the value for the "isub" parameter using characters permitted for
    the "isub" parameter as specified in RFC 3966 [2] or omit the
    "isub-encoding" parameter.
    If the ISDN subaddress is an NSAP address encoded using BCD
    (AFI=0x48), the entity MUST set the "isub-encoding" parameter to
    the value "nsap-bcd" and set the decoded DSP value of the NSAP
    address as the value for the "isub" parameter in US-ASCII
    characters using numbers.
       Note: Each semi-octet should be translated 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 not an NSAP address, the entity
    translating the message SHOULD NOT generate any "isub-encoding" or
    "isub" parameters, unless it has a private agreement with the
    recipient about what to do in this case.

6.2. SIP Entity Behavior

 An entity compliant to this specification setting an "isub" parameter
 MUST follow the procedures given below.
    If the ISDN subaddress is an NSAP address encoded using IA5
    (AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5".
    The "isub" parameter value MUST NOT exceed 19 characters.  The
    characters used MUST follow the syntax defined for the "isub"
    parameter as specified in RFC 3966 [2].
    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

    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

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

8. IANA Considerations

 This document requires no action by IANA.
 Further information on a registry for tel parameters is covered in
 [8].

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.

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

Appendix A. Structure of an ISDN Subaddress Information Element

 The structure of an ISDN subaddress information element in ISUP
 messages is defined in Q.931 [7] as follows.
                              Bits
          8     7     6     5     4     3     2     1     Octets
       +-----+-----------------------------------------+
       |  0  |  1     1     1     0     0     0     0  |   1
       +-----+-----------------------------------------+
       |  Length of called party subaddress contents   |   2
       +-----+-----------------------------------------+
       |  1  | Subaddress type | o/e |  0     0     0  |   3
       +-----+-----------------------------------------+
       |                                               |   4
       |            Subaddress information             |
       |                                               |
       |                                               |
       |                                               |
       +-----------------------------------------------+ max. 23
      Figure 3:  Structure of an ISDN Subaddress Information Element
 Although the length varies, the maximum length of an ISDN subaddress
 information element shown in the figure above is 23 octets.  The
 first 3 octets are the header.  The rest of the octets comprise the
 subaddress information that is either an NSAP address or a "user
 specified" address.
 The 1st octet is a called party subaddress information element
 identifier that identifies that this information element is a called
 party subaddress.  The 2nd octet represents the length of called
 party subaddress contents.
 The 5th to 7th bits of the 3rd 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.
    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

Appendix B. Structure of NSAP Addresses

 In ISUP messages, the ISDN subaddress is generally represented as an
 NSAP address.  The NSAP address is defined as follows in ISO 8348
 [6].
 The NSAP address consists of an Initial Domain Part (IDP) and a
 Domain Specific Part (DSP).  The IDP consists of two fields, an
 Authority and Format Identifier (AFI) and an Initial Domain
 Identifier (IDI).  The maximum length of an NSAP address is 20
 octets.
         <------------------ NSAP Address ------------------>
         +--------------------------------------------------+
         |    I D P    |                                    |
         |-------------|             D S P                  |
         | AFI |  IDI  |                                    |
         +--------------------------------------------------+
         0     1       k     ...  Octets  ...         max. 20
               Figure 4:  Structure of NSAP Addresses
 The AFI value 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 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
      Figure 5  Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)

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

10. References

10.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
      December 2004.
 [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 4234, October 2005.

10.2. Informative References

 [4]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [5]  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.
 [6]  International Standard, "Information technology - Open Systems
      Interconnection - Network service definition", ISO/IEC 8348,
      2002.
 [7]  International Telecommunication Union, "ISDN User-Network
      Interface Layer 3 Specification for Basic Call Control",
      Recommendation Q.931, 1998.
 [8]  Jennings, C. and V. Gurbani, "The Internet Assigned Numbers
      Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
      Registry", Work in Progress, May 2006.

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

Authors' Addresses

 Mayumi Munakata
 NTT Corporation
 Phone: +81 422 36 7565
 EMail: munakata.mayumi@lab.ntt.co.jp
 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
 Phone: +81 422 59 7748
 EMail: ohba.takumi@lab.ntt.co.jp
 URI:   http://www.ntt.co.jp

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

Full Copyright Statement

 Copyright (C) The IETF Trust (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
 PURPOSE.

Intellectual 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.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Munakata, et al. Informational [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4715.txt · Last modified: 2006/11/03 19:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki