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:[email protected]>;tag=a6c85cf
  To: <sip:[email protected]>
  Call-ID: a84b4c76e66710
  Max-Forwards: 70
  CSeq: 116 REGISTER
  Contact: <sip:[email protected];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:[email protected]>;tag=a6c85cf
  To: <sip:[email protected]>;tag=1263390604
  Contact: <sip:[email protected];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:[email protected] SIP/2.0
  Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
  Max-Forwards: 70
  From: Alice <sip:[email protected]>;tag=9fxced76sl
  To: Bob <sip:[email protected]>
  Accept-Contact: *;+sip.fax="t38"
  Call-ID: [email protected]
  CSeq: 1 INVITE
  Contact: <sip:[email protected];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: [email protected]


  Gonzalo Salgueiro
  Cisco Systems
  7200-12 Kit Creek Road
  Research Triangle Park, NC  27709
  US

  EMail: [email protected]


  Kevin P. Fleming
  Digium, Inc.
  445 Jan Davis Drive NW
  Huntsville, AL  35806
  US

  EMail: [email protected]
























Hanes, et al.                Standards Track                    [Page 9]