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)
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.
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.
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.
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].
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.
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.
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: 184.108.40.206.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.
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.