idnits 2.17.1 draft-hanes-dispatch-fax-capability-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3841]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2012) is 4196 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'T38' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH D. Hanes 3 Internet-Draft G. Salgueiro 4 Intended status: Standards Track Cisco Systems 5 Expires: May 3, 2013 K. Fleming 6 Digium, Inc. 7 October 30, 2012 9 Indicating Fax over IP Capability 10 in the Session Initiation Protocol (SIP) 11 draft-hanes-dispatch-fax-capability-04 13 Abstract 15 This document defines and registers with IANA the new 'fax' media 16 feature tag for use with SIP. Currently, fax calls are 17 indistinguishable from voice at call initiation. Consequently, fax 18 calls can be routed to SIP user agents that are not fax capable. A 19 'fax' media feature tag implemented in conjunction with RFC 3841 20 [RFC3841] allows for more accurate fax call routing. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Fax communications in the Session Initiation Protocol (SIP) are 71 handled in a "voice first" manner. Indications that a user desires 72 to use a fax transport protocol, such as ITU-T T.38 [T38], to send a 73 fax are not known when the initial INVITE message is sent. The call 74 is set up as a voice call first and then only after it is connected, 75 does a switchover to the T.38 [T38] protocol occur. This is 76 problematic in that fax calls can be routed inadvertently to SIP user 77 agents that are not fax capable. 79 To ensure that fax calls are routed to fax capable SIP user agents, 80 an implementation of caller preferences defined in RFC 3841 [RFC3841] 81 is necessary. Feature preferences are a part of RFC 3841 [RFC3841] 82 that would allow UAs to express their preference for receiving fax 83 communications. Subsequently SIP servers take these preferences into 84 account to increase the likelihood that fax calls land at fax capable 85 SIP user agents. 87 This document defines the 'fax' media feature tag for use in the SIP 88 tree as per Section 12.1 of RFC 3840 [RFC3840]. This feature tag 89 will be applied per RFC 3841 [RFC3841] as a feature preference for 90 fax capable UAs. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Motivation 100 In the majority of circumstances, it is preferred that capabilities 101 be handled in the SDP portion of the SIP communication. However, fax 102 is somewhat unique in that the ultimate intention of the call is not 103 accurately signaled in the initial SDP exchange. Fax is one of the 104 few situations where a media feature tag indicating a capability is 105 highly predictive of the ultimate communication request that will be 106 made in the near future but is not indicated by the current SDP. 108 Specifically, indications of T.38 [T38] or any other fax transport 109 protocol in the call are not known when the call is initiated by an 110 INVITE message. Fax calls are always considered voice calls until 111 after they are connected. This results in increased chances of fax 112 calls being received by SIP user agents not capable of handling fax 113 transmissions. 115 For example, Alice wants to send a fax to Bob. Bob registers two SIP 116 UAs. The first SIP UA is not fax capable but the second one supports 117 the T.38 [T38] fax protocol. Currently, SIP servers are unable to 118 know when the call starts that Alice prefers a fax capable SIP UA to 119 handle her call. Additionally, the SIP servers are also not aware of 120 which of Bob's SIP UAs are fax capable. 122 An implementation of RFC3841 [RFC3841] changes this scenario and 123 feature preferences are used to resolve this issue. With RFC 3841 124 [RFC3841], Alice can express up front that she prefers a T.38 [T38] 125 fax capable SIP UA for this call. At the same time, Bob's SIP UAs 126 have expressed their fax capabilities as well during registration. 127 Now when Alice places a fax call to Bob, the call is appropriately 128 routed to Bob's fax capable SIP UA. 130 4. Example 132 Bob registers with the fax media feature tag. The message flow is 133 shown in FFigure 1: 135 SIP Registrar Bob's SIP UA 136 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 137 | | 138 | REGISTER F1 | 139 |<------------------------------| 140 | | 141 | 200 OK F2 | 142 |------------------------------>| 143 | | 145 Figure 1: Fax Media Feature Tag SIP Registration Example 147 F1 REGISTER Bob -> Registrar 149 REGISTER sip:example.com SIP/2.0 150 Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2 151 From: ;tag=a6c85cf 152 To: 153 Call-ID: a84b4c76e66710 154 Max-Forwards: 70 155 CSeq: 116 REGISTER 156 Contact: ;+sip.fax="t38" 157 Expires: 3600 159 The registrar responds with a 200 OK: 161 F2 200 OK Registrar -> Bob 163 SIP/2.0 200 OK 164 From: ;tag=a6c85cf 165 To: ;tag=1263390604 166 Contact: ;+sip.fax="t38" 167 Expires: 120 168 Call-ID: a84b4c76e66710 169 Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2 170 CSeq: 116 REGISTER 171 Expires: 3600 173 Callers desiring to express a preference for fax will include the 174 sip.fax media feature tag in the Accept-Contact header of their 175 INVITE. 177 INVITE sip:UserY@example.com SIP/2.0 178 From: sip:UserX@operator.com 179 To: sip:UserY@example.com 180 Accept-Contact: *;+sip.fax="t38" 181 Content-Type: application/sdp 183 5. Security Considerations 185 The security considerations related to the use of media feature tags 186 from Section 11.1 of RFC 3840 [RFC3840] apply. 188 6. IANA Considerations 190 This specification adds a new media feature tag to the SIP Media 191 Feature Tag Registration Tree per the procedures defined in RFC 2506 192 [RFC2506] and RFC 3840 [RFC3840]. 194 Media feature tag name: sip.fax 196 ASN.1 Identifier: 1.3.6.1.8.4.{PH} 197 Summary of the media feature indicated by this tag: This feature tag 198 indicates whether a communications device supports the ITU-T T.38 199 [T38] fax protocol ("t38") or the passthrough method of fax 200 transmission using the ITU-T G.711 [G711] audio codec 201 ("passthrough"). 203 Values appropriate for use with this feature tag: Token with an 204 equality relationship. Values are: 206 t38: The device supports the image/t38 media type [RFC3326] and 207 implements ITU-T T.38 [T38] for transporting the ITU-T T.30 208 [T30] and ITU-T T.4 [T4] fax data over IP. 210 passthrough: The device supports the audio/pcmu and audio/pcma 211 media types [RFC4856] for transporting ITU-T T.30 [T30] and 212 ITU-T T.4 [T4] fax data using the ITU-T G.711 [G711] audio 213 codec. Additional implementation recommendations are in ITU-T 214 V.152 [V152] Sections 6 and 6.1. 216 The feature tag is intended primarily for use in the following 217 applications, protocols, services, or negotiation mechanisms: This 218 feature tag is most useful in a communications application for the 219 early identification of a FoIP call. 221 Examples of typical use: Ensuring a fax call is routed to a fax 222 capable SIP UA. 224 Related standards or documents: RFCXXXX 226 Security Considerations: Security considerations for this media 227 feature tag are discussed in Section 5 of this document. 229 [[NOTE TO RFC EDITOR: Please change {PH} above to the correct 230 identifier for this entry in the IANA registry for 231 iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4)]] 233 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 234 this specification, and remove this paragraph on publication.]] 236 7. Acknowledgements 238 This document is a result of the unique cooperation between the SIP 239 Forum and the i3 Forum who embarked on a groundbreaking international 240 test program for FoIP to improve the interoperability and reliability 241 of fax communications over IP networks, especially tandem networks. 242 The authors would like to acknowledge the effort and dedication of 243 all the members of the Fax-over-IP (FoIP) Task Group in the SIP Forum 244 and the communications carriers of the I3 Forum that contributed to 245 this global effort. 247 This memo has benefited from the discussion and review of the 248 DISPATCH working group, especially the detailed and thoughtful 249 comments and corrections of Dan Wing, Paul Kyzivat, Christer 250 Holmberg, Charles Eckel, and Dale Worley. 252 8. References 254 8.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 260 "Indicating User Agent Capabilities in the Session 261 Initiation Protocol (SIP)", RFC 3840, August 2004. 263 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 264 Preferences for the Session Initiation Protocol (SIP)", 265 RFC 3841, August 2004. 267 [T38] International Telecommunication Union, "Procedures for 268 real-time Group 3 facsimile communication over IP 269 Networks", ITU-T Recommendation T.38, October 2010. 271 8.2. Informative References 273 [G711] International Telephone and Telegraph Consultative 274 Committee, "Pulse Code Modulation (PCM) of Voice 275 Frequencies", CCITT Recommendation G.711, 1972. 277 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 278 Registration Procedure", BCP 31, RFC 2506, March 1999. 280 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 281 Header Field for the Session Initiation Protocol (SIP)", 282 RFC 3326, December 2002. 284 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 285 the RTP Profile for Audio and Video Conferences", 286 RFC 4856, February 2007. 288 [T30] International Telecommunication Union, "Procedures for 289 document facsimile transmission in the general switched 290 telephone network", ITU-T Recommendation T.30, 291 September 2005. 293 [T4] International Telecommunication Union, "Standardization of 294 Group 3 facsimile terminals for document transmission", 295 ITU-T Recommendation T.4, July 2003. 297 [V152] International Telecommunication Union, "Procedures for 298 supporting voice-band data over IP networks", ITU- 299 T Recommendation V.152, September 2010. 301 Authors' Addresses 303 David Hanes 304 Cisco Systems 305 7200-10 Kit Creek Road 306 Research Triangle Park, NC 27709 307 US 309 Email: dhanes@cisco.com 311 Gonzalo Salgueiro 312 Cisco Systems 313 7200-12 Kit Creek Road 314 Research Triangle Park, NC 27709 315 US 317 Email: gsalguei@cisco.com 319 Kevin P. Fleming 320 Digium, Inc. 321 445 Jan Davis Drive NW 322 Huntsville, AL 35806 323 US 325 Email: kevin@kpfleming.us