Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2848

The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services

Pages: 73
Proposed Standard
Part 4 of 4 – Pages 62 to 73
First   Prev   None

Top   ToC   RFC2848 - Page 62   prevText

7. References

[1] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
Top   ToC   RFC2848 - Page 63
   [3]  Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

   [5]  The Unicode Consortium, "The Unicode Standard -- Version 2.0",
        Addison-Wesley, 1996.

   [6]  ITU-T Study Group 2, "E.164 - The International Public Network
        Numbering Plan", ITU-T, June 1997.

   [7]  Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F.,
        DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K.
        Vishwanathan "Toward the PSTN/Internet Inter-Networking--Pre-
        PINT Implementations", RFC 2458, November 1998.

   [8]  ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN
        User Part of SS No7" ITU-T, August 1994.

   [9]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [10] Crocker, D., "Standard for the format of ARPA Internet text
        messages", STD 11, RFC 822, August 1982.

   [11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane
        Architecture", ITU-T, February 1994.

   [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [13] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and CRL Profile", RFC
        2459, January 1999.

   [15] Crocker, D. and P. Overall, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [16] Mills, D., "Network Time Protocol (version 3) specification and
        implementation", RFC 1305, March 1992.
Top   ToC   RFC2848 - Page 64
   [17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

   [18] Mockapetris, P., "Domain Names - Implementation and
        Specification", STD 13, RFC 1035, November 1987.

   [19] Levinson, E., "The MIME Multipart/Related Content-type" RFC
        2387, August 1998.

8. Acknowledgements

The authors wish to thank the members of the PINT working group for comments that were helpful to the preparation of this specification. Ian Elz's comments were extremely useful to our understanding of internal PSTN operations. The SUBSCRIBE and NOTIFY requests were first suggested by Henning Schulzrinne and Jonathan Rosenberg. The suggestion to use an audio port of 0 to express that the phone is "on hold" (i.e. not receiving voice) is due to Ray Zibman. Finally, thanks to Bernie Hoeneisen for his close proofreading.
Top   ToC   RFC2848 - Page 65

Appendix A: Collected ABNF for PINT Extensions

;; --(ABNF is specified in RFC 2234 [15]) ;; --Variations on SDP definitions connection-field = ["c=" nettype space addrtype space connection-address CRLF] ; -- this is the original definition from SDP, included for completeness ; -- the following are PINT interpretations and modifications nettype = ("IN"/"TN") ; -- redefined as a superset of the SDP definition addrtype = (INAddrType / TNAddrType) ; -- redefined as a superset of the SDP definition INAddrType = ("IP4"/"IP6") ; -- this non-terminal added to hold original SDP address types TNAddrType = ("RFC2543"/OtherAddrType) OtherAddrType = (<X-Token>) ; -- X-token is as defined in RFC2045 addr = (<FQDN> / <unicast-address> / TNAddr) ; -- redefined as a superset of the original SDP definition ; -- FQDN and unicast address as specified in SDP TNAddr = (RFC2543Addr/OtherAddr) ; -- TNAddr defined only in context of nettype == "TN" RFC2543Addr = (INPAddr/LDPAddr) INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) ; -- POS-DIGIT and DIGIT as defined in SDP LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) OtherAddr = 1*<uric> ; -- OtherAdd defined in the context of OtherAddrType ; -- uric is as defined in RFC2396 media-field = "m=" media <space> port <space> proto 1*(<space> fmt) <CRLF> ; -- NOTE redefined as subset/relaxation of original SDP definition ; -- space and CRLF as defined in SDP
Top   ToC   RFC2848 - Page 66
media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are
; --  used in PINT 1.0

port = ("0" / "1")
; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold")
; -- (1 means there is media)

proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition

INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP
TNProto = ("voice"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN"

fmt = (<subtype> / "-")
; -- NOTE redefined as a subset of the original SDP definition
; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type
held
; --  in associated media sub-field or the special value "-".

attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP

attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP

PINT-attribute = (clir-attribute / q763-nature-attribute /
                   q763plan-attribute / q763-INN-attribute /
                   phone-context-attribute / tsp-attribute /
                   pint-fmtp-attribute / strict-attribute)

clir-attribute = clir-tag ":" ("true" / "false")

clir-tag = "clir"

q763-nature-attribute = Q763-nature-tag ":" q763-natures

q763-nature-tag = "Q763-nature"

q763-natures = ("1" / "2" / "3" / "4")
Top   ToC   RFC2848 - Page 67
q763-plan-attribute = Q763-plan-tag ":" q763-plans

q763-plan-tag = "Q763-plan"

q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text

q763-INN-attribute = Q763-INN-tag ":" q763-INNs

q763-INN-tag = "Q763-INN"

q763-INNs = ("0" / "1")

phone-context-attribute = phone-context-tag ":" phone-context-ident

phone-context-tag = "phone-context"

phone-context-ident = network-prefix / private-prefix

network-prefix = intl-network-prefix / local-network-prefix

intl-network-prefix = "+" 1*<DIGIT>

local-network-prefix = 1*<DIGIT>

private-prefix = 1*excldigandplus 0*<uric>

excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname

tsp-tag = "tsp"

provider-domainname = <domain>
; -- domain is defined in RFC1035

; -- NOTE the following is redefined relative to the normal use in SDP
pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution
                      *(<space> resolution)
                      (<space> ";" 1(<attribute>) *(<space>
<attribute>))
; -- subtype as defined in RFC2046.
; -- NOTE that this value MUST match a fmt on the ultimately preceeding
; --  media-field
; -- attribute is as defined in SDP

resolution = (uri-ref / opaque-ref / sub-part-ref)

uri-ref = uri-tag ":" <URI-Reference>
Top   ToC   RFC2848 - Page 68
; -- URI-Reference defined in RFC2396

uritag = "uri"

opaque-ref = opr-tag ":" 0*<uric>

opr-tag = "opr"

sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822

spr-tag = "spr"

strict-attribute = "require:" att-tag-list

att-tag-list = 1(PINT-att-tag-list / <att-field> /
                    pint-fmtp-tag-list)
                  *(","
                    (PINT-att-tag-list / <att-field> /
                      pint-fmtp-tag-list)
                   )
; -- att-field as defined in SDP

PINT-att-tag-list = (phone-context-tag / clir-tag /
                       q763-nature-tag / q763-plan-tag /
                       q763-INN-tag)

pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)

;; --Variations on SIP definitions

clir-parameter = clir-tag "=" ("true" / "false")

q763-nature-parameter = Q763-nature-tag "=" Q763-natures

q763plan-parameter = Q763-plan-tag "=" q763plans

q763-INN-parameter = Q763-INN-tag "=" q763-INNs

tsp-parameter = tsp-tag "=" provider-domainname

phone-context-parameter = phone-context-tag "=" phone-context-ident

SIP-param = ( <transport-param> / <user-param> / <method-param> /
                <ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP

PINT-param = ( clir-parameter / q763-nature-parameter /
Top   ToC   RFC2848 - Page 69
                q763plan-parameter / q763-INN-parameter/
                tsp-parameter / phone-context-parameter )

URL-parameter = (SIP-param / PINT-param)
; -- redefined SIP's URL-parameter to include ones defined in PINT

Require-header = "require:" 1(required-extensions)
                             *("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)

required-extensions = ("org.ietf.sip.subscribe" /
                       "org.ietf.sdp.require")

Appendix B: IANA Considerations

There are three kinds of identifier used in PINT extensions that SHOULD be registered with IANA, if a new value is specified. These are: * Media Format sub-types, as described in section 3.4.2 of this document. * Private Attributes as mentioned in section 3.4.3 * Private Phone Context values, as described in section 3.4.3.1. It should be noted that private Address Types (in section 3.4.1) have been explicitly excluded from this process, as they must be in the form of an X-Token.

B.1. Media Format Sub-types

Taking these in turn, the media format sub-types are used within the PINT extensions to SDP to specify the attribute line that holds the data source definitions. In normal use, the values in this field are sub-types of MIME discrete types[4]. If a value other than an IANA- registered sub-type is to be used, then it should either be an X- Token (i.e. start with "X-") or it should be registered with IANA. if the intention is to describe a new MIME sub-type, then the procedures specified in RFC 2048 should be used. It is ASSUMED that any new MIME sub-type would follow the syntactic rules for interpretation of associated PINT fmtp lines defined in this document. Note that, in keeping with the SDP description, such registrations SHOULD include the "proto" field values within which they are defined; however, it is appropriate to specify only that they can be used with "all values of TNProto".
Top   ToC   RFC2848 - Page 70
   Conversely, if the intent is to define a new way of including data
   source definitions within PINT, then it will be necessary to specify,
   in the documentation supporting any such new "PINT Media Format Sub-
   type" registration, the syntax of the associated "fmtp" attribute
   line, as the identifier serves to indicate the interpretation that
   should be made of format specific attribute lines "tagged" with such
   a sub-type.

   If the fmtp interpretation follows the PINT default, then it is
   adequate to mention this in the defining document rather than
   repeating the syntax definition given here (although, in this case,
   it is unclear why such a new registration would be required). As
   before, the Media Format sub-type SHOULD specify the values of
   "proto" field within which it is defined, but this can be "all values
   of TNProto".

B.2. Private Attributes

Any proprietary attribute lines that are added may be registered with IANA using the procedures mentioned in [2]; the mechanism is the same as that used in SDP. If the attribute is defined for use only within PINT, then it may be appropriate to mention this in the supporting documentation. Note that, in the PINT 1.0 specification covered here, there is no mechanism to add such freshly registered attribute lines to a "require:" clause.

B.3. Private phone-contexts

Within the session description used for PINT requests, a phone- context attribute may be used to specify the prefix or context within which an associated telephone-number (in a connection line) should be interpreted. For "public" phone contexts the prefix to be used MUST start with either a DIGIT or a "+". Private phone contexts may be registered with IANA that do NOT start with either of these characters. Such a prefix may be useful to identify a private network, potentially with an associated numeric ID (see example 4 in section 3.4.3.1). In the example, the prefix acts as the context for X-acme.com's private network numbering plan. It is recommended that any private context to be registered have the general form of a token including a domain name, optionally followed by a digit string or other token. The appropriate form of the initial token name space will be similar to that used for private or vendor registrations for sub-types (e.g. vnd.acme.com). However, note that the registration will be used to specify a customer's private network numbering plan format rather than being used generally for all of
Top   ToC   RFC2848 - Page 71
   their equipment vendor's customer's; thus, fbi.gov would be
   appropriate, but lucent.com would not (unless the private network
   were to be that used by Lucent internally).

   In addition, the supporting documentation MUST either declare that
   there is no associated token, or define the syntax by which that
   token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the
   registration describes a format, not a value range; it is sufficient
   that the private context can be parsed, without the value being
   interpreted.

   In detail, the registration request SHOULD include:

   *  Kind of registration (i.e. private phone-context attribute to be
      used within the service description of PINT service requests)
   *  Contact details for the person responsible for the registration
      request (name, organisation, e-mail address, public telephone
      number)
   *  Private Prefix initial token name (e.g. vnd.fbi.gov)
   *  syntax for private context (e.g. "vnd.fbi.gov" <space> 1*DIGIT, or
      "vnd.gtn.gov.uk")
   *  Description of use (e.g. "This phone context declares an
      associated telephone number to be within the 'government
      telecommunications network'; the number is in an internal or
      private number plan form)
   *  Network Type and Address Type with which this private context is
      associated; If the "normal" telephone types (as specified in this
      document) are used, then the values would be shown as:
      "nettype=TN" , addrtype="RFC2543Addr". If, however, this context
      were to be used with another address type, then a reference to
      that address type name and the syntax of that address value would
      be required.

   In short, this context is the telephone equivalent of a "Net 10"
   address space behind a NAT, and the initial name (and contact
   information) shows the context within which that address is valid. It
   also specifies the format for the network and address types (and
   address value syntax) with which this context is associated.

   Of course, IANA may refer the requested registration to the IESG or
   an appropriate IETF working group for review, and may require
   revisions to be made before the registration is accepted.
Top   ToC   RFC2848 - Page 72

Authors' Addresses

Scott Petrack MetaTel, Inc. 45 Rumford Ave. Waltham MA 02453-3844 Phone: +1 (781)-891-9000 EMail: scott.petrack@metatel.com Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Phone: +44 (1794) 833666 EMail: lwc@roke.co.uk
Top   ToC   RFC2848 - Page 73
Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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