summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6913.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6913.txt')
-rw-r--r--doc/rfc/rfc6913.txt507
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]
+