[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4715

Network Working Group                                        M. Munakata
Internet-Draft                                               S. Schubert
Expires: October 31, 2006                                        T. Ohba
                                                                     NTT
                                                            Apr 29, 2006


               ISDN subaddress encoding type for tel URI
                 draft-munakata-iptel-isub-type-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 31, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Without a tel URI parameter to carry encoding type of Integrated
   Services Digital Network(ISDN) subaddress, interworking between ISDN
   User Part(ISUP) network and Session Initiation Protocol(SIP) network
   is impossible in some cases.  To solve the problem, this document
   specifies a new optional tel URI parameter to carry encoding type of
   ISDN subaddress.




Munakata, et al.        Expires October 31, 2006                [Page 1]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  SIP-ISDN Interconnection . . . . . . . . . . . . . . . . .  5
     3.2.  ISDN-SIP-ISDN Interconnection  . . . . . . . . . . . . . .  7
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Parameter Definition . . . . . . . . . . . . . . . . . . . . .  9
   6.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Gateway behavior . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  SIP Entity behavior  . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Structure of NSAP Addresses . . . . . . . . . . . . . 14
   Appendix B.  Changelog . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18






























Munakata, et al.        Expires October 31, 2006                [Page 2]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


1.  Introduction

   RFC3966[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, Network Service Access
   Point(NSAP) address[6] or user specified address can be carried as
   ISDN subaddress.  An 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 RFC3966
   doesn't define a solution to carry information of subaddress type
   (whether the subaddress is NSAP or User Specific) nor an identifier
   for an encoding type.

   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 enough to describe
   ISDN subaddresses, and additional information is needed.

      Lack of information describing the encoding type of ISDN
      subaddress will likely make it difficult for ISDN terminal
      receiving ISDN subaddress from SIP network(SIP-ISDN
      Interconnection) when trying to interpret the "isub" parameter
      value, as gateway may translate it using the encoding type not
      anticipated and lead to a wrong value due to the inconsistency in
      encoding method used.  It will also make it difficult to recover
      the original ISDN subaddress value when ISUP message is translated
      to SIP message and translated back to ISUP message(ISDN-SIP-ISDN
      Interconnection).  As there is no placeholder to carry the
      encoding type in 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 described, this specification defines an "isub-
   type" parameter to carry an information describing whether the value
   of "isub" parameter is an NSAP address as well as its encoding type.
   In addition, this document specifies the accommodating values to be
   carried in "isub" parameter for each encoding type used.







Munakata, et al.        Expires October 31, 2006                [Page 3]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


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














































Munakata, et al.        Expires October 31, 2006                [Page 4]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


3.  Problem Statement

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

3.1.  SIP-ISDN Interconnection

   The following diagrams show an issue that will be observed, when
   interworking between SIP network and ISDN network with an ISDN
   subaddress is needed.  When a SIP equipment sends a request with
   "isub" parameter to address an ISDN terminal behind Private Branch
   Exchange(PBX), the encoding type of the ISDN subaddress currently can
   not be specified.  Therefore gateway sitting between SIP network and
   ISDN network can not translate the value of "isub" into ISUP Initial
   Address Message(IAM) properly as the encoding type information of the
   ISDN subaddress is missing.



































Munakata, et al.        Expires October 31, 2006                [Page 5]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 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.

















Munakata, et al.        Expires October 31, 2006                [Page 6]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


3.2.  ISDN-SIP-ISDN Interconnection

   The following diagrams show an issue that will be observed, when
   interworking message with an ISDN subaddress between two ISDN
   networks that traverses through SIP networks.  When an ISDN terminal
   sends a message that contains ISDN subaddress along with its encoding
   type information, Gateway 1 translates the subaddress into "isub"
   parameter in SIP message.  However, its encoding type information is
   dropped because there is no placeholder for encoding type in SIP
   message.  When Gateway 2 receives "isub", it can not translate "isub"
   value back into IAM message properly because the encoding type
   information of the ISDN subaddress is missing.



                                                           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





Munakata, et al.        Expires October 31, 2006                [Page 7]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


4.  Requirements

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

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

   Req 2:  When using "isub" parameters in tel URIs, the encoding SHOULD
           be specified by using the optional "isub-type" parameter.







































Munakata, et al.        Expires October 31, 2006                [Page 8]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


5.  Parameter Definition

   The parameter defined in this draft 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
   RFC3966[2].  The ABNF[3] syntax is as follows.



   isub-type           = isub-type-tag "=" isub-type-value
   isub-type-tag       = "isub-type"
   isub-type-value     = "nsap-ia5" / "nsap-bcd" / "nsap" / token


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

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

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

   nsap:     Indication that the "isub" parameter value needs to be
             encoded using encoding type defined in ISO8348[6]
             other than IA5(AFI=0x50) or BCD(AFI=0x48).


   Note: Q.931[7] defines an "User specified" subaddress type, token may
   be used to address "User specified" subaddress type and therefore
   specifying the detail is beyond the scope of this document.

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

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











Munakata, et al.        Expires October 31, 2006                [Page 9]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


6.  Usage

   It is anticipated that the tel URI parameter defined in this document
   will be used along with the "isub" parameter defined in RFC3966[2]
   when interworking between ISUP networks and SIP network.  The URI
   parameter defined here is an optional parameter to the tel URI and
   provides no useful means on its own and is useful only when it's
   accompanying the "isub" parameter.  To find out more about the NSAP
   address including definition of AFI, IDI, IDP, and DSP, please
   reference the Appendix A.

   If the "isub-type" is absent, and a message is interpreted by an
   entity on the SIP network, the entity SHOULD assume that the original
   ISDN subaddress from ISUP message was an NSAP address with an
   encoding type of IA5(AFI=0x50), of which DSP value was translated to
   "isub" parameter value and SHOULD handle the message accordingly.

   If the "isub-type" is absent, and the message is handled by a gateway
   translating the SIP message to ISUP message, the gateway SHOULD
   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 ISUP message.

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

6.1.  Gateway behavior

   Gateway receiving message/signal from ISDN network containing ISDN
   subaddress SHOULD check the encoding used for the subaddress, and
   SHOULD set the equivalent "isub" parameter and "isub-type" parameter
   to the SIP message in a form of tel URI parameter.  Following text is
   a recommended guideline when translating ISUP message containing ISDN
   subaddress.

      If the ISDN subaddress is an NSAP address encoded using
      IA5(AFI=0x50), the entity translating the message SHOULD set
      "nsap-ia5" to the "isub-type" and the DSP value starting with 5th
      octet of the subaddress information element in the original ISUP
      message as "isub" value in ASCII characters.

      If the ISDN subaddress is an NSAP address encoded using
      BCD(AFI=0x48), the entity translating the message SHOULD set
      "nsap-bcd" to the "isub-type" and the decoded DSP value starting
      with 5th octet of the subaddress information element in the
      original ISUP message as the "isub" value in ASCII characters
      using numbers.



Munakata, et al.        Expires October 31, 2006               [Page 10]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


         Note: Each semi-octet should be translated to numbers. e.g)
         01001001 would be translated to 4 and 9.

      If the ISDN subaddress is an NSAP address but neither encoded
      using IA5(AFI=0x50) nor BCD(AFI=0x48), the entity translating the
      message SHOULD set "nsap" to the "isub-type" and the IDP and DSP
      value starting with 4th octet of the subaddress information
      element in original ISUP message as "isub" value in hexadecimal
      using ASCII characters(0-9 and A-F).

      If the ISDN subaddress is not an NSAP address but an "User
      Specific" subaddress as defined in Q.931[7], the entity
      translating the message MAY set any value as a token.  When "User
      Specific" address type is used along with BCD encoding type,
      Q.931[7] defines odd/even indicator to enable an entity to pad the
      missing bits(last 4bits of subaddress information) when the digit
      numbers of subaddress is odd.  When interworking with SIP it is
      recommended to not translate the padding bits to "isub" parameter.

6.2.  SIP Entity behavior

   An entity setting an "isub" parameter is RECOMMENDED to set the
   "isub-type" with the encoding type information used for the target's
   ISDN subaddress.  Following text is a recommended guideline when
   setting the "isub" parameter.

      If the "isub-type" is "nsap-ia5", the "isub" parameter value
      SHOULD NOT exceed 19 ASCII characters.

      If the "isub-type" is "nsap-bcd", the "isub" parameter value
      SHOULD NOT exceed 38 ASCII characters(numbers).

      If the "isub-type" is "nsap", the "isub" parameter value SHOULD
      NOT exceed 40 ASCII characters and it SHOULD be in hexadecimal
      using ASCII characters(0-9 and A-F).

      Entity MAY define other type of "isub-type" as a token in which
      case, the semantics and format of the "isub" parameter are beyond
      the scope of this document.












Munakata, et al.        Expires October 31, 2006               [Page 11]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


7.  Security Considerations

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















































Munakata, et al.        Expires October 31, 2006               [Page 12]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


8.  Acknowledgements

   To John Elwell, James Rafferty, Steve Norreys, Michael Hammer, Ray
   Forbes, Martin Dolly and Henning Schulzrinne for providing extensive
   and constructive reviews and comments.














































Munakata, et al.        Expires October 31, 2006               [Page 13]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


Appendix A.  Structure of NSAP Addresses

   In ISUP messages, ISDN subaddress is represented as NSAP address.
   NSAP address is defined as follows in ISO8348[6].

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


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

        +------------------------------------------------+
        |   I D P   |                                    |
        |-----------|             D S P                  |
        | AFI | IDI |                                    |
        +------------------------------------------------+

                          Figure 3



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

   IDI value is decimal digits, and it identifies a network addressing
   domain or authority responsible for allocating values of the DSP.

   Typical encoding type of ISDN subaddress, IA5, is identified with
   AFI=0x50.  When AFI value is 0x50, IDI is null, and the length of IDP
   is 2 digits(1 octet).  In this case, DSP value is a subaddress
   encoded by IA5 and its maximum length is 19 octets.


















Munakata, et al.        Expires October 31, 2006               [Page 14]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


Appendix B.  Changelog

   Changes from 00 to 01. - Many editorial fixes and grammatical
   correction. - Added a text on "User-Specific" address type. - Added a
   text on "odd/even" indicator. - Changed the requirements to clearly
   address the requirements this draft is trying to meet.













































Munakata, et al.        Expires October 31, 2006               [Page 15]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


9.  References

9.1.  Normative Reference

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

9.2.  Informative Reference

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

   [7]  INTERNATIONAL Telecommunications Union, "ISDN User-Network
        Interface Layer 3 Specification for Basic Call Control",
        Recommendation Q.931, 1998.





















Munakata, et al.        Expires October 31, 2006               [Page 16]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


Authors' Addresses

   Mayumi Munakata
   NTT Corporation

   Phone: +81 422 36 7565
   Email: munakata.mayumi at lab.ntt.co.jp


   Shida Schubert
   NTT Corporation

   Phone: +1 604 762 5606


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

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



























Munakata, et al.        Expires October 31, 2006               [Page 17]

Internet-Draft  ISDN subaddress encoding type for tel URI       Apr 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (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.


Acknowledgment

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




Munakata, et al.        Expires October 31, 2006               [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/