idnits 2.17.1 draft-hanes-dispatch-fax-capability-08.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 : ---------------------------------------------------------------------------- == 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 date (February 15, 2013) is 4060 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: 0 errors (**), 0 flaws (~~), 2 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: August 19, 2013 K. Fleming 6 Digium, Inc. 7 February 15, 2013 9 Indicating Fax over IP Capability 10 in the Session Initiation Protocol (SIP) 11 draft-hanes-dispatch-fax-capability-08 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 caller 20 preferences 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 August 19, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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. Usage of the sip.fax Parameter . . . . . . . . . . . . . . . . 4 60 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Fax communications in the Session Initiation Protocol (SIP) [RFC3261] 72 are handled in a "voice first" manner. Indications that a user 73 desires to use a fax transport protocol, such as ITU-T T.38 [T38], to 74 send a fax are not known when the initial INVITE message is sent. 75 The call is set up as a voice call first and then only after it is 76 connected, does a switchover to the T.38 [T38] protocol occur. This 77 is problematic in that fax calls can be routed inadvertently to SIP 78 user agents (UAs) that are not fax capable. 80 To ensure that fax calls are routed to fax capable SIP user agents, 81 an implementation of caller preferences defined in RFC 3841 [RFC3841] 82 can be used. Feature preferences are a part of RFC 3841 [RFC3841] 83 that would allow UAs to express their preference for receiving fax 84 communications. Subsequently SIP servers take these preferences into 85 account to increase the likelihood that fax calls are routed to fax 86 capable SIP user agents. 88 This document defines the 'fax' media feature tag for use in the SIP 89 tree as per Section 12.1 of RFC 3840 [RFC3840]. This feature tag 90 will be applied per RFC 3841 [RFC3841] as a feature preference for 91 fax capable UAs. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Motivation 101 In the majority of circumstances, it is preferred that capabilities 102 be handled in the Session Description Protocol (SDP) portion of the 103 SIP [RFC3261] communication. However, fax is somewhat unique in that 104 the ultimate intention of the call is not accurately signaled in the 105 initial SDP exchange. Specifically, indications of T.38 [T38] or any 106 other fax transport protocol in the call are not known when the call 107 is initiated by an INVITE message. Fax calls are always considered 108 voice calls until after they are connected. This results in the 109 possibility of fax calls being received by SIP user agents not 110 capable of handling fax transmissions. 112 For example, Alice wants to send a fax to Bob. Bob has registered two 113 SIP UAs. The first SIP UA is not fax capable but the second one 114 supports the T.38 [T38] fax protocol. Currently, SIP servers are 115 unable to know when the call starts that Alice prefers a fax capable 116 SIP UA to handle her call. Additionally, the SIP servers are also 117 not aware of which of Bob's SIP UAs are fax capable. 119 To resolve this issue of calls not arriving at a UA supporting fax, 120 this document defines a new media feature tag specific to fax per RFC 121 3840 [RFC3840]. Caller preferences as defined in RFC3841 [RFC3841] 122 can then be used for registering UAs that support fax and routing fax 123 calls to these UAs. Thus, Alice can express up front that she 124 prefers a T.38 [T38] fax capable SIP UA for this call. At the same 125 time, Bob's SIP UAs have expressed their fax capabilities as well 126 during registration. Now when Alice places a fax call to Bob, the 127 call is appropriately routed to Bob's fax capable SIP UA. 129 4. Usage of the sip.fax Parameter 131 The sip.fax media feature tag is a new string parameter, defined in 132 this document, that allows a call to indicate a fax preference. A 133 receiving UA includes the "sip.fax" media feature tag in the Contact 134 header field of REGISTER messages to indicate that it is fax-capable, 135 and a SIP Registrar includes this tag in the Contact header field of 136 its 200 OK response to confirm the registration of this preference, 137 all as per RFC 3840 [RFC3840]. 139 A calling UA SHOULD include the "sip.fax" media feature tag in the 140 Accept-Contact header of an INVITE request in order to express its 141 desire for a call to be routed to a fax capable UA. Otherwise, 142 without this tag, fax call determination is not possible until after 143 the call is connected. If a calling UA does so, and the SIP network 144 elements that process the call (including the called UA(s)) implement 145 RFC 3840 and RFC 3841 procedures, then the call will be 146 preferentially routed to UAs that have advertised their support for 147 this feature (by including it in the Contact header of their REGISTER 148 requests, as documented above). 150 It is possible for the calling UA to utilize additional procedures in 151 RFC 3840 and RFC 3841 to express a requirement (instead of a 152 preference) that its call be delivered to fax-capable UAs. However, 153 the calling UA SHOULD NOT require the "sip.fax" media type. Doing so 154 could result in call failure for a number of reasons, not only 155 because there may not be any receiving UAs registered that have 156 advertised their support for this feature, but also because one or 157 more SIP network elements that process the call may not support RFC 158 3840 and RFC 3841 processing. A calling UA that wishes to express 159 this requirement should be prepared to relax it to a preference if it 160 receives a failure response indicating that the requirement mechanism 161 itself is not supported by the called UA(s), their proxies, or other 162 SIP network elements. 164 When calls do connect through the use of "sip.fax" either as a 165 preference or a requirement, then UAs should follow standard fax 166 negotiation procedures documented in ITU-T T.38 [T38] for T.38 fax 167 calls and ITU-T G.711 [G711] and ITU-T V.152 [V152] sections 6 and 168 6.1 for fax passthrough calls. Subsequently, the "sip.fax" feature 169 tag has two allowed values: "t38" and "passthrough". The "t38" value 170 indicates that the impending call will utilize the ITU-T T.38 [T38] 171 protocol for the fax transmission. The "passthrough" value indicates 172 that the ITU-T G.711 [G711] codec will be used to transport the fax 173 call. 175 5. Example 177 Bob registers with the fax media feature tag. The message flow is 178 shown in Figure 1: 180 SIP Registrar Bob's SIP UA 181 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 182 | | 183 | REGISTER F1 | 184 |<------------------------------| 185 | | 186 | 200 OK F2 | 187 |------------------------------>| 188 | | 190 Figure 1: Fax Media Feature Tag SIP Registration Example 192 F1 REGISTER Bob -> Registrar 194 REGISTER sip:example.com SIP/2.0 195 Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2 196 From: ;tag=a6c85cf 197 To: 198 Call-ID: a84b4c76e66710 199 Max-Forwards: 70 200 CSeq: 116 REGISTER 201 Contact: ;+sip.fax="t38" 202 Expires: 3600 203 The registrar responds with a 200 OK: 205 F2 200 OK Registrar -> Bob 207 SIP/2.0 200 OK 208 From: ;tag=a6c85cf 209 To: ;tag=1263390604 210 Contact: ;+sip.fax="t38" 211 Expires: 120 212 Call-ID: a84b4c76e66710 213 Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2 214 CSeq: 116 REGISTER 215 Expires: 3600 217 Callers desiring to express a preference for fax will include the 218 sip.fax media feature tag in the Accept-Contact header of their 219 INVITE. 221 INVITE sip:bob@biloxi.example.com SIP/2.0 222 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 223 Max-Forwards: 70 224 From: Alice ;tag=9fxced76sl 225 To: Bob 226 Accept-Contact: *;+sip.fax="t38" 227 Call-ID: 3848276298220188511@atlanta.example.com 228 CSeq: 1 INVITE 229 Contact: 230 Content-Type: application/sdp 231 Content-Length: 151 233 6. Security Considerations 235 The security considerations related to the use of media feature tags 236 from Section 11.1 of RFC 3840 [RFC3840] apply. 238 7. IANA Considerations 240 This specification adds a new media feature tag to the SIP Media 241 Feature Tag Registration Tree per the procedures defined in RFC 2506 242 [RFC2506] and RFC 3840 [RFC3840]. 244 Media feature tag name: sip.fax 246 ASN.1 Identifier: 1.3.6.1.8.4.{PH} 248 Summary of the media feature indicated by this tag: This feature tag 249 indicates whether a communications device supports the ITU-T T.38 250 [T38] fax protocol ("t38") or the passthrough method of fax 251 transmission using the ITU-T G.711 [G711] audio codec 252 ("passthrough"). 254 Values appropriate for use with this feature tag: Token with an 255 equality relationship. Values are: 257 t38: The device supports the image/t38 media type [RFC3326] and 258 implements ITU-T T.38 [T38] for transporting the ITU-T T.30 259 [T30] and ITU-T T.4 [T4] fax data over IP. 261 passthrough: The device supports the audio/pcmu and audio/pcma 262 media types [RFC4856] for transporting ITU-T T.30 [T30] and 263 ITU-T T.4 [T4] fax data using the ITU-T G.711 [G711] audio 264 codec. Additional implementation recommendations are in ITU-T 265 V.152 [V152] Sections 6 and 6.1. 267 The feature tag is intended primarily for use in the following 268 applications, protocols, services, or negotiation mechanisms: This 269 feature tag is most useful in a communications application for the 270 early identification of a Fax over IP (FoIP) call. 272 Examples of typical use: Ensuring a fax call is routed to a fax 273 capable SIP UA. 275 Related standards or documents: RFCXXXX 277 Security Considerations: The security considerations related to the 278 use of media feature tags from Section 11.1 of RFC 3840 [RFC3840] 279 apply. 281 [[NOTE TO RFC EDITOR: Please change {PH} above to the correct 282 identifier for this entry in the IANA registry for 283 iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4)]] 285 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 286 this specification, and remove this paragraph on publication.]] 288 8. Acknowledgements 290 This document is a result of the unique cooperation between the SIP 291 Forum and the i3 Forum who embarked on a groundbreaking international 292 test program for FoIP to improve the interoperability and reliability 293 of fax communications over IP networks, especially tandem networks. 294 The authors would like to acknowledge the effort and dedication of 295 all the members of the Fax-over-IP (FoIP) Task Group in the SIP Forum 296 and the communications carriers of the I3 Forum that contributed to 297 this global effort. 299 This memo has benefited from the discussion and review of the 300 DISPATCH working group, especially the detailed and thoughtful 301 comments and corrections of Dan Wing, Paul Kyzivat, Christer 302 Holmberg, Charles Eckel, Hadriel Kaplan, Tom Yu, Dale Worley, Adrian 303 Farrel and Pete Resnick. 305 The authors also thank Gonzalo Camarillo for his review and AD 306 sponsorship of this draft and DISPATCH WG chair, Mary Barnes, for her 307 review and support. 309 9. References 311 9.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 317 A., Peterson, J., Sparks, R., Handley, M., and E. 318 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 319 June 2002. 321 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 322 "Indicating User Agent Capabilities in the Session 323 Initiation Protocol (SIP)", RFC 3840, August 2004. 325 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 326 Preferences for the Session Initiation Protocol (SIP)", 327 RFC 3841, August 2004. 329 [T38] International Telecommunication Union, "Procedures for 330 real-time Group 3 facsimile communication over IP 331 Networks", ITU-T Recommendation T.38, October 2010. 333 9.2. Informative References 335 [G711] International Telephone and Telegraph Consultative 336 Committee, "Pulse Code Modulation (PCM) of Voice 337 Frequencies", CCITT Recommendation G.711, 1972. 339 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 340 Registration Procedure", BCP 31, RFC 2506, March 1999. 342 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 343 Header Field for the Session Initiation Protocol (SIP)", 344 RFC 3326, December 2002. 346 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 347 the RTP Profile for Audio and Video Conferences", 348 RFC 4856, February 2007. 350 [T30] International Telecommunication Union, "Procedures for 351 document facsimile transmission in the general switched 352 telephone network", ITU-T Recommendation T.30, 353 September 2005. 355 [T4] International Telecommunication Union, "Standardization of 356 Group 3 facsimile terminals for document transmission", 357 ITU-T Recommendation T.4, July 2003. 359 [V152] International Telecommunication Union, "Procedures for 360 supporting voice-band data over IP networks", ITU- 361 T Recommendation V.152, September 2010. 363 Authors' Addresses 365 David Hanes 366 Cisco Systems 367 7200-10 Kit Creek Road 368 Research Triangle Park, NC 27709 369 US 371 Email: dhanes@cisco.com 373 Gonzalo Salgueiro 374 Cisco Systems 375 7200-12 Kit Creek Road 376 Research Triangle Park, NC 27709 377 US 379 Email: gsalguei@cisco.com 380 Kevin P. Fleming 381 Digium, Inc. 382 445 Jan Davis Drive NW 383 Huntsville, AL 35806 384 US 386 Email: kevin@kpfleming.us