doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc6913.txt b/doc/rfc/rfc6913.txt
new file mode 100644
index 0000000..4daf29f
--- /dev/null
+++ b/doc/rfc/rfc6913.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          D. Hanes
+Request for Comments: 6913                                  G. Salgueiro
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                               K. Fleming
+                                                            Digium, Inc.
+                                                              March 2013
+
+
+                   Indicating Fax over IP Capability
+                in the Session Initiation Protocol (SIP)
+
+Abstract
+
+   This document defines and registers with IANA the new "fax" media
+   feature tag for use with the Session Initiation Protocol (SIP).
+   Currently, fax calls are indistinguishable from voice calls at call
+   initiation.  Consequently, fax calls can be routed to SIP user agents
+   that are not fax capable.  A "fax" media feature tag implemented in
+   conjunction with caller preferences allows for more accurate fax call
+   routing.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6913.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 1]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Usage of the "sip.fax" Parameter  . . . . . . . . . . . . . . . 4
+   5.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   Fax communications in the Session Initiation Protocol (SIP) [RFC3261]
+   are handled in a "voice first" manner.  Indications that a user
+   desires to use a fax transport protocol, such as ITU-T T.38 [T38], to
+   send a fax are not known when the initial INVITE message is sent.
+   The call is set up as a voice call first, and then, only after it is
+   connected, does a switchover to the T.38 [T38] protocol occur.  This
+   is problematic in that fax calls can be routed inadvertently to SIP
+   user agents (UAs) that are not fax capable.
+
+   To ensure that fax calls are routed to fax-capable SIP UAs, an
+   implementation of caller preferences defined in RFC 3841 [RFC3841]
+   can be used.  Feature preferences are a part of RFC 3841 [RFC3841]
+   that would allow UAs to express their preference for receiving fax
+   communications.  Subsequently, SIP servers take these preferences
+   into account to increase the likelihood that fax calls are routed to
+   fax-capable SIP UAs.
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 2]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+   This document defines the "fax" media feature tag for use in the SIP
+   tree, as per Section 12.1 of RFC 3840 [RFC3840].  This feature tag
+   will be applied per RFC 3841 [RFC3841] as a feature preference for
+   fax-capable UAs.
+
+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 [RFC2119].
+
+3.  Motivation
+
+   In the majority of circumstances, it is preferred that capabilities
+   be handled in the Session Description Protocol (SDP) portion of the
+   SIP [RFC3261] communication.  However, fax is somewhat unique in that
+   the ultimate intention of the call is not accurately signaled in the
+   initial SDP exchange.  Specifically, indications of T.38 [T38] or any
+   other fax transport protocol in the call are not known when the call
+   is initiated by an INVITE message.  Fax calls are always considered
+   voice calls until after they are connected.  This results in the
+   possibility of fax calls being received by SIP UAs that are not
+   capable of handling fax transmissions.
+
+   For example, Alice wants to send a fax to Bob.  Bob has registered
+   two SIP UAs.  The first SIP UA is not fax capable, but the second one
+   supports the T.38 [T38] fax protocol.  Currently, SIP servers are
+   unable to know at the time that the call starts that Alice prefers a
+   fax-capable SIP UA to handle her call.  Additionally, the SIP servers
+   are also not aware of which of Bob's SIP UAs are fax capable.
+
+   To resolve this issue of calls not arriving at a UA that supports
+   fax, this document defines a new media feature tag specific to fax,
+   per RFC 3840 [RFC3840].  Caller preferences, as defined in RFC 3841
+   [RFC3841], can then be used for registering UAs that support fax and
+   for routing fax calls to these UAs.  Thus, Alice can express up front
+   that she prefers a T.38 [T38] fax-capable SIP UA for this call.  At
+   the same time, Bob's SIP UAs have expressed their fax capabilities as
+   well during registration.  Now, when Alice places a fax call to Bob,
+   the call is appropriately routed to Bob's fax-capable SIP UA.
+
+
+
+
+
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 3]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+4.  Usage of the "sip.fax" Parameter
+
+   The "sip.fax" media feature tag is a new string parameter, defined in
+   this document, that allows a call to indicate a fax preference.  A
+   receiving UA includes the "sip.fax" media feature tag in the Contact
+   header field of REGISTER messages to indicate that it is fax capable,
+   and a SIP Registrar includes this tag in the Contact header field of
+   its 200 OK response to confirm the registration of this preference,
+   all as per RFC 3840 [RFC3840].
+
+   A calling UA SHOULD include the "sip.fax" media feature tag in the
+   Accept-Contact header of an INVITE request in order to express its
+   desire for a call to be routed to a fax-capable UA.  Otherwise,
+   without this tag, fax call determination is not possible until after
+   the call is connected.  If a calling UA includes the "sip.fax" tag
+   and the SIP network elements that process the call (including the
+   called UAs) implement the procedures of RFC 3840 and RFC 3841, the
+   call will be preferentially routed to UAs that have advertised their
+   support for this feature (by including it in the Contact header of
+   their REGISTER requests, as documented above).
+
+   It is possible for the calling UA to utilize additional procedures
+   defined in RFC 3840 and RFC 3841 to express a requirement (instead of
+   a preference) that its call be delivered to fax-capable UAs.
+   However, the calling UA SHOULD NOT require the "sip.fax" media type.
+   Doing so could result in call failure for a number of reasons, not
+   only because there may not be any receiving UAs registered that have
+   advertised their support for this feature, but also because one or
+   more SIP network elements that process the call may not support the
+   processing defined in RFC 3840 and RFC 3841.  A calling UA that
+   wishes to express this requirement should be prepared to relax it to
+   a preference if it receives a failure response indicating that the
+   requirement mechanism itself is not supported by the called UAs,
+   their proxies, or other SIP network elements.
+
+   When calls do connect through the use of "sip.fax" either as a
+   preference or a requirement, UAs should follow standard fax
+   negotiation procedures documented in ITU-T T.38 [T38] for T.38 fax
+   calls and ITU-T G.711 [G711] and ITU-T V.152 [V152], Sections 6 and
+   6.1, for fax passthrough calls.  Subsequently, the "sip.fax" feature
+   tag has two allowed values: "t38" and "passthrough".  The "t38" value
+   indicates that the impending call will utilize the ITU-T T.38 [T38]
+   protocol for the fax transmission.  The "passthrough" value indicates
+   that the ITU-T G.711 [G711] codec will be used to transport the fax
+   call.
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 4]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+5.  Example
+
+   Bob registers with the fax media feature tag.  The message flow is
+   shown in Figure 1:
+
+               SIP Registrar                    Bob's SIP UA
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+                   |                               |
+                   |          REGISTER F1          |
+                   |<------------------------------|
+                   |                               |
+                   |           200 OK F2           |
+                   |------------------------------>|
+                   |                               |
+
+         Figure 1: Fax Media Feature Tag SIP Registration Example
+
+
+   F1 REGISTER Bob -> Registrar
+
+   REGISTER sip:example.com SIP/2.0
+   Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
+   From: <sip:bob-tp@example.com>;tag=a6c85cf
+   To: <sip:bob-tp@pexample.com>
+   Call-ID: a84b4c76e66710
+   Max-Forwards: 70
+   CSeq: 116 REGISTER
+   Contact: <sip:bob-tp@pc33.example.com;transport=tcp>;+sip.fax="t38"
+   Expires: 3600
+
+   The registrar responds with a 200 OK:
+
+   F2 200 OK Registrar -> Bob
+
+   SIP/2.0 200 OK
+   From: <sip:bob-tp@example.com>;tag=a6c85cf
+   To: <sip:bob-tp@example.com>;tag=1263390604
+   Contact: <sip:bob-tp@example.com;transport=tcp>;+sip.fax="t38"
+   Expires: 120
+   Call-ID: a84b4c76e66710
+   Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
+   CSeq: 116 REGISTER
+   Expires: 3600
+
+   Callers desiring to express a preference for fax will include the
+   "sip.fax" media feature tag in the Accept-Contact header of their
+   INVITE.
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 5]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+   INVITE sip:bob@biloxi.example.com SIP/2.0
+   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
+   Max-Forwards: 70
+   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+   To: Bob <sip:bob@biloxi.example.com>
+   Accept-Contact: *;+sip.fax="t38"
+   Call-ID: 3848276298220188511@atlanta.example.com
+   CSeq: 1 INVITE
+   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
+   Content-Type: application/sdp
+   Content-Length: 151
+
+6.  Security Considerations
+
+   The security considerations related to the use of media feature tags
+   from Section 11.1 of RFC 3840 [RFC3840] apply.
+
+7.  IANA Considerations
+
+   This specification adds a new media feature tag to the SIP Media
+   Feature Tag Registration Tree per the procedures defined in RFC 2506
+   [RFC2506] and RFC 3840 [RFC3840].
+
+   Media feature tag name:  sip.fax
+
+   ASN.1 Identifier:  1.3.6.1.8.4.25
+
+   Summary of the media feature indicated by this tag:  This feature tag
+      indicates whether a communications device supports the ITU-T T.38
+      [T38] fax protocol ("t38") or the passthrough method of fax
+      transmission using the ITU-T G.711 [G711] audio codec
+      ("passthrough").
+
+   Values appropriate for use with this feature tag:  Token with an
+      equality relationship.  Values are:
+
+      t38:  The device supports the "image/t38" media type [RFC3326] and
+         implements ITU-T T.38 [T38] for transporting the ITU-T T.30
+         [T30] and ITU-T T.4 [T4] fax data over IP.
+
+      passthrough:  The device supports the "audio/pcmu" and "audio/
+         pcma" media types [RFC4856] for transporting ITU-T T.30 [T30]
+         and ITU-T T.4 [T4] fax data using the ITU-T G.711 [G711] audio
+         codec.  Additional implementation recommendations are in ITU-T
+         V.152 [V152], Sections 6 and 6.1.
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 6]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+   The feature tag is intended primarily for use in the following
+      applications, protocols, services, or negotiation mechanisms:
+      This feature tag is most useful in a communications application
+      for the early identification of a Fax over IP (FoIP) call.
+
+   Examples of typical use:  Ensuring a fax call is routed to a fax
+      capable SIP UA.
+
+   Related standards or documents:  RFC 6913
+
+   Security Considerations:  The security considerations related to the
+      use of media feature tags from Section 11.1 of RFC 3840 [RFC3840]
+      apply.
+
+8.  Acknowledgements
+
+   This document is a result of the unique cooperation between the SIP
+   Forum and the i3 Forum, who embarked on a groundbreaking
+   international test program for FoIP to improve the interoperability
+   and reliability of fax communications over IP networks, especially
+   tandem networks.  The authors would like to acknowledge the effort
+   and dedication of all the members of the Fax-over-IP (FoIP) Task
+   Group in the SIP Forum and the communications carriers of the I3
+   Forum who contributed to this global effort.
+
+   This memo has benefited from the discussion and review of the
+   DISPATCH working group, especially the detailed and thoughtful
+   comments and corrections of Dan Wing, Paul Kyzivat, Christer
+   Holmberg, Charles Eckel, Hadriel Kaplan, Tom Yu, Dale Worley, Adrian
+   Farrel, and Pete Resnick.
+
+   The authors also thank Gonzalo Camarillo for his review and AD
+   sponsorship of this draft and DISPATCH WG chair, Mary Barnes, for her
+   review and support.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  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.
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 7]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
+              "Indicating User Agent Capabilities in the Session
+              Initiation Protocol (SIP)", RFC 3840, August 2004.
+
+   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
+              Preferences for the Session Initiation Protocol (SIP)",
+              RFC 3841, August 2004.
+
+   [T38]      International Telecommunication Union, "Procedures for
+              real-time Group 3 facsimile communication over IP
+              Networks", ITU-T Recommendation T.38, October 2010.
+
+9.2.  Informative References
+
+   [G711]     International Telephone and Telegraph Consultative
+              Committee, "Pulse Code Modulation (PCM) of Voice
+              Frequencies", CCITT Recommendation G.711, 1972.
+
+   [RFC2506]  Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
+              Registration Procedure", BCP 31, RFC 2506, March 1999.
+
+   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
+              Header Field for the Session Initiation Protocol (SIP)",
+              RFC 3326, December 2002.
+
+   [RFC4856]  Casner, S., "Media Type Registration of Payload Formats in
+              the RTP Profile for Audio and Video Conferences",
+              RFC 4856, February 2007.
+
+   [T30]      International Telecommunication Union, "Procedures for
+              document facsimile transmission in the general switched
+              telephone network", ITU-T Recommendation T.30, September
+              2005.
+
+   [T4]       International Telecommunication Union, "Standardization of
+              Group 3 facsimile terminals for document transmission",
+              ITU-T Recommendation T.4, July 2003.
+
+   [V152]     International Telecommunication Union, "Procedures for
+              supporting voice-band data over IP networks", ITU-T
+              Recommendation V.152, September 2010.
+
+
+
+
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 8]
+
+RFC 6913                  Fax Media Feature Tag               March 2013
+
+
+Authors' Addresses
+
+   David Hanes
+   Cisco Systems
+   7200-10 Kit Creek Road
+   Research Triangle Park, NC  27709
+   US
+
+   EMail: dhanes@cisco.com
+
+
+   Gonzalo Salgueiro
+   Cisco Systems
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   US
+
+   EMail: gsalguei@cisco.com
+
+
+   Kevin P. Fleming
+   Digium, Inc.
+   445 Jan Davis Drive NW
+   Huntsville, AL  35806
+   US
+
+   EMail: kevin@kpfleming.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hanes, et al.                Standards Track                    [Page 9]
+