idnits 2.17.1 draft-ietf-mmusic-sdp-t38-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 15, 1998) is 9256 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) -- Missing reference section? '1' on line 148 looks like a reference -- Missing reference section? '2' on line 153 looks like a reference -- Missing reference section? '3' on line 158 looks like a reference -- Missing reference section? '4' on line 163 looks like a reference -- Missing reference section? '5' on line 167 looks like a reference -- Missing reference section? '6' on line 170 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Wedlund/Jiang/Schulzrinne 4 ietf-mmusic-sdp-t38-00.txt Ericsson/Columbia U./Columbia U. 5 December 15, 1998 6 Expires: June 1999 8 SDP Extensions for Fax over IP Using T.38 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 Fax over IP is currently using SMTP, i.e. the fax is sent 33 as an e-mail. It would be desireable to support a fax 34 delivery that can return status of the transmission in 35 real time, such as whether the phone number or address 36 was correct, whether the remote side was busy, etc. The 37 ITU is standardizing a protocol for transferring real 38 time fax over IP, T.38. This standard is meant to be 39 used with the H.323 standard, but it is also possible to 40 use it together with SIP, provided that SDP is extended 41 to support the necessary parameters. This document 42 defines extensions to SDP to support the use of T.38 for 43 real-time fax. 45 1 Introduction 47 Fax is a popular means for transferring documents between locations. 49 Traditionally, this has been done over the telephone network, as 50 defined in the ITU specification T.30 [1]. Some of the reasons for 51 the populatity of fax is that the sender of a fax gets a notification 52 that the fax has been successfully sent, and that the receiver gets 53 information on the senders telephone number and the time the fax was 54 received. Another reason is that fax transmission over a telephone 55 connection can not easily be eavesdropped. When introducing fax over 56 IP, these benefits should be preserved. The ITU standard T.38 [2] 57 defines how to transport the fax signals over IP. It is expected that 58 the fax channel is set up by some other means, e.g., through H.323 or 59 SIP. Annex D of H.323 [3] describes how H.323 supports fax over IP. 60 In this document we will describe how SIP and SDP can do the same. It 61 would probably be possible to even support the T.38 scope with SIP 62 and SDP, but that is for future work. 64 2 Introduction to T.38 66 The ITU T.38 recommendation defines how to transfer fax in realtime 67 between fax gateways and/or IP fax machines in an IP network. 68 Transport of the fax signals is done either by TCP or UDP, and 69 reliability with UDP is achieved through error control mechanisms in 70 T.38, which can be either parity FEC or packet redundancy. The 71 recommendation assumes that a network connection has already been 72 established by the two (or more) peers. This is similar to 73 traditional fax, where a phone line is allocated before the actual 74 fax signalling starts. The issues that are left to be handled by 75 other mechanisms are addressing, identification, authentication, and 76 creation of the fax connection. The fax machines must also have 77 agreed on whether to use UDP or TCP for transport, and in case of 78 UDP, the error control scheme to use. 80 3 Session Initiation Protocol 82 The Session Initiation Protocol (SIP) [4] already provides mechanisms 83 for user (fax machine) location, caller identification, call 84 establishment, and authentication. No additions are needed to support 85 the use of T.38. 87 4 Extensions to SDP 89 The Session Description Protocol (SDP) (RFC 2327 [5]) provides 90 mechanisms for describing sessions. The information that needs to be 91 represented in SDP for T.38 is 93 o the fact that T.38 is to be used, 95 o whether to use TCP or UDP for transport, and 96 o which type of error control to be used by T.38. 98 Thus, the SDP message could be the following: 100 v=0 101 o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68 102 s=FAX message 103 e=faxsupport@company.com 104 t=2873397496 0 105 c=IN IP4 128.59.19.68 106 m=application 49170 udp t38 107 a=t38errctl:parFEC 109 In order to do this, "application/t38" needs to be registered as a 110 MIME type according to the recommendations in [5]. The choice of TCP 111 or UDP can already be represented in SDP, and the error control 112 scheme should be represented as an attribute. 114 5 Security Considerations 116 SIP provides security mechanisms for authentication of caller, and 117 encryption of SIP messages including the SDP payload. For the T.38 118 flow, IP security mechanisms, as defined in RFC 1825 [6], can be 119 used. 121 6 Authors' Addresses 123 Elin Wedlund 124 Switchlab 125 Ericsson Telecom AB 126 S-126 25 Stockholm 127 SWEDEN 128 electronic mail: elin.wedlund@etx.ericsson.se 130 Wenyu Jiang 131 Dept. of Computer Science 132 Columbia University 133 1214 Amsterdam Avenue 134 New York, NY 10027 135 USA 136 electronic mail: wenyu@cs.columbia.edu 138 Henning Schulzrinne 139 Dept. of Computer Science 140 Columbia University 141 1214 Amsterdam Avenue 142 New York, NY 10027 143 USA 144 electronic mail: schulzrinne@cs.columbia.edu 146 7 Bibliography 148 [1] International Telecommunication Union, "Procedures for document 149 facsimile transmission in the general switched telephone network," 150 Recommendation T.30, Telecommunication Standardization Sector of ITU, 151 Geneva, Switzerland, July 1996. 153 [2] International Telecommunication Union, "Procedures for real-time 154 group 3 facsimile communication over IP networks," Recommendation 155 T.38, Telecommunication Standardization Sector of ITU, Geneva, 156 Switzerland, June 1998. 158 [3] International Telecommunication Union, "Visual telephone systems 159 and equipment for local area networks which provide a non-guaranteed 160 quality of service," Recommendation H.323, Telecommunication 161 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 163 [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 164 session initiation protocol," Internet Draft, Internet Engineering 165 Task Force, Nov. 1998. Work in progress. 167 [5] M. Handley and V. Jacobson, "SDP: session description protocol," 168 RFC 2327, Internet Engineering Task Force, Apr. 1998. 170 [6] R. Atkinson, "Security architecture for the internet protocol," 171 RFC 1825, Internet Engineering Task Force, Aug. 1995.