Movatterモバイル変換

Internet Engineering Task Force (IETF)                          D. HanesRequest for Comments: 6913                                  G. SalgueiroCategory: Standards Track                                  Cisco SystemsISSN: 2070-1721                                               K. Fleming                                                            Digium, Inc.                                                              March 2013Indicating Fax over IP Capabilityin 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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6913.Hanes, et al.                Standards Track                    [Page 1]

RFC 6913                  Fax Media Feature Tag               March 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .33.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . .34.  Usage of the "sip.fax" Parameter  . . . . . . . . . . . . . . .45.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . .56.  Security Considerations . . . . . . . . . . . . . . . . . . . .67.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .68.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .79.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .79.1.  Normative References  . . . . . . . . . . . . . . . . . . .79.2.  Informative References  . . . . . . . . . . . . . . . . . .81.  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 inRFC 3841 [RFC3841]   can be used.  Feature preferences are a part ofRFC 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 perSection 12.1 of RFC 3840 [RFC3840].  This feature tag   will be applied perRFC 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 inRFC 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,   perRFC 3840 [RFC3840].  Caller preferences, as defined inRFC 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 20134.  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 perRFC 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 ofRFC 3840 andRFC 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 inRFC 3840 andRFC 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 inRFC 3840 andRFC 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], Sections6 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 20135.  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: 1516.  Security Considerations   The security considerations related to the use of media feature tags   fromSection 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 inRFC 2506   [RFC2506] andRFC 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], Sections6 and6.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 fromSection 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.  References9.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 2013Authors' 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.usHanes, et al.                Standards Track                    [Page 9]