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

Versions: 00 01 02 draft-jesske-sipcore-sip-tree-cap-indicators

Sipcore Working Group                                      A. Allen, Ed.
Internet-Draft                                                Blackberry
Intended status: Informational                                 R. Jesske
Expires: July 22, 2018                                  Deutsche Telekom
                                                        January 18, 2018


 Internet Assigned Numbers Authority (IANA) Registration of the Session
        Initiation Protocol (SIP) Feature-Capability indicators
             draft-allen-sipcore-sip-tree-cap-indicators-02

Abstract

   This document registers with IANA SIP Feature-Capability indicators
   in the "SIP Feature-Capability Indicator Registration Tree" of the
   IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for
   use with the SIP Feature-Caps header field and defines their usage
   and interpretation.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on July 22, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Allen & Jesske            Expires July 22, 2018                 [Page 1]


Internet-Draft          SIP Capability Indicators           January 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  SIP Feature-Capability indicators  . . . . . . . . . . . . . .  5

   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Audio  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Application  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Data . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.5.  Control  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.6.  Video  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.8.  Message  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.9.  Interactive Connectivity Establishment . . . . . . . . . . 12
     5.10. Application Subtype  . . . . . . . . . . . . . . . . . . . 12
     5.11. Fax  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

















Allen & Jesske            Expires July 22, 2018                 [Page 2]


Internet-Draft          SIP Capability Indicators           January 2018


1.  Introduction

   RFC 6809 [1] specifies the SIP Feature-Caps header field that conveys
   feature-capability indicators that are used to indicate support of
   features and capabilities for SIP entities that are not represented
   by the Uniform Resource Identifier (URI) of the Contact header field.
   RFC 6809 [1] also creates a new IANA registry, "Proxy-Feature
   Feature-Capability Indicator Trees", for registering feature-
   capability indicators including a SIP feature-capability indicator
   tree for registering SIP feature-capability indicators that is
   similar to the media feature tag SIP tree defined in RFC 3840 [2].
   To date only one feature-capability indicator, sip.607 (RFC 8197 [8])
   has been included in the SIP feature-capability indicator tree.

   This document populates this SIP tree with some additional feature-
   capability indicators that are based upon those already defined in
   RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC 6913
   [6] and also defines an additional SIP feature-capability indicator
   "Contact-features" that allows an intermediary to indicate a contact
   address and the capabilitie supported by that intermediary if SIP
   Requests are sent to that contact address.


2.  Motivation

   SIP sessions often involve intermediaries (typically acting as
   B2BUAs) that in addition to forwarding SIP requests and responses can
   also act as UAs to perform more complex manipulations of the session.
   Examples of such intermediaries include IP PBXs (Internet Protocol
   Private Branch Exchanges), Telephony Call Feature Application Servers
   and Session Transfer Anchor Points.  Often the manipulations of the
   session by the intermediary are initiated by one of the UAs in the
   session sending a request (such as REFER request) to the intermediary
   to for example transfer the session or create a conference.
   Additionally UAs may also need to subscribe to events related to the
   session with the intermediary accepting such subscriptions and
   providing the notification of event state changes.

   Typically such functionality has been achieved by sending such REFER
   and SUBSCRIBE requests within the established dialog for the session,
   with the intermediary then intercepting and processing the REFER or
   SUBSCRIBE request rather than forwarding it to the remote UAS.
   However such dialog reuse has been problematic and RFC 6665 [9] has
   deprecated dialog reuse (except for legacy interoperability).
   However, in order to avoid reusing the same dialog as the session and
   achieve equivalent functionality when interacting with intermediaries
   using for instance REFER request requires that the UA obtain the
   Globally Routable User Agent URI (GRUU) of the intermediary and also



Allen & Jesske            Expires July 22, 2018                 [Page 3]


Internet-Draft          SIP Capability Indicators           January 2018


   know that the intermediary supports the relevant capabilities such as
   the required SIP methods (i.e.  REFER) as well as the needed SIP
   extensions, (such as target dialog extension specified in RFC 4538 in
   [10]).

   Typically B2BUAs have acted as two UAs back-to-back with the Contact
   URI being the URI of the B2BUA.  However this means that GRUU of the
   UA is overwritten by the B2BUA and the meaning of the Contact header
   field parameters becomes obscure.  Do the Contact header field
   parameters reflect the capabilities of the Contact address (i.e. the
   B2BUA) or do they reflect the capabilities of the remote UA?  If they
   reflect the capabilities of the B2BUA then the identification of the
   capabilities of the remote UA have been lost.  If they reflect the
   capabilities of the remote UA then they falsely identify that the
   B2BUA contact address has the capabilities of the remote UA.

   Another use case for B2BUAs is in control of Application Level
   Gateways (ALGs).  These ALGs are controlled by SIP intermediaries
   that act as routing B2BUs and perform media functions such as IP
   address translation, transcoding, and media policing.  Such ALGs may
   only support some media types while blocking others.  It is useful if
   the media types that are allowed can be communciated to other
   entities in the SIP signaling so that fruitless attempts to establish
   sessions with media types that will not be allowed are not
   attempted.Such functionality is required by 3GPP IMS (IP Multimedia
   Subsystem) to avoid unnecessary failed session establishment
   attempts.

   What is needed is a way for intermediaries to pass the remote UA's
   contact address and capabilities transparently in the Contact header
   field while being able to indicate their own contact address (i.e
   GRUU) and associated capabilities to the UA.

   RFC 6809 [1] provides that addresses of intermediaries can be
   communicated as a value of an associated feature-capability
   indicator.  What is needed is a feature capability indicator to
   communicate the contact address GRUU (Globally Routable User Agent
   URI of the intermediary along with the associated media feature-
   capability indicators tags representing the capabilities supported by
   that of the intermediary if SIP Requests are sent to that contact
   address.  The feature-capability indicators for communicating SIP
   related capabilities (e.g. supported SIP Methods and extensions) also
   need to be registered in the SIP tree in order to allow an
   intermediary to indicate the SIP features it supports when forwarding
   SIP requests or the media capabilities it supports as an ALG.






Allen & Jesske            Expires July 22, 2018                 [Page 4]


Internet-Draft          SIP Capability Indicators           January 2018


3.  SIP Feature-Capability indicators

   This document defines a new Feature-Capability indicator in the SIP
   tree:
      sip.contact

   The sip.contact Feature-Capability indicator provides a GRUU as the
   contact address of the intermediary along with a list of all the
   Fmedia feature tags representing the capabilities of the intermediary
   supported by that intermediary if SIP Requests areent to that contact
   address.

   The following media feature tags from RFC 3840 [2]", RFC 4569 [3],
   RFC 5768 [4], RFC 5688 [5] and RFC 6913 [6] are considered to be
   useful to also be defined as Feature-Capability indicators:
      sip.audio
      sip.application
      sip.data
      sip.control
      sip.video
      sip.text
      sip.message
      sip.ice
      sip.app-subtype
      sip.fax

   An intermediary that includes at least feature capability indicator
   of one of the above media capabilities SHOULD include all the feature
   capability indicators for the media it will allow.  The absence of a
   media capability from the list of feature capability indicators MAY
   be interpreted by another entity as indicating that this media is not
   allowed.  The lack of indication of any of the above media
   capabilities SHOULD be interpreted as inconclusive information about
   what media is allowed or not allowed.

   The following media feature tags from RFC 3840 [2], RFC 4235 [11] and
   RFC 5626 [12] are currently NOT considered to be useful to be defined
   as Feature-Capability indicators since they do not represent stream
   types likely to be implemented by an intermediary:
      sip.automata
      sip.class
      sip.mobility
      sip.actor
      sip.byeless
      sip.rendering
      sip.instance





Allen & Jesske            Expires July 22, 2018                 [Page 5]


Internet-Draft          SIP Capability Indicators           January 2018


      sip.duplex
      sip.description
      sip.events
      sip.priority
      sip.methods
      sip.extensions
      sip.schemes
      sip.isfocus


4.  Security Considerations

   The security considerations in RFC 3840 [2] and RFC 6809 [1] apply to
   the use of Feature-capability indicators in the SIP tree.


5.  IANA Considerations

   This specification registers the following new feature-capability
   indicators in the SIP tree per the procedures defined in RFC 6809
   [12].


5.1.  Contact


      Feature-capability indicator name: sip.contact

      Description:
      This Feature-capability indicator indicator provides a GRUU as the
      contact address of the intermediary along with a list of all the
      media feature tags representing the capabilities of the
      intermediary supported by that intermediary if SIP Requests are
      sent to that contact address.

      Feature-capability indicator specification reference: The present
      document.

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator:

         String with an equality relationship.  The Syntax for the
         string is the same as the of the contents of the Contact header
         field defined in RFC 3261 [7].





Allen & Jesske            Expires July 22, 2018                 [Page 6]


Internet-Draft          SIP Capability Indicators           January 2018


         This Feature-Capability indicator is most useful in a
         communications application, such as an IP-PBX or conference
         bridge for providing a contact address and the capabilities of
         a network intermediary at that contact address.

         Examples of typical use: An conference server indicating that
         it is capable of accepting SIP REFER requests for inviting 3rd
         parties to a conference.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].


5.2.  Audio


      Feature-capability indicator name: sip.audio

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports audio as a streaming media type for sessions established
      via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with audio as a
         streaming media type.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].








Allen & Jesske            Expires July 22, 2018                 [Page 7]


Internet-Draft          SIP Capability Indicators           January 2018


5.3.  Application


      Feature-capability indicator name: sip.application

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports application as a streaming media type for sessions
      established via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with a media
         control application.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].


5.4.  Data




      Feature-capability indicator name: sip.data

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports data as a streaming media type for sessions established
      via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].






Allen & Jesske            Expires July 22, 2018                 [Page 8]


Internet-Draft          SIP Capability Indicators           January 2018


      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with data as a
         streaming media type.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].


5.5.  Control


      Feature-capability indicator name: sip.control

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports control as a streaming media type for sessions
      established via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: A conference bridge indicating that it
         is capable of supporting a floor control application.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].





Allen & Jesske            Expires July 22, 2018                 [Page 9]


Internet-Draft          SIP Capability Indicators           January 2018


5.6.  Video


      Feature-capability indicator name: sip.video

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports video as a streaming media type for sessions established
      via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with video as a
         streaming media type.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].


5.7.  Text


      Feature-capability indicator name: sip.text

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports text as a streaming media type for sessions established
      via it.

      Feature-capability indicator specification reference: RFC 3840
      [2].

      Additional information:






Allen & Jesske            Expires July 22, 2018                [Page 10]


Internet-Draft          SIP Capability Indicators           January 2018


         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with text as a
         streaming media type.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1] and
         RFC 3840 [2].


5.8.  Message


      Feature-capability indicator name: sip.message

      Descrition:
      This Feature-capability indicator indicates that the intermediary
      supports message as a streaming media type for sessions
      established via it.

      Feature-capability indicator specification reference: RFC 4569
      [3].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of accepting and initiating sessions with message as a
         streaming media type.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1], RFC
         3840 [2] and RFC 4569 [3].






Allen & Jesske            Expires July 22, 2018                [Page 11]


Internet-Draft          SIP Capability Indicators           January 2018


5.9.  Interactive Connectivity Establishment


      Feature-capability indicator name: sip.ice

      Description:
      This Feature-capability indicator indicates that the intermediary
      supports Interactive Connectivity Establishment (ICE) for sessions
      established via it.

      Feature-capability indicator specification reference: RFC 5768
      [4].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Boolean.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: An IP PBX indicating that it is
         capable of using ICE to establish media connectivity for
         sessions.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1], RFC
         3840 [2] and RFC 5768 [4].


5.10.  Application Subtype


      Feature-capability indicator name: sip.app-subtype

      Description:
      This Feature-capability indicator indicates the MIME application
      subtypes supported by the intermediary for purposes of streaming
      media for sessions established via it.

      Feature-capability indicator specification reference: RFC 5688
      [5].

      Additional information:






Allen & Jesske            Expires July 22, 2018                [Page 12]


Internet-Draft          SIP Capability Indicators           January 2018


         Values appropriate for use with this Feature-Capability
         indicator: Token (equality relationship).

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.

         Examples of typical use: A conference server indicating that it
         supports an application specific media burst control protocol
         for Push to Talk sessions.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1], RFC
         3840 [2] and RFC 5688 [5].


5.11.  Fax


      Feature-capability indicator name: sip.fax

      Description:
      This Feature-capability indicator indicates whether an
      intermediary accepts sessions using the ITU-T T.38 [13] fax
      protocol ("t38") or the passthrough method of fax transmission
      using the ITU-T G.711 [14] audio codec ("passthrough").

      Feature-capability indicator specification reference: RFC 6913
      [6].

      Additional information:

         Values appropriate for use with this Feature-Capability
         indicator: Token with an equality relationship.  Values are:

            t38: The device supports the "image/t38" media type (RFC
            3326) [15] and implements ITU-T T.38 [13] for transporting
            the ITU-T T.30 [16] and ITU-T T.4 [17] fax data over IP.

            passthrough: The device supports the "audio/pcmu" and
            "audio/ pcma" media types (RFC4856) [18] for transporting
            ITU-T T.30 [16] and ITU-T T.4 [17] fax data using the ITU-T
            G.711 [14] audio codec.

         This Feature-Capability indicator is most useful in a
         communications application for describing the capabilities of a
         network intermediary, such as an IP-PBX or conference bridge.




Allen & Jesske            Expires July 22, 2018                [Page 13]


Internet-Draft          SIP Capability Indicators           January 2018


         Examples of typical use: A conference bridge indicating that it
         is capable of distributing T.38 fax media to the participants
         in a conference.

         Security Considerations: Security considerations for this
         Feature-capability indicator are discussed in RFC 6809 [1], RFC
         3840 [2] and RFC 6913 [6].



6.  Acknowledgements

   This document draws heavily on text from the earlier work on RFC 6809
   [1], RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC
   6913 [6].  The author would like to thank the authors of these RFCs:
   Christer Holmber, Ivo Sedlacek, Hadriel Kaplan, Jonathan Rosenberg
   Henning Schulzrinne, Paul Kyzivat, Gonzalo Camarillo, D Hanes, G
   Salgueiro and K Fleming for their earlier work.


7.  References

7.1.  Normative References

   [1]   Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
         Indicate Support of Features and Capabilities in the Session
         Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809,
         November 2012, <https://www.rfc-editor.org/info/rfc6809>.

   [2]   Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
         User Agent Capabilities in the Session Initiation Protocol
         (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004,
         <https://www.rfc-editor.org/info/rfc3840>.

   [3]   Camarillo, G., "Internet Assigned Number Authority (IANA)
         Registration of the Message Media Feature Tag", RFC 4569,
         DOI 10.17487/RFC4569, July 2006,
         <https://www.rfc-editor.org/info/rfc4569>.

   [4]   Rosenberg, J., "Indicating Support for Interactive Connectivity
         Establishment (ICE) in the Session Initiation Protocol (SIP)",
         RFC 5768, DOI 10.17487/RFC5768, April 2010,
         <https://www.rfc-editor.org/info/rfc5768>.

   [5]   Rosenberg, J., "A Session Initiation Protocol (SIP) Media
         Feature Tag for MIME Application Subtypes", RFC 5688,
         DOI 10.17487/RFC5688, January 2010,
         <https://www.rfc-editor.org/info/rfc5688>.



Allen & Jesske            Expires July 22, 2018                [Page 14]


Internet-Draft          SIP Capability Indicators           January 2018


   [6]   Hanes, D., Salgueiro, G., and K. Fleming, "Indicating Fax over
         IP Capability in the Session Initiation Protocol (SIP)",
         RFC 6913, DOI 10.17487/RFC6913, March 2013,
         <https://www.rfc-editor.org/info/rfc6913>.

   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261,
         June 2002, <https://www.rfc-editor.org/info/rfc3261>.

7.2.  Informative References

   [8]   Schulzrinne, H., "A SIP Response Code for Unwanted Calls",
         RFC 8197, DOI 10.17487/RFC8197, July 2017,
         <https://www.rfc-editor.org/info/rfc8197>.

   [9]   Roach, A., "SIP-Specific Event Notification", RFC 6665,
         DOI 10.17487/RFC6665, July 2012,
         <https://www.rfc-editor.org/info/rfc6665>.

   [10]  Rosenberg, J., "Request Authorization through Dialog
         Identification in the Session Initiation Protocol (SIP)",
         RFC 4538, DOI 10.17487/RFC4538, June 2006,
         <https://www.rfc-editor.org/info/rfc4538>.

   [11]  Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-
         Initiated Dialog Event Package for the Session Initiation
         Protocol (SIP)", RFC 4235, DOI 10.17487/RFC4235, November 2005,
         <https://www.rfc-editor.org/info/rfc4235>.

   [12]  Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing
         Client-Initiated Connections in the Session Initiation Protocol
         (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009,
         <https://www.rfc-editor.org/info/rfc5626>.

   [13]  International Telecommunication Union, "Procedures for real-
         time Group 3 facsimile communication over IP Networks", ITU-
         T Recommendation T.38, October 2010.

   [14]  International Telephone and Telegraph Consultative Committee,
         "Pulse Code Modulation (PCM) of Voice Frequencies",
         CCITT Recommendation G.711, 1972.

   [15]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
         Field for the Session Initiation Protocol (SIP)", RFC 3326,
         DOI 10.17487/RFC3326, December 2002,
         <https://www.rfc-editor.org/info/rfc3326>.




Allen & Jesske            Expires July 22, 2018                [Page 15]


Internet-Draft          SIP Capability Indicators           January 2018


   [16]  International Telecommunication Union, "Procedures for document
         facsimile transmission in the general switched telephone
         network", ITU-T Recommendation T.30, September 2005.

   [17]  International Telecommunication Union, "Standardization of
         Group 3 facsimile terminals for document transmission", ITU-
         T Recommendation T.4, July 2003.

   [18]  Casner, S., "Media Type Registration of Payload Formats in the
         RTP Profile for Audio and Video Conferences", RFC 4856,
         DOI 10.17487/RFC4856, February 2007,
         <https://www.rfc-editor.org/info/rfc4856>.


Authors' Addresses

   Andrew Allen (editor)
   Blackberry
   1560 Sawgrass Corporate Parkway
   Sunrise, Florida  33323
   USA

   Email: aallen@blackberry.com


   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz Str. 3-7
   Darmstadt  64295
   Germany

   Email: r.jesske@telekom.de



















Allen & Jesske            Expires July 22, 2018                [Page 16]


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