idnits 2.17.1 draft-andreasen-mgcp-fax-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2007. 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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force F. Andreasen 2 Internet Draft Cisco Systems 3 Document: draft-andreasen-mgcp-fax-08.txt 4 Category: Informational D. Hancock 5 CableLabs 7 Expires: Aug, 2008 Feb, 2008 9 Media Gateway Control Protocol Fax Package 10 draft-andreasen-mgcp-fax-08 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines a Media Gateway Control Protocol (MGCP) 38 package to support fax calls. The package allows for fax calls to 39 be supported in two different ways. The first one utilizes ITU-T 40 Recommendation T.38 for fax relay under the control of the Call 41 Agent. The second one lets the gateway decide upon a method for fax 42 transmission as well as handle the details of the fax call without 43 Call Agent involvement. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in BCP 14, RFC-2119 50 [RFC2119]. 52 Table of Contents 53 1. Introduction......................................................3 54 2. Fax Package Definition............................................3 55 2.1 LocalConnectionOptions..........................................3 56 2.1.1 T.38 Procedure (Strict or Loose)............................5 57 2.1.2 Gateway Procedure...........................................7 58 2.1.3 Off Procedure...............................................7 59 2.1.4 Mode Operation..............................................8 60 2.1.5 Detecting a Fax Call........................................9 61 2.1.6 Considerations for Which Procedures to Request.............10 62 2.2 Events and Signals.............................................11 63 2.2.1 Gateway Controlled Fax (gwfax).............................12 64 2.2.2 No Special Fax Handling (nopfax)...........................13 65 2.2.3 T.38 fax relay(t38):.......................................13 66 2.3 Connection Parameters..........................................14 67 2.4 Negotiation of T.38 Parameters.................................15 68 2.5 Implementation Considerations..................................16 69 2.5.1 Media IP Address and Port for T.38.........................16 70 2.5.2 Case Sensitivity...........................................17 71 2.5.3 Boolean Indicator after T.38 Parameters....................17 72 3. Call Flow Examples...............................................17 73 3.1 Call Agent Controlled T.38 Strict..............................17 74 3.2 Multiple and Different Options.................................24 75 3.3 Interaction with SIP Endpoints.................................31 76 4. Security Considerations..........................................37 77 5. IANA Considerations..............................................37 78 6. Summary of Changes...............................................37 79 7. Normative References.............................................38 80 8. Informative References...........................................38 81 9. Acknowledgements.................................................39 82 10. Author's Address................................................39 83 Full Copyright Statement............................................40 84 Disclaimer of validity..............................................40 85 1. Introduction 87 This document defines a Media Gateway Control Protocol (MGCP) 88 [RFC3435] package that enables MGCP controlled gateways to support 89 fax calls. The package enables fax calls to be supported in two 90 different ways. The first one utilizes ITU-T Recommendation T.38 91 using either UDPTL or TCP (see [T38]) for fax relay under the 92 control of the Call Agent. The second one lets the gateway decide 93 upon a method for fax transmission as well as handle the details of 94 the fax call without Call Agent involvement. 96 The fax package definition is provided in Section 2 and in Section 3 97 we provide three call flow examples showing how to use it. Security 98 considerations are found in Section 4, followed by the IANA 99 considerations and references. 101 2. Fax Package Definition 103 A package is defined for fax. The package defines new 104 LocalConnectionOptions, events, and connection parameters as 105 detailed below. 107 Package Name: FXR 108 Package Version: 0 110 2.1 LocalConnectionOptions 112 A new Fax LocalConnectionOptions (LCO) parameter is defined for fax 113 handling. The Call Agent supplies this fax LCO to indicate the 114 desired fax handling procedure to the Media Gateway. The fax LCO 115 contains a list of desired fax handling procedures ordered by 116 preference with the most desired procedure listed first. When the 117 parameter is explicitly included in a command, the gateway MUST be 118 able to use at least one of the listed procedures for the command to 119 succeed. The list can currently indicate one or more of the 120 following procedures (see Section 2.1.1 to 2.1.4 for further details 121 on these): 123 * T.38 Strict: 124 Use T.38 [T38] with either UDPTL or TCP for fax relay and have the 125 Call Agent control it. Assuming the procedure can be used (see 126 Section 2.1.1), a switch to T.38 procedures will be initiated upon 127 fax detection and a "t38(start)" event will be generated (see 128 Section 2.2). This mode requires an indication of T.38 support 129 from the remote side in order to be used, as described further in 130 Section 2.1.1. 132 * T.38 Loose: 133 Identical to T.38 Strict procedure, except that an indication of 134 T.38 support from the remote side is not required for the 135 procedure to be used. 137 * Off: 138 Do not invoke any special procedure for fax, except for echo 139 cancellation adjustment and possibly switching to another codec. 141 * Gateway: 142 Let the gateway control and decide how to handle fax calls without 143 Call Agent involvement. This includes the case where the gateway 144 does not do anything special for fax, hence by definition this 145 procedure can always be supported. If the gateway does invoke a 146 special procedure upon detection of fax, it will generate a 147 "gwfax(start)" event so the Call Agent can be notified about it 148 (see Section 2.2). The Call Agent SHOULD then refrain from 149 issuing potentially conflicting commands to the gateway until the 150 gateway ends its special fax handling procedure. 152 A gateway that ends up not being able to invoke any special 153 procedure for fax will generate a "nopfax(start)" event (see Section 154 2.2) upon detection of fax. 156 The set of possible values (i.e. procedures) for the fax LCO is 157 extensible. The prefix "x-", which indicates an optional extension, 158 and the prefix "x+", which indicates a mandatory extension, are 159 reserved for vendor-specific use. 161 In CreateConnection commands, the fax LCO value defaults to 162 "gateway". In ModifyConnection commands, the fax LCO value defaults 163 to its current value on the connection. Thus, if 164 LocalConnectionOptions are either omitted or the fax LCO is not 165 included in a ModifyConnection command, the previous fax LCO value 166 for the connection is retained, but without affecting the outcome of 167 the command; consequently, the gateway may now not apply any special 168 procedure to fax. If the Call Agent wants to ensure that a command 169 succeeds only when a fax procedure is applied, the command needs to 170 include the fax LCO explicitly. 172 As an example of this, assume that the CreateConnection command 173 successfully specified the use of "T.38 Strict", and a 174 ModifyConnection command is now received without the fax LCO, 175 but with a RemoteConnectionDescriptor indicating no support for 176 T.38; in that case, the ModifyConnection command will succeed, 177 however T.38 procedures will no longer be invoked upon fax 178 detection (a "nopfax" event will be generated). Had the Call 179 Agent instead included the fax LCO set to "T.38 Strict", the 180 command would have failed. 182 If multiple fax parameter values are provided, the gateway MUST 183 choose one of the procedures specified according to the order in 184 which they are supplied, except as follows: 186 1. If "gateway" would have been selected and it would have resulted 187 in no special procedure being applied, and 188 2. there are procedures other than "off" which are specified after 189 "gateway" (e.g., "t38") 191 then the gateway MUST use the most preferred of those subsequent 192 procedures that can be supported. If none of those subsequent 193 procedures can be supported, the gateway reverts to not invoking any 194 special procedure for fax. Please refer to Section 2.1.4 for 195 further details on determining which procedures can be supported. 197 The fax LCO parameter is encoded as the keyword "fx" (prefixed with 198 the package name per [RFC3435]), followed by a colon and a semicolon 199 separated list of values where T.38 Strict is encoded as "t38", T.38 200 Loose is encoded as "t38-loose", gateway is encoded as "gw", and off 201 is encoded as "off". 203 The following example illustrates the use of PCMU or G.729 for audio 204 encoding and T.38 Strict fax relay (preferred) or gateway control 205 for fax: 207 L: a:PCMU;G729, fxr/fx:t38;gw 209 It should be noted, that MGCP allows the CreateConnection command to 210 omit both LocalConnectionOptions and a RemoteConnectionDescriptor 211 thereby letting the gateway decide upon the media parameters to use. 212 When the T.38 fax package is supported, the gateway thus could 213 choose to do either audio or T.38 fax relay in such cases. Most 214 likely, the Call Agent requires one or the other to be used, and 215 hence it SHOULD NOT omit both LocalConnectionOptions and a 216 RemoteConnectionDescriptor in CreateConnection commands. 218 When auditing capabilities, the fax LCO may be returned with a semi- 219 colon separated list of supported fax handling parameters. The 220 values "t38", "t38-loose", "off" and "gw" MAY be omitted from such a 221 list as they are always implied. Gateways that implement additional 222 parameters SHOULD return these additional parameters when 223 capabilities are audited as illustrated by the following example: 225 A: a:image/t38, fxr/fx:mypar, ... 227 In the following subsections we provide additional detail on the 228 above defined fax procedures. 230 2.1.1 T.38 Procedure (Strict or Loose) 232 When a gateway is instructed to use one of the T.38 procedures 233 (strict or loose), also known as Call Agent controlled T.38 mode, 234 the "m=" line in the SDP returned will not indicate use of UDPTL- 235 based or TCP-based T.38 (unless the gateway was also instructed to 236 use "image/t38" for the media stream). Any other entity seeing this 237 SDP will not know whether T.38 is supported or not and hence whether 238 it is safe to attempt a switch to T.38 upon fax detection. To 239 remedy this dilemma, capability information for T.38 (if supported) 240 using the SDP Simple Capability Declaration extensions [RFC3407] 241 MUST be included. Other capability information is included as well, 242 regardless of whether the Call Agent authorized use of those in the 243 connection handling command or not. A subsequent attempt to 244 actually use these may of course not succeed, e.g., because the Call 245 Agent LCO does not allow them to be used. The following example 246 illustrates the RFC 3407 ([RFC3407]) capability descriptor - note 247 the inclusion of both current (audio) and latent (T.38) capabilities 248 as specified in RFC 3407 ([RFC3407]): 250 m=audio 3456 RTP/AVP 18 251 a=sqn: 0 252 a=cdsc: 1 audio RTP/AVP 18 253 a=cdsc: 2 image udptl t38 255 For a list of T.38 related parameters to be included in the SDP, 256 please refer to T.38 Annex D [T38]. 258 Upon fax detection, a gateway which has successfully been instructed 259 to use one of the T.38 procedures will: 261 1. Initiate the T.38 fax relay procedure and mute the media channel 262 in both the send and receive direction (unless the media channel 263 is already using T.38). 265 2. Generate a "t38(start)" event. 267 3. Await further instructions from the Call Agent in order to 268 initiate the actual media change (unless the media channel is 269 already using T.38). 271 The Call Agent instructs the gateway to perform the media change by 272 sending it a ModifyConnection command with "image/t38" listed as the 273 encoding method in the LocalConnectionOptions (receipt of a 274 ModifyConnection command without LocalConnectionOptions but with a 275 RemoteConnectionDescriptor containing an "m=" line with the MIME 276 type "image/t38" would achieve the same). Per the normal MGCP codec 277 negotiation procedures (see [RFC3435] Section 2.6), if a 278 RemoteConnectionDescriptor was included as well, it needs to include 279 an "m=" line with "image/t38" as an acceptable media format in order 280 for the command to succeed. The gateway may choose between the 281 UDPTL and TCP transport protocols at its own discretion subject to 282 the normal MGCP codec negotiation procedures (in practice, TCP-based 283 implementations are currently rare). 285 If a RemoteConnectionDescriptor was not included with the 286 ModifyConnection command sent to a gateway that initiated the T.38 287 procedure, it is possible (in fact likely), that the last received 288 RemoteConnectionDescriptor did not include an "m=" line listing 289 "image/t38" as an acceptable media format. In that case, the 290 endpoint cannot send T.38 media to the other side. The endpoint 291 MUST instead wait for an updated RemoteConnectionDescriptor with 292 "image/t38" as an acceptable media format and a supported transport 293 protocol (UDPTL or TCP). The T.38 fax procedure continues when an 294 acceptable RemoteConnectionDescriptor is received. An acceptable 295 RemoteConnectionDescriptor contains an "m=" line with the 296 "image/t38" MIME type (using the normal SDP syntax) and a supported 297 transport protocol (UDPTL or TCP). If the fax call fails, e.g., due 298 to a fax timeout, while either waiting for the Call Agent to 299 instruct the gateway to switch to "image/t38" or waiting for an 300 acceptable RemoteConnectionDescriptor, a "t38(stop)" or a 301 "t38(failure)" event MUST be generated. When the T.38 procedure 302 ends, a "t38(stop)" or "t38(failure)" event MUST be generated. 304 Finally, the Call Agent may need to abort a T.38 procedure that is 305 in progress. This can for example be done when the remote side was 306 unable to switch to T.38, and a fallback to fax passthrough using an 307 audio codec is attempted. The Call Agent instructs the endpoint to 308 abort an in-progress T.38 procedure by use of the "off" Fax LCO as 309 illustrated below: 311 L: fxr/fx:off 313 We now define "time t38init" as the point in time where the T.38 314 procedure was initiated, and "time t38abort" as the point in time 315 where the Call Agent aborts an in-progress T.38 procedure. If the 316 Call Agent at time t38abort instructs or enables the endpoint to 317 revert to one or more codecs that were in use just prior to time 318 t38init, the endpoint SHOULD use media stream parameters that mimic 319 the most recent LocalConnectionDescriptor issued before time 320 t38init. For example, IP-address and UDP port, payload formats used 321 and their payload type mapping, should all be the same as before 322 time t38init. This will enable the fallback to be as rapid as 323 possible. A LocalConnectionDescriptor is returned as usual, i.e., 324 only if one or more parameters changed since the last 325 LocalConnectionDescriptor issue (e.g. if a T.38 LCD was issued or a 326 transport address in the audio LCD was changed). 328 2.1.2 Gateway Procedure 330 A gateway using the gateway procedure, also known as Gateway 331 controlled mode, may initiate special fax handling upon detecting a 332 fax call. The details of this special fax handling are outside the 333 scope of this document. However, in order to use any special fax 334 handling, support for it MUST be negotiated with the other side by 335 passing and recognizing relevant parameters via the 336 LocalConnectionDescriptor and RemoteConnectionDescriptor. If the 337 other side has not indicated support for the special fax handling 338 desired, the gateway MUST NOT attempt to initiate it. When special 339 fax handling is initiated, a "gwfax(start)" event MUST be generated 340 thereby enabling the Call Agent to differ between the Call Agent and 341 gateway controlled mode while still being informed about the actual 342 change to fax. When the special gateway handling of fax ends, a 343 "gwfax(stop)" or "gwfax(failure)" event MUST be generated. 345 2.1.3 Off Procedure 346 A gateway using the "off" procedure will not invoke any special fax 347 procedures, e.g. T.38, when detecting a fax. However, the gateway 348 may still adjust local echo cancellation and/or switch to an 349 alternative codec as needed (in particular, this does not preclude 350 the use of RTP-based T.38). Also, a "nopfax(start)" event MUST be 351 generated; a corresponding "stop" event however will not. 353 Generating a "stop" event would imply that the gateway had to 354 infer when the fax call ends, which involves processing of the 355 media stream. However, when using the "off" mode, such processing 356 is not expected to occur. 358 2.1.4 Mode Operation 360 For each of the above modes, the RemoteConnectionDescriptor provides 361 information on what procedure(s) the other side supports. The 362 following rules are used to determine which procedure to use: 364 1. Whatever the Call Agent specified in the Fax 365 LocalConnectionOptions for the current command MUST be adhered 366 to. If the gateway cannot satisfy any of the options, the 367 command fails (error code 532 - unsupported value(s) in 368 LocalConnectionOptions is RECOMMENDED). 370 2. If both Fax LocalConnectionOptions and a 371 RemoteConnectionDescriptor are provided, the procedure selected 372 MUST be supported by both sides - this is currently only an issue 373 for "T.38 Strict". A procedure can be satisfied by the remote 374 side if: 376 * the relevant MIME media type, e.g. "image/t38", is included in 377 the "m=" line in the RemoteConnectionDescriptor, or 379 * the relevant MIME media type is included as a capability (see 380 [RFC3407]) in the RemoteConnectionDescriptor. 382 If the gateway cannot select any of the procedures in the Fax 383 LocalConnectionOptions, the command fails (error code 532 is 384 RECOMMENDED). Note that "T.38 Loose", "gateway", and "off" by 385 definition can always be supported by an implementation that 386 supports this package, irrespective of what the 387 RemoteConnectionDescriptor indicates. 389 3. If the Call Agent did not include any Fax LocalConnectionOptions 390 or a RemoteConnectionDescriptor with the command, the gateway 391 MUST continue using whichever procedure it is currently using. 393 4. If the Call Agent did not include any Fax LocalConnectionOptions, 394 but a RemoteConnectionDescriptor was included, the gateway MUST 395 follow rule 2 in selecting a procedure. In so doing, the default 396 Fax LocalConnectionOptions, i.e. "gateway" in CreateConnection, 397 or the current value in ModifyConnection, MUST be used. In the 398 case of ModifyConnection, the outcome of the command does not 399 depend on the gateway being able to select one of these "default" 400 procedures (as described in Section 2.1). Note that this is not 401 an issue for the CreateConnection command, since the default 402 value can always be supported by definition. 404 5. A previously received RemoteConnectionDescriptor does not affect 405 what procedure can be selected. Only a 406 RemoteConnectionDescriptor supplied with the current command 407 affects the procedure selection. However, in order to send media 408 of a given type (e.g. "image/t38"), the most recently received 409 RemoteConnectionDescriptor MUST include a corresponding media 410 line. 412 The following examples illustrate the use of the above rules: 414 Per rule 1, a gateway that only supports standard T.38 fax relay 415 will fail a command that only contains the fax option "mypar" 416 whereas it will succeed a command that contains, "t38-loose", "gw", 417 "off" or no Fax LCO. A command that only contained "t38", i.e. use 418 of T.38 in "strict" mode, may or may not succeed (depending on the 419 RemoteConnectionDescriptor). 421 A gateway supporting T.38 that receives a CreateConnection command 422 with the fax handling LCO set to "t38" and a 423 RemoteConnectionDescriptor with neither a T.38 capability nor a T.38 424 media stream will fail per rule 2. Had the fax handling LCO 425 included either "t38-loose", "gw" or "off", the command would have 426 succeeded and any of the procedures included could have been 427 selected. 429 Assume a gateway supporting T.38 has successfully executed a 430 CreateConnection command with fax handling set to "t38" (i.e. 431 strict). If the gateway now receives a ModifyConnection command 432 without a fax handling LCO but with a RemoteConnectionDescriptor 433 that has neither a T.38 capability nor a media stream with 434 "image/t38", the command will succeed (since rule 1 has no effect in 435 that case). However, per rule 2 and 4, there will not be any T.38 436 procedure in place. Had the Call Agent instead included a fax 437 handling LCO set to "t38" again, the command would have failed per 438 rule 2. 440 Finally, it should be noted that a switch to T.38 can be initiated 441 by either one or both of the originating and terminating gateways 442 and hence implementations MUST be prepared to handle this. This 443 includes the case where both sides initiate the switch, which for 444 example can occur when the originating fax generates Calling Tone 445 (CNG) and the terminating fax detects V.21 fax preamble (see [T30]) 446 before the switch to T.38 has been performed on the terminating 447 side. 449 2.1.5 Detecting a Fax Call 450 A fax call can be detected by several different means, e.g. V.21 fax 451 preamble, T.30 CNG tone, or V.8 signals, depending on the fax 452 transmission method being used. Implementations of this package MUST 453 at a minimum detect a fax call based on V.21 fax preamble. 455 Triggering based on T.30 CNG tone MAY be done; this is generally 456 considered acceptable for G3 and lower fax speeds. However, when 457 used with T.38 version 2 or earlier, it will impact V.34 high-speed 458 fax. The reason is, that T.38 version 2 (and earlier) does not 459 support the V.8 ANSam and CM signals used with V.34 fax, and hence 460 the V.34 faxes will downspeed to G3 (14.400 bps) or lower when using 461 T.38 version 2 (or earlier). Also, a few rare cases of modems 462 generating T.30 CNG tones for non-fax calls have been reported; such 463 modems would generate a false trigger for fax. As a consequence of 464 the above, it is RECOMMENDED that implementations of this package 465 which support T.30 CNG based fax detection provide a configuration 466 option to disable it for T.38 version 2 (or earlier). 468 2.1.6 Considerations for Which Procedures to Request 470 It is important to understand the implications of using any one of 471 the above defined procedures. Furthermore, multiple alternative 472 procedures can be requested, however not all combinations make 473 sense. In this section, we elaborate on both of these issues. 475 Use of the T.38 strict mode is ideal in an environment where it is 476 known, that other endpoints generate RFC 3407 ([RFC3407]) capability 477 descriptions with T.38 fax relay information. If a 478 RemoteConnectionDescriptor without T.38 fax relay capabilities is 479 received in such an environment, it is known that the other side 480 does not support T.38, and hence an unsuccessful attempt to switch 481 to T.38 (which in turn may lead to a failed fax call) can be 482 avoided. If it is not known whether other endpoints support the RFC 483 3407 ([RFC3407]) capability descriptors or not, the tradeoff is less 484 clear. The advantage is, that a switch to T.38 will only be 485 attempted if it is known that the other side supports it, however 486 endpoints that do not indicate support for T.38 may still support 487 it; T.38 however will not be used with these which in turn may lead 488 to unnecessary fax failures with low-bandwidth codecs or lossy 489 networks. 491 Use of the T.38 loose mode involves the same considerations as for 492 T.38 strict, however the pros and cons are reversed. If a peer 493 endpoint does not support T.38, the T.38 loose mode will still 494 attempt to switch to T.38 (and fail), which in turn may lead to a 495 failed fax call. On the other hand, if the peer endpoint does not 496 support the RFC 3407 ([RFC3407]) capability descriptors, but the 497 peer endpoint does in fact support T.38, T.38 would still be used 498 with this mode. 500 In summary, there is no single good answer to the use of either T.38 501 strict or T.38 loose mode; it depends on the capabilities of the 502 endpoints involved as well as the trade-off between potentially 503 letting fax calls fail due to lack of capability indications (where 504 T.38 otherwise is supported) versus potentially letting fax calls 505 fail due to an unsuccessful switch to T.38 (because T.38 in fact was 506 not supported). It should be noted, that Call Agents may have means 507 beyond RFC 3407 ([RFC3407]) capability descriptors to determine if a 508 peer endpoint supports T.38 or not. For example, when SIP is used 509 as the signaling protocol with other peers (e.g. Call Agents or 510 other SIP devices), the SIP OPTIONS method can be used to learn 511 whether T.38 is supported. Also, if the Call Agent allows use of 512 high-bandwidth codecs with redundancy when support for T.38 is not 513 indicated, fax calls may still succeed without the use of T.38, even 514 in networks with non-negligible packet loss. 516 When the gateway controlled mode is selected, there will only be 517 special fax handling if the two peer endpoints support the same fax 518 handling method; note that the details of the actual method is 519 entirely up to the vendor. Also note, that if the two peer 520 endpoints either do not support the same method for fax handling, or 521 the method is not indicated in the SDP exchanged, there will be no 522 special fax handling in place. Furthermore, the Call Agent will not 523 be aware that this is the case until the fax transmission starts and 524 a "nopfax(start)" event is generated. 526 The off mode is straightforward; there will be no special procedure 527 in place for fax handling, except for the usual handling of echo 528 cancellation and possibly a change to a higher bandwidth codec. 530 Having looked at the individual procedures in more detail, we now 531 elaborate on some of the combinations of procedures that may be 532 requested: 534 * T.38 strict: If the T.38 strict procedure is placed after 535 the T.38 loose or the off procedure (both of which can always be 536 supported), it will not be selected. Apart from this, it makes 537 little sense to request both T.38 strict and T.38 loose. 539 * T.38 loose: The T.38 loose procedure can always be 540 supported, so any procedure specified after T.38 loose will not be 541 selected. 543 * Gateway: The gateway controlled procedure can always be 544 supported. If the gateway controlled procedure would have 545 resulted in no special fax procedure and further options (except 546 off) are provided, those procedures will be attempted. If neither 547 of those procedures can be supported, there will be no special fax 548 procedure in place. 550 * Off: The off procedure can always be supported. Any 551 procedure specified after this one will not be selected. 553 2.2 Events and Signals 555 The following events are defined in support of the above: 557 ------------------------------------------------------------------ 558 | Symbol | Definition | R | S Duration | 559 |---------|----------------------------|-----|---------------------| 560 | gwfax | Gateway controlled fax | x | | 561 | nopfax | No special fax handling | x | | 562 | t38 | T.38 fax relay | x | | 563 ------------------------------------------------------------------ 565 The definitions of the individual events are provided in the 566 following subsections. 568 2.2.1 Gateway Controlled Fax (gwfax) 570 The "gateway controlled fax" event occurs when the gateway handled 571 fax procedure either starts, stops or fails. The event is encoded as 572 "gwfax" and the following event parameters, which apply to 573 ObservedEvents only, are defined: 575 * start: 576 Gateway controlled fax procedure was initiated. The Call Agent 577 SHOULD refrain from issuing media handling instructions to the 578 gateway until either a "gwfax(stop)" or "gwfax(failure)" event 579 is generated. 581 * stop: 582 Gateway controlled fax procedure ended and the gateway did not 583 detect any errors. Note that this does not necessarily imply a 584 successfully transmitted fax. It merely indicates that the 585 gateway controlled fax procedure has ended and the procedure 586 itself did not encounter any errors. Media parameters for the 587 connection are as before the gateway handled fax procedure 588 started. 590 * failure: 591 The gateway controlled fax procedure ended abnormally. Some 592 kind of problem was encountered in the gateway controlled fax 593 procedure and the procedure ended. Media parameters are as 594 before the gateway handled fax procedure started. 596 One of the above parameters will be present when the event is 597 reported. The "gwfax" event MAY be parameterized with additional 598 parameters in ObservedEvents, however it is RECOMMENDED that one of 599 the above parameters is the first parameter supplied. Unknown 600 parameters MUST be ignored. 602 The following example illustrates the encoding of the "gwfax" 603 event: 605 O: fxr/gwfax(start) 606 O: fxr/gwfax(stop, foobar) 607 2.2.2 No Special Fax Handling (nopfax) 609 The "no special fax handling" event occurs when there is no special 610 fax handling procedure in place and a fax call is detected. This 611 can happen either due to no special fax handling procedure being 612 requested (including "off"), or negotiation leading to no special 613 fax handling procedure being possible. The event is encoded as 614 "nopfax" and the following event parameter, which applies to 615 ObservedEvents only, is defined: 617 * start: 618 No special fax handling procedure is in place, however a fax 619 call is now detected. The Call Agent may have to issue further 620 commands in order to ensure a successful fax call (e.g., switch 621 to another codec). 623 The above parameter will be present when the event is reported. The 624 "nopfax" event MAY be parameterized with additional parameters on 625 ObservedEvents, however it is RECOMMENDED that the above parameter 626 is the first parameter supplied. Unknown parameters MUST be 627 ignored. Note, that this event currently cannot be parameterized 628 with "stop" or "failure" as it only detects the beginning of a fax 629 call. 631 The following example illustrates the encoding of the "nopfax" 632 event: 634 O: fxr/nopfax(start) 636 2.2.3 T.38 Fax Relay (t38) 638 The "T.38 fax relay" event occurs when one of the T.38 fax relay 639 procedures (strict or loose) either starts, stops or fails. The 640 event is encoded as "t38" and the following event parameters, which 641 apply to ObservedEvents only, are defined: 643 * start: 644 A fax call was detected on the endpoint and the Call Agent 645 controlled T.38 fax relay procedure was initiated. The Call 646 Agent SHOULD modify each side of the connection to start using 647 the "image/t38" media format, unless they already do. Note that, 648 as long as use of the Call Agent controlled T.38 relay procedure 649 is in effect, the event will be generated upon fax call 650 detection irrespective of the current encoding method on any 651 connections on the endpoint (incl. "image/t38"). The T38(start) 652 event MUST be generated at most once by the endpoint per fax 653 call regardless of whether or not it is requested again in a 654 subsequent requested events list. 656 * stop: 657 Call Agent controlled T.38 fax relay procedure ended and the 658 gateway did not detect any errors. Note that this does not 659 necessarily imply a successfully transmitted fax. It merely 660 indicates that the Call Agent controlled T.38 fax relay 661 procedure has ended and the procedure itself did not encounter 662 any errors. The Call Agent may want to modify the media 663 parameters for each side of the connection. Note that, in 664 contrast to the gateway controlled fax procedure case, media 665 parameters such as codecs do not automatically revert to their 666 values before the start of the fax call; echo cancellation and 667 silence suppression however do per the procedures in [RFC3435] 668 Section 2.3.5. The "t38(stop)" event MUST NOT be generated 669 unless a corresponding "t38(start)" event for the fax call in 670 question was generated earlier. 672 * failure: 673 Call Agent controlled T.38 fax relay procedure ended 674 abnormally. Some kind of problem in the Call Agent controlled 675 T.38 fax relay procedure was encountered and the procedure 676 ended. The Call Agent may want to modify the media parameters 677 for each side of the connection. Note that, in contrast to the 678 gateway controlled fax procedure case, media parameters such as 679 codecs do not automatically revert to their state before the 680 start of the fax call; echo cancellation and silence suppression 681 however do per the procedures in [RFC3435] Section 2.3.5. The 682 "t38(failure)" event MUST NOT be generated unless a 683 corresponding "t38(start)" event for the fax call in question 684 was generated earlier. 686 One of the above parameters will be present when the event is 687 reported. The "t38" event MAY be parameterized with additional 688 parameters, however it is RECOMMENDED that one of the above 689 parameters is the first parameter supplied. Unknown parameters MUST 690 be ignored. 692 The following example illustrates the encoding of the "t38" event: 694 O: fxr/t38(start) 695 O: fxr/t38(stop, foobar) 697 2.3 Connection Parameters 699 The connection parameters for the connection, that measures packets 700 and octets sent and received, MUST include packets and octets for 701 fax handling as well. Interarrival jitter and average transmission 702 delay calculation however MAY not be performed while fax is in 703 progress, e.g., if T.38 is used. In such cases, the interarrival 704 jitter and average transmission delay calculations are simply 705 suspended until calculations can resume, e.g., by changing back to 706 an RTP-based media stream again. 708 In addition to these connection parameters, the fax package defines 709 the following connection parameters, which gateways MAY support: 711 Number of fax pages sent (PGS): 713 The cumulative number of fax pages sent by the endpoint for the 714 life of the connection. The parameter is encoded as "PGS" and the 715 value supplied is a string of up to nine decimal digits. 717 Number of fax pages received (PGR): 719 The cumulative number of fax pages received by the endpoint for 720 the life of the connection. The parameter is encoded as "PGR" and 721 the value supplied is a string of up to nine decimal digits. 723 The following example illustrates the use of these parameters: 725 P: FXR/PGS=3, FXR/PGR=0, PS=1245, OS=62345, ... 727 2.4 Negotiation of T.38 Parameters 729 T.38 Annex D defines a number of T.38 parameters that can be 730 negotiated in the SDP. Currently, T.38 does not specify procedures 731 for how each of these parameters is negotiated, and in particular 732 whether each side has to use the same value or not. In the absence 733 of that, it was considered to add such definitions and procedures 734 here. However, it is expected that T.38 will rectify the above, 735 which could lead to conflicting definitions and procedures. To avoid 736 that, we instead assume the existence of an offer/answer section for 737 T.38 where T.38 Annex D parameters are classified as either 738 declarative or negotiated, and we then provide guidelines for how to 739 map such definitions and procedures to the MGCP fax package defined 740 here. 742 MGCP does not specify use of the offer/answer model, but instead 743 operates with the concept of connection handling commands (e.g. 744 CreateConnection and ModifyConnection) that may include a 745 RemoteConnectionDescriptor (SDP) and in turn may generate a 746 LocalConnectionDescriptor (SDP) in their response. 748 When an MGCP endpoint receives a CreateConnection command without a 749 RemoteConnectionDescriptor, it should follow the corresponding T.38 750 procedures for generating an initial offer and return the resulting 751 SDP in its LocalConnectionDescriptor. 753 When an MGCP endpoint receives a CreateConnection command with a 754 RemoteConnectionDescriptor, it should follow the corresponding T.38 755 procedures for receiving an initial offer and generating an answer 756 to it. The resulting SDP is returned in the 757 LocalConnectionDescriptor. 759 When an MGCP endpoint receives a ModifyConnection command with a 760 RemoteConnectionDescriptor, it cannot determine whether this 761 corresponds to an answer to an initial offer or a new offer. This is 762 not an issue for declarative parameters since they can be specified 763 independently in either direction. Negotiated parameters however 764 require some consideration: 766 When an offerer receives an answer to a previous offer, the 767 negotiation has completed and the parameters negotiated can no 768 longer be changed with this offer/answer exchange. The negotiated 769 parameters may be subject to certain validation checks. Conversely, 770 when an answerer receives an offer, the negotiation is open and the 771 answerer may change some of the offered negotiated parameters. Since 772 the MGCP endpoint does not know which situation it is in, it can not 773 perform the "offerer" validation checks. Likewise, in order to 774 ensure that any required negotiation actually takes place, it needs 775 to process an incoming SDP as an offer. If the SDP in fact does 776 correspond to an offer then this is obviously correct behavior. If 777 the SDP however corresponds to an answer, and one or more negotiated 778 parameters did change, then this will result in a new SDP. The Call 779 Agent may or may not contain sufficient intelligence to determine 780 whether this new SDP needs to result in another offer/answer 781 exchange or not. 783 For example, if the initial offer (in response to a 784 CreateConnection without SDP) contained fax version 2, and the 785 answer (in response to a CreateConnection with SDP) contained fax 786 version 0, then the corresponding ModifyConnection command (with 787 SDP) will result in an updated SDP with fax version also set to 788 zero. If this was the only change in the updated SDP, a new 789 offer/answer exchange would not be needed. Note that this example 790 does not imply that it is generally considered a good idea for 791 Call Agents to parse SDP in order to determine whether new 792 offer/answer exchanges are needed or not. 794 Finally, a ModifyConnection without SDP that generates an SDP needs 795 to be considered. The SDP generated may either correspond to an 796 initial offer/answer exchange or a subsequent offer/answer exchange. 797 The endpoint should generate SDP as if it was part of a subsequent 798 offer/answer exchange. If the Call Agent does not desire such 799 semantics, it can simply create a new connection instead. 801 2.5 Implementation Considerations 803 2.5.1 Media IP Address and Port for T.38 805 When an endpoint is instructed to change to or from T.38 for a media 806 stream, it SHOULD continue using the same IP address and port as the 807 media stream is currently using, since this will minimize any 808 Quality of Service, Network Address Translator (NAT) and Firewall 809 interactions from the change. However, if an endpoint has a good 810 reason, it MAY choose not to follow this recommendation. 812 When an endpoint uses the same port for RTP audio and T.38 with 813 either UDPTL or TCP, packets of one type (e.g. T.38) may be received 814 while expecting packets of another type (RTP audio). Since there is 815 explicit signaling to indicate which type is expected at any given 816 point in time, this does not introduce any new problems. In other 817 words, the receiver does not operate as a demultiplexer with a need 818 to determine if a given packet received is an RTP audio packet or a 819 T.38 UDPTL/TCP packet. The receiver simply processes incoming 820 packets as usual. If T.38 packets are expected, then incoming 821 packets are validated against T.38, and if RTP audio packets are 822 expected, then incoming packets are validated against RTP. 824 2.5.2 Case Sensitivity 826 The IANA has registered the uppercase string "UDPTL" as the 827 transport protocol identifier to be used for UDP-based T.38. 828 However, the examples provided in Recommendation T.38 as well as 829 most (if not all) current implementations use the lowercase string 830 "udptl" instead. Implementations conforming to this package SHOULD 831 generate the lowercase string "udptl" and accept the lowercase, 832 uppercase, and mixed upper/lowercase strings as being equivalent. 834 The attribute "T38MaxBitRate" is incorrectly registered with IANA as 835 "T38maxBitRate" (lower-case "m"). In accordance with T.38 examples 836 and common implementation practice, the form "T38MaxBitRate" SHOULD 837 be generated by implementations conforming to this package. 839 In general, it is RECOMMENDED that implementations of this package 840 accept both lowercase, uppercase, and mixed upper/lowercase 841 encodings of all the T.38 attributes. 843 2.5.3 Boolean Indicator after T.38 Parameters 845 Some implementations incorrectly use a colon (':') followed by a 846 number (zero or one) after the attributes T38FaxFillBitRemoval, 847 T38FaxTranscodingMMR and T38FaxTranscodingJBIG. Implementations 848 that receive such erroneous encodings MAY interpret the value ":0" 849 as lack of support for the option and all other values as indicating 850 support of the option in question. 852 3. Call Flow Examples 854 In this section, we provide three example call flows. The first one 855 illustrates a T.38 fax call under Call Agent control on both the 856 originating and terminating side. The second one illustrates the 857 use of multiple and different options on the two sides. The third 858 one illustrates the interaction with a SIP endpoint. 860 3.1 Call Agent Controlled T.38 Strict 862 In this example, both sides are under strict T.38 Call Agent 863 control. We assume the originating and terminating Call Agents 864 communicate via the Session Initiation Protocol (SIP) [RFC3261]. 865 Furthermore, the originating fax machine does not generate CNG tone 866 which is typical of early (i.e. pre-1993) fax machines. 868 ------------------------------------------------------------------ 869 | #| GW-o | CA-o | CA-t | GW-t | 870 |==|===============|===============|===============|===============| 871 | 1| <-|CRCX | | | 872 | 2| 200(sdp-o)|-> | | | 873 | 3| | INVITE(sdp-o)|-> | | 874 | 4| | | CRCX(sdp-o)|-> | 875 | 5| | | <-|200 (sdp-t) | 876 | 6| | <-|200(sdp-t) | | 877 | 7| <-|MDCX(sdp-t) | | | 878 | 8| 200|-> | | | 879 |--|---------------|---------------|---------------|---------------| 880 | 9| | | | <- ANS/ | 881 | | | | | T.30 CED | 882 |10| | | | <- V.21 fax | 883 | | | | | preamble | 884 |11| | | <-|NTFY(t38 start)| 885 |12| | | 200|-> | 886 |13| | | MDCX(t38)|-> | 887 |14| | | <-|200(sdp-t2) | 888 |15| | <-|INVITE(sdp-t2) | | 889 |16| <-|MDCX(sdp-t2) | | | 890 |17| 200(sdp-o2)|-> | | | 891 |18| | 200(sdp-o2)|-> | | 892 |19| | | MDCX(sdp-o2)|-> | 893 |20| | | <-|200 | 894 |21| V.21 fax -> | | | | 895 | | preamble | | | | 896 |22|NTFY(t38 start)|-> | | | 897 |23| <-|200 | | | 898 |24| <-|RQNT(T38 event)| | | 899 |25| 200|-> | | | 900 |--|---------------|---------------|---------------|---------------| 901 |26| | | | (fax ends) | 902 |27| | | <-|NTFY(t38 stop) | 903 |28| | | 200|-> | 904 |29|NTFY(t38 stop) |-> | | | 905 |30| <-|200 | | | 906 ------------------------------------------------------------------ 908 Step 1: 910 The Call Agent issues a CreateConnection command to the gateway 911 instructing it to use PCMU media encoding and to use the strict Call 912 Agent controlled T.38 procedure. Consequently, the Call Agent asks 913 the gateway to notify it of the t38 event: 915 CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 916 C: 1 917 L: a:PCMU, fxr/fx:t38 918 M: recvonly 919 R: fxr/t38 920 X: 1 921 Step 2: 923 The gateway acknowledges the command and includes SDP with codec 924 information as well as RFC 3407 ([RFC3407]) capability information: 926 200 1000 OK 927 I:1 929 v=0 930 o=- 25678 753849 IN IP4 192.0.2.1 931 s=- 932 c=IN IP4 192.0.2.1 933 t=0 0 934 m=audio 3456 RTP/AVP 0 935 a=sqn: 0 936 a=cdsc: 1 audio RTP/AVP 0 18 937 a=cdsc: 3 image udptl t38 939 Step 3: 941 The originating Call Agent sends a SIP INVITE message with the SDP 942 to the terminating Call Agent. 944 Step 4: 946 The terminating Call Agent issues a CreateConnection command to the 947 terminating gateway instructing it to use PCMU media encoding and to 948 use the strict Call Agent controlled T.38 procedure. Consequently, 949 the Call Agent asks the gateway to notify it of the t38 event: 951 CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 952 C: 2 953 L: a:PCMU, fxr/fx:t38 954 M: sendrecv 955 R: fxr/t38 956 X: 20 958 v=0 959 o=- 25678 753849 IN IP4 192.0.2.1 960 s=- 961 c=IN IP4 192.0.2.1 962 t=0 0 963 m=audio 3456 RTP/AVP 0 964 a=sqn: 0 965 a=cdsc: 1 audio RTP/AVP 0 18 966 a=cdsc: 3 image udptl t38 968 Step 5: 970 The terminating gateway supports T.38, and the 971 RemoteConnectionDescriptor included indicates that the other side 972 supports T.38 as well, so the strict T.38 Call Agent controlled 973 procedure requested can be used. The terminating gateway sends back 974 a success response with its SDP which also includes capability 975 information: 977 200 2000 OK 978 I:2 980 v=0 981 o=- 25678 753849 IN IP4 192.0.2.2 982 s=- 983 c=IN IP4 192.0.2.2 984 t=0 0 985 m=audio 1296 RTP/AVP 0 986 a=sqn: 0 987 a=cdsc: 1 audio RTP/AVP 0 18 988 a=cdsc: 3 image udptl t38 990 Step 6: 992 The terminating Call Agent sends back a SIP 200 OK response to the 993 originating Call Agent, which in turn sends a SIP ACK (not shown). 995 Step 7: 997 The originating Call Agent in turns sends a ModifyConnection command 998 to the originating gateway: 1000 MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1001 C: 1 1002 I: 1 1003 M: sendrecv 1005 v=0 1006 o=- 25678 753849 IN IP4 192.0.2.2 1007 s=- 1008 c=IN IP4 192.0.2.2 1009 t=0 0 1010 m=audio 1296 RTP/AVP 0 1011 a=sqn: 0 1012 a=cdsc: 1 audio RTP/AVP 0 18 1013 a=cdsc: 3 image udptl t38 1015 The ModifyConnection command does not repeat the 1016 LocalConnectionOptions sent previously. As far as fax handling is 1017 concerned, the gateway therefore attempts to continue using the 1018 current fax handling procedure, i.e. strict Call Agent controlled 1019 T.38. Since the capability information indicates the other side 1020 supports T.38, the gateway will in fact be able to use the strict 1021 Call Agent controlled T.38 procedure. Had there not been any 1022 support for T.38 in the RemoteConnectionDescriptor, then this 1023 command would still have succeeded, however there would be no 1024 special fax handling procedure (since strict mode could not be 1025 supported). 1027 Step 8: 1029 The gateway acknowledges the command. At this point, a call is 1030 established using PCMU encoding, and if a fax call is detected, the 1031 Call Agent controlled T.38 procedure will be initiated. 1033 Step 9-11: 1035 A fax call now occurs. First, the T.30 CED tone (a.k.a. V.25 ANS) 1036 is sent which in this case is simply passed through the current PCMU 1037 encoding. Since both fax and modem calls can start with this 1038 sequence, it is not possible to determine that this is a fax call 1039 until step 10, where the V.21 fax preamble is detected. 1041 The gateway was instructed to apply the Call Agent controlled T.38 1042 procedure for fax calls, so it begins to mute audio, generates the 1043 "t38(start)" event, and notifies the Call Agent: 1045 NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1046 O: fxr/t38(start) 1047 X: 20 1049 Step 12: 1051 The Call Agent acknowledges the Notify command: 1053 200 2500 OK 1055 Step 13: 1057 The Call Agent then instructs the terminating gateway to change to 1058 using the "image/t38" MIME type instead: 1060 MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1061 C: 2 1062 I: 2 1063 L: a:image/t38 1064 R: fxr/t38 1065 X: 21 1067 Step 14: 1069 The gateway changes to T.38, and sends back a success response with 1070 updated SDP: 1072 200 2002 OK 1074 v=0 1075 o=- 25678 753850 IN IP4 192.0.2.2 1076 s=- 1077 c=IN IP4 192.0.2.2 1078 t=0 0 1079 m=image 1296 udptl t38 1080 a=sqn: 0 1081 a=cdsc: 1 audio RTP/AVP 0 18 1082 a=cdsc: 3 image udptl t38 1084 Note, that since the gateway's current RemoteConnectionDescriptor 1085 (as opposed to the LocalConnectionDescriptor returned here) does not 1086 list "image/t38" as a valid encoding method, the terminating gateway 1087 is still muting the media and is now waiting for an updated 1088 RemoteConnectionDescriptor with "image/t38". 1090 Step 15: 1092 The terminating Call Agent sends a re-INVITE to the originating Call 1093 Agent with the updated SDP. 1095 Step 16: 1097 The originating Call Agent then sends a ModifyConnection command to 1098 the originating gateway: 1100 MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1101 C: 1 1102 I: 1 1104 v=0 1105 o=- 25678 753850 IN IP4 192.0.2.2 1106 s=- 1107 c=IN IP4 192.0.2.2 1108 t=0 0 1109 m=image 1296 udptl t38 1110 a=sqn: 0 1111 a=cdsc: 1 audio RTP/AVP 0 18 1112 a=cdsc: 3 image udptl t38 1114 Step 17: 1116 The originating gateway changes to T.38 and sends back a success 1117 response with updated SDP: 1119 200 1003 OK 1121 v=0 1122 o=- 25678 753850 IN IP4 192.0.2.1 1123 s=- 1124 c=IN IP4 192.0.2.1 1125 t=0 0 1126 m=image 3456 udptl t38 1127 a=sqn: 0 1128 a=cdsc: 1 audio RTP/AVP 0 18 1129 a=cdsc: 3 image udptl t38 1131 Step 18: 1133 The originating Call Agent sends a SIP 200 OK response with the 1134 updated SDP to the terminating Call Agent, which in turn sends a SIP 1135 ACK (not shown). 1137 Step 19: 1139 The terminating Call Agent sends a ModifyConnection with the updated 1140 SDP to the terminating gateway: 1142 MDCX 2003 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1143 C: 2 1144 I: 2 1146 v=0 1147 o=- 25678 753850 IN IP4 192.0.2.1 1148 s=- 1149 c=IN IP4 192.0.2.1 1150 t=0 0 1151 m=image 3456 udptl t38 1152 a=sqn: 0 1153 a=cdsc: 1 audio RTP/AVP 0 18 1154 a=cdsc: 3 image udptl t38 1156 Step 20: 1158 The terminating gateway sends back a success response: 1160 200 2003 OK 1162 Since the terminating gateway now has a RemoteConnectionDescriptor 1163 with "image/t38" as valid media, it can start exchanging T.38 with 1164 the originating gateway. 1166 Step 21, 22: 1168 The originating endpoint detects V.21 fax preamble. Even though the 1169 endpoint is already using "image/t38" for media, it generates a 1170 "t38(start)" event and notifies the Call Agent. 1172 NTFY 3500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1173 O: fxr/t38(start) 1174 X: 1 1176 Step 23, 24: 1178 The Call Agent acknowledges the Notify command, then issues a new 1179 request for notification of the T38 event. 1181 200 3500 OK 1182 . 1183 RQNT 1004 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1184 R: fxr/t38 1185 X: 2 1186 Step 25: 1188 The gateway acknowledges the command. 1190 200 1004 OK 1192 Step 26, 27: 1194 When the fax ends, a "t38(stop)" event is generated by the 1195 terminating endpoint, which is notified to the Call Agent: 1197 NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1198 O: t38(stop) 1199 X: 21 1201 Step 28: 1203 The Call Agent acknowledges the Notify command: 1205 200 2501 OK 1207 Step 29: 1209 The originating endpoint also generates a "t38(stop)" event, which 1210 is notified to the Call Agent: 1212 NTFY 3502 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1213 O: t38(stop) 1214 X: 2 1216 Step 30: 1218 The Call Agent acknowledges the Notify command: 1220 200 3502 OK 1222 The fax call is now over. The Call Agent may now decide to change 1223 back to a voice codec, delete the connection, or something 1224 different. 1226 3.2 Multiple and Different Options 1228 In this example, the originating gateway is instructed to use the 1229 gateway procedure whereas the terminating gateway is given a choice 1230 between the gateway procedure and the strict t38 procedure. 1231 Furthermore, the originating fax machine is generating CNG tone. 1233 ------------------------------------------------------------------ 1234 | #| GW-o | CA-o | CA-t | GW-t | 1235 |==|===============|===============|===============|===============| 1236 | 1| <-|CRCX | | | 1237 | 2| 200(sdp-o)|-> | | | 1238 | 3| | INVITE(sdp-o)|-> | | 1239 | 4| | | CRCX(sdp-o)|-> | 1240 | 5| | | <-|200 (sdp-t) | 1241 | 6| | <-|200(sdp-t) | | 1242 | 7| <-|MDCX(sdp-t) | | | 1243 | 8| 200|-> | | | 1244 |--|---------------|---------------|---------------|---------------| 1245 | 9| CNG ->| | | | 1246 |10| | | |<- ANS/T.30 CED| 1247 |11| | | |<- V.21 fax | 1248 | | | | | preamble | 1249 |12| | | <-|NTFY(t38 start)| 1250 |13| | | 200|-> | 1251 |14| | | MDCX(t38)|-> | 1252 |15| | | <-|200(sdp-t2) | 1253 |16| | <-|INVITE(sdp-t2) | | 1254 |17| <-|MDCX(sdp-t2) | | | 1255 |18| 200(sdp-o2)|-> | | | 1256 |19| | 200(sdp-o2)|-> | | 1257 |20| | | MDCX(sdp-o2)|-> | 1258 |21| | | <-|200 | 1259 |--|---------------|---------------|---------------|---------------| 1260 |22| | | | (fax ends) | 1261 |23| | | <-|NTFY(t38 stop) | 1262 |24| | | 200|-> | 1263 ------------------------------------------------------------------ 1265 Step 1: 1267 The Call Agent issues a CreateConnection command to the gateway 1268 instructing it to use PCMU media encoding and to use the gateway 1269 procedure. Consequently, the Call Agent asks the gateway to notify 1270 it of the gwfax event: 1272 CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1273 C: 1 1274 L: a:PCMU, fxr/fx:gw 1275 M: recvonly 1276 R: fxr/gwfax 1277 X: 1 1279 Step 2: 1281 The gateway acknowledges the command and includes SDP with codec 1282 information as well as capability information: 1284 200 1000 OK 1285 I:1 1287 v=0 1288 o=- 25678 753849 IN IP4 192.0.2.1 1289 s=- 1290 c=IN IP4 192.0.2.1 1291 t=0 0 1292 m=audio 3456 RTP/AVP 0 1293 a=sqn: 0 1294 a=cdsc: 1 audio RTP/AVP 0 18 1295 a=cdsc: 3 image udptl t38 1296 a=X-FaxScheme: 123 1298 We assume the gateway supports some other fax scheme and it 1299 indicates this by including an attribute "X-FaxScheme: 123" 1301 Step 3: 1303 The originating Call Agent sends a SIP INVITE message with the SDP 1304 to the terminating Call Agent. 1306 Step 4: 1308 The terminating Call Agent issues a CreateConnection command to the 1309 terminating gateway instructing it to use PCMU media encoding and to 1310 use either the gateway procedure or the strict Call Agent controlled 1311 T.38 procedure. Consequently, the Call Agent asks the gateway to 1312 notify it of both the gwfax and t38 events: 1314 CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1315 C: 2 1316 L: a:PCMU, fxr/fx:gw;t38 1317 M: sendrecv 1318 R: fxr/t38, fxr/gwfax 1319 X: 20 1321 v=0 1322 o=- 25678 753849 IN IP4 192.0.2.1 1323 s=- 1324 c=IN IP4 192.0.2.1 1325 t=0 0 1326 m=audio 3456 RTP/AVP 0 1327 a=sqn: 0 1328 a=cdsc: 1 audio RTP/AVP 0 18 1329 a=cdsc: 3 image udptl t38 1330 a=X-FaxScheme: 123 1332 Step 5: 1334 The terminating gateway does not support any special gateway fax 1335 handling, however it does support T.38, and the 1336 RemoteConnectionDescriptor included indicates that the other side 1337 supports T.38 as well, so the strict T.38 Call Agent controlled 1338 procedure requested can be honored. The terminating gateway sends 1339 back a success response with its SDP which also includes capability 1340 information: 1342 200 2000 OK 1343 I:2 1345 v=0 1346 o=- 25678 753849 IN IP4 192.0.2.2 1347 s=- 1348 c=IN IP4 192.0.2.2 1349 t=0 0 1350 m=audio 1296 RTP/AVP 0 1351 a=sqn: 0 1352 a=cdsc: 1 audio RTP/AVP 0 18 1353 a=cdsc: 3 image udptl t38 1355 Step 6: 1357 The terminating Call Agent sends back a SIP 200 OK response to the 1358 originating Call Agent, which in turn sends a SIP ACK (not shown). 1360 Step 7: 1362 The originating Call Agent in turns sends a ModifyConnection command 1363 to the originating gateway: 1365 MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1366 C: 1 1367 I: 1 1368 M: sendrecv 1370 v=0 1371 o=- 25678 753849 IN IP4 192.0.2.2 1372 s=- 1373 c=IN IP4 192.0.2.2 1374 t=0 0 1375 m=audio 1296 RTP/AVP 0 1376 a=sqn: 0 1377 a=cdsc: 1 audio RTP/AVP 0 18 1378 a=cdsc: 3 image udptl t38 1380 The ModifyConnection command does not repeat the 1381 LocalConnectionOptions sent previously. As far as fax handling is 1382 concerned, the gateway therefore attempts to continue using the 1383 current fax handling, i.e. the gateway procedure. The SDP 1384 information returned however does not indicate support for the "X- 1385 FaxScheme: 123", and hence the originating gateway will not invoke 1386 any special fax handling procedure for this call. 1388 Step 8: 1390 The gateway acknowledges the command. At this point, a call is 1391 established using PCMU encoding and if a fax call is detected, no 1392 special fax handling procedure will occur. 1394 Step 9-12: 1396 First, a CNG tone is generated by the originating fax thereby 1397 indicating a fax call. If the gateway was using either of the T.38 1398 modes, or it had negotiated support for a special gateway handling 1399 procedure with the other side, a "t38(start)" or "gwfax(start)" 1400 event would now have been generated and the switch to T.38 (or 1401 special gateway handling) could start. However, since the 1402 negotiation with the terminating gateway resulted in the originating 1403 gateway not doing anything special for fax, no such event is 1404 generated. Instead, the "nopfax(start)" event is now generated, but 1405 since the Call Agent has not requested this event, it is not 1406 detected and hence not reported to the Call Agent. Consequently, 1407 the CNG tone is simply passed through the current PCMU encoding 1408 without the (originating) Call Agent being aware of the fax call. 1410 Subsequently, the T.30 CED tone (a.k.a. V.25 ANS) occurs which in 1411 this case is also simply passed through the current PCMU encoding. 1412 Since both fax and modem calls can start with this sequence, it is 1413 not possible to determine that this is a fax call until step 11, 1414 where the V.21 fax preamble is detected. 1416 The terminating gateway is using the Call Agent controlled T.38 1417 procedure for fax calls, so it begins to mute audio, generates the 1418 "t38(start)" event, and notifies the Call Agent: 1420 NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1421 O: fxr/t38(start) 1422 X: 20 1424 Step 13: 1426 The Call Agent acknowledges the Notify command: 1428 200 2500 OK 1430 Step 14: 1432 The Call Agent then instructs the terminating gateway to change to 1433 using the "image/t38" MIME type instead: 1435 MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1436 C: 2 1437 I: 2 1438 L: a:image/t38 1439 R: fxr/t38 1440 X: 21 1441 Step 15: 1443 The gateway changes to T.38, and sends back a success response with 1444 updated SDP: 1446 200 2002 OK 1448 v=0 1449 o=- 25678 753850 IN IP4 192.0.2.2 1450 s=- 1451 c=IN IP4 192.0.2.2 1452 t=0 0 1453 m=image 1296 udptl t38 1454 a=sqn: 0 1455 a=cdsc: 1 audio RTP/AVP 0 18 1456 a=cdsc: 3 image udptl t38 1458 Note, that since the terminating gateway's last received 1459 RemoteConnectionDescriptor (as opposed to the 1460 LocalConnectionDescriptor returned here) did not list "image/t38" as 1461 a valid encoding method, the terminating gateway is still muting the 1462 media and is now waiting for an updated RemoteConnectionDescriptor 1463 with "image/t38". 1465 Step 16: 1467 The terminating Call Agent sends a re-INVITE to the originating Call 1468 Agent with the updated SDP. 1470 Step 17: 1472 The originating Call Agent then sends a ModifyConnection command to 1473 the originating gateway: 1475 MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1476 C: 1 1477 I: 1 1479 v=0 1480 o=- 25678 753850 IN IP4 192.0.2.2 1481 s=- 1482 c=IN IP4 192.0.2.2 1483 t=0 0 1484 m=image 1296 udptl t38 1485 a=sqn: 0 1486 a=cdsc: 1 audio RTP/AVP 0 18 1487 a=cdsc: 3 image udptl t38 1489 Step 18: 1491 The originating gateway changes to T.38 and sends back a success 1492 response with updated SDP: 1494 200 1003 OK 1496 v=0 1497 o=- 25678 753850 IN IP4 192.0.2.1 1498 s=- 1499 c=IN IP4 192.0.2.1 1500 t=0 0 1501 m=image 3456 udptl t38 1502 a=sqn: 0 1503 a=cdsc: 1 audio RTP/AVP 0 18 1504 a=cdsc: 3 image udptl t38 1506 Step 19: 1508 The originating Call Agent sends a SIP 200 OK response with the 1509 updated SDP to the terminating Call Agent, which in turn sends a SIP 1510 ACK (not shown). 1512 Step 20: 1514 The terminating Call Agent sends a ModifyConnection with the updated 1515 SDP to the terminating gateway: 1517 MDCX 2003 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1518 C: 2 1519 I: 2 1521 v=0 1522 o=- 25678 753850 IN IP4 192.0.2.1 1523 s=- 1524 c=IN IP4 192.0.2.1 1525 t=0 0 1526 m=image 3456 udptl t38 1527 a=sqn: 0 1528 a=cdsc: 1 audio RTP/AVP 0 18 1529 a=cdsc: 3 image udptl t38 1531 Step 21: 1533 The terminating gateway sends back a success response: 1535 200 2003 OK 1537 Since the terminating gateway now has a RemoteConnectionDescriptor 1538 with "image/t38" as valid media, it can start exchanging T.38 with 1539 the originating gateway. 1541 Step 22, 23: 1543 When the fax ends, a "t38(stop)" event is generated, which is 1544 notified to the Call Agent: 1546 NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 1547 O: t38(stop) 1548 X: 21 1550 Step 24: 1552 The Call Agent acknowledges the Notify command: 1554 200 2501 OK 1556 The fax call is now over. The Call Agent may now decide to change 1557 back to a voice codec, delete the connection, or something 1558 different. 1560 3.3 Interaction with SIP Endpoints 1562 In this example, we show interaction with a SIP endpoint that does 1563 not support the RFC 3407 ([RFC3407]) capability descriptors. To 1564 accommodate such endpoints, the T.38 loose mode is being used (at 1565 the risk of initiating T.38 to an endpoint that does not support 1566 it). Once again, the originating fax does not generate CNG tone. 1568 ------------------------------------------------------------------ 1569 | #| GW-o | CA-o | SIP-UA-t | fax | 1570 |==|===============|===============|===============|===============| 1571 | 1| <-|CRCX | | | 1572 | 2| 200(sdp-o)|-> | | | 1573 | 3| | INVITE(sdp-o)|-> | | 1574 | 4| | <-|200(sdp-t) | | 1575 | 5| | ACK|-> | | 1576 | 6| <-|MDCX(sdp-t) | | | 1577 | 7| 200|-> | | | 1578 |--|---------------|---------------|---------------|---------------| 1579 | 8| | | | <- ANS/ | 1580 | | | | | T.30 CED | 1581 | 9| | | | <- V.21 fax | 1582 | | | | | preamble | 1583 |10| | <-|INVITE(sdp-t2) | | 1584 |11| <-|MDCX(sdp-t2) | | | 1585 |12| 200(sdp-o2)|-> | | | 1586 |13| | 200(sdp-o2)|-> | | 1587 |14| | <-|ACK | | 1588 |15| V.21 fax -> | | | | 1589 | | preamble | | | | 1590 |16|NTFY(t38 start)|-> | | | 1591 |17| <-|200 | | | 1592 |18| <-|RQNT(T38 event)| | | 1593 |19| 200|-> | | | 1594 |--|---------------|---------------|---------------|---------------| 1595 |20| | | | (fax ends) | 1596 |21| | <-|BYE | | 1597 |22| | 200|-> | | 1598 |23|NTFY(t38 stop) |-> | | | 1599 |24| <-|200 | | | 1600 ------------------------------------------------------------------ 1602 Step 1: 1604 The Call Agent issues a CreateConnection command to the gateway 1605 instructing it to use PCMU media encoding and to use the loose Call 1606 Agent controlled T.38 procedure. Consequently, the Call Agent asks 1607 the gateway to notify it of the t38 event: 1609 CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1610 C: 1 1611 L: a:PCMU, fxr/fx:t38-loose 1612 M: recvonly 1613 R: fxr/t38 1614 X: 1 1616 Step 2: 1618 The gateway acknowledges the command and includes SDP with codec 1619 information as well as RFC 3407 ([RFC3407]) capability information: 1621 200 1000 OK 1622 I:1 1624 v=0 1625 o=- 25678 753849 IN IP4 192.0.2.1 1626 s=- 1627 c=IN IP4 192.0.2.1 1628 t=0 0 1629 m=audio 3456 RTP/AVP 0 1630 a=sqn: 0 1631 a=cdsc: 1 audio RTP/AVP 0 18 1632 a=cdsc: 3 image udptl t38 1634 Step 3: 1636 The originating SIP User Agent sends a SIP INVITE message with the 1637 SDP to the terminating Call Agent (not all SIP details shown here): 1639 INVITE sip:bob@biloxi.example.com SIP/2.0 1640 ... 1641 Content-Type: application/sdp 1642 Content-Length: 167 1644 v=0 1645 o=- 25678 753849 IN IP4 192.0.2.1 1646 s=- 1647 c=IN IP4 192.0.2.1 1648 t=0 0 1649 m=audio 3456 RTP/AVP 0 1650 a=sqn: 0 1651 a=cdsc: 1 audio RTP/AVP 0 18 1652 a=cdsc: 3 image udptl t38 1654 Step 4: 1656 The terminating SIP User Agent sends back a SIP 200 OK response (not 1657 all SIP details shown) to the originating Call Agent: 1659 SIP/2.0 200 OK 1660 ... 1661 Content-Type: application/sdp 1662 Content-Length: 100 1664 v=0 1665 o=- 25678 753849 IN IP4 192.0.2.2 1666 s=- 1667 c=IN IP4 192.0.2.2 1668 t=0 0 1669 m=audio 1296 RTP/AVP 0 1671 Note that the terminating SIP User Agent does not use the RFC 3407 1672 ([RFC3407]) capability descriptor to indicate support for (or lack 1673 of support for) T.38. 1675 Step 5: 1677 The originating Call Agent receives the SIP 200 response and sends a 1678 SIP ACK message to the terminating SIP UA. 1680 Note that the Call Agent does not know whether the peer entity 1681 supports T.38 or not. In order to figure this out, the Call Agent 1682 could send a SIP OPTIONS request to the terminating SIP UA 1683 requesting it to return its capabilities (not shown). Note that 1684 this can of course be done towards any SIP peer, e.g. if the other 1685 side was a Call Agent speaking SIP it could be done there too. 1687 Step 6: 1689 The originating Call Agent in turns sends a ModifyConnection command 1690 to the originating gateway: 1692 MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1693 C: 1 1694 I: 1 1695 M: sendrecv 1697 v=0 1698 o=- 25678 753849 IN IP4 192.0.2.2 1699 s=- 1700 c=IN IP4 192.0.2.2 1701 t=0 0 1702 m=audio 1296 RTP/AVP 0 1704 The ModifyConnection command does not repeat the 1705 LocalConnectionOptions sent previously. As far as fax handling is 1706 concerned, the gateway therefore attempts to continue using the 1707 current fax handling procedure, i.e. loose Call Agent controlled 1708 T.38. The T.38 loose procedure can always be supported, and hence a 1709 switch to T.38 will be attempted if the originating gateway detects 1710 a fax call. 1712 Step 7: 1714 The gateway acknowledges the command. At this point, a call is 1715 established using PCMU encoding, and if a fax call is detected, the 1716 Call Agent controlled T.38 procedure will be initiated. 1718 Step 8-9: 1720 A fax call now occurs. First, the T.30 CED tone (a.k.a. V.25 ANS) 1721 is sent which in this case is simply passed through the current PCMU 1722 encoding. Since both fax and modem calls can start with this 1723 sequence, it is not possible to determine that this is a fax call 1724 until step 9, where the V.21 fax preamble is detected. 1726 Step 10: 1728 The terminating SIP UA in fact does support T.38, and upon detecting 1729 the fax call, it attempts to change to T.38. Consequently, it sends 1730 a re-INVITE to the originating Call Agent with an updated SDP 1731 indicating a switch to T.38. 1733 INVITE sip:ca@ca-o.whatever.net SIP/2.0 1734 ... 1735 Content-Type: application/sdp 1736 Content-Length: 100 1738 v=0 1739 o=- 25678 753850 IN IP4 192.0.2.2 1740 s=- 1741 c=IN IP4 192.0.2.2 1742 t=0 0 1743 m=image 1296 udptl t38 1745 Step 11: 1747 The originating Call Agent then sends a ModifyConnection command to 1748 the originating gateway: 1750 MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1751 C: 1 1752 I: 1 1754 v=0 1755 o=- 25678 753850 IN IP4 192.0.2.2 1756 s=- 1757 c=IN IP4 192.0.2.2 1758 t=0 0 1759 m=image 1296 udptl t38 1761 Step 12: 1763 The originating gateway changes to T.38 and sends back a success 1764 response with updated SDP: 1766 200 1003 OK 1768 v=0 1769 o=- 25678 753850 IN IP4 192.0.2.1 1770 s=- 1771 c=IN IP4 192.0.2.1 1772 t=0 0 1773 m=image 3456 udptl t38 1774 a=sqn: 0 1775 a=cdsc: 1 audio RTP/AVP 0 18 1776 a=cdsc: 3 image udptl t38 1778 Step 13: 1780 The originating Call Agent sends a SIP 200 OK response with the 1781 updated SDP to the terminating SIP User Agent: 1783 SIP/2.0 200 OK 1784 ... 1785 Content-Type: application/sdp 1786 Content-Length: 167 1788 v=0 1789 o=- 25678 753850 IN IP4 192.0.2.1 1790 s=- 1791 c=IN IP4 192.0.2.1 1792 t=0 0 1793 m=image 3456 udptl t38 1794 a=sqn: 0 1795 a=cdsc: 1 audio RTP/AVP 0 18 1796 a=cdsc: 3 image udptl t38 1798 Step 14: 1800 The terminating SIP User Agent receives the SIP 200 and sends a SIP 1801 ACK. 1803 Since the terminating SIP User Agent now has a 1804 RemoteConnectionDescriptor with "image/t38" as valid media, it can 1805 start exchanging T.38 with the originating gateway (and vice versa). 1807 Step 15, 16: 1809 The originating endpoint detects V.21 fax preamble. Even though the 1810 endpoint is already using "image/t38" for media, it generates a 1811 "t38(start)" event and notifies the Call Agent. 1813 NTFY 3500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1814 O: fxr/t38(start) 1815 X: 1 1817 Step 17, 18: 1819 The Call Agent acknowledges the Notify command and then issues a new 1820 request for notification of the T38 event. 1822 200 3500 OK 1823 . 1824 RQNT 1004 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1825 R: fxr/t38 1826 X: 2 1828 Step 19: 1830 The gateway acknowledges the command. 1832 200 1004 OK 1834 Step 20-22: 1836 When the fax ends, the terminating SIP UA decides to tear down the 1837 call and hence sends a SIP BYE message, which the Call Agent 1838 responds to with a SIP 200. 1840 Step 23: 1842 The originating endpoint also generates a "t38(stop)" event, which 1843 is notified to the Call Agent: 1845 NTFY 3502 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 1846 O: t38(stop) 1847 X: 2 1849 Step 24: 1851 The Call Agent acknowledges the Notify command: 1853 200 3502 OK 1855 The fax call is now over. The Call Agent may now decide to change 1856 back to a voice codec, delete the connection, or something 1857 different. 1859 4. Security Considerations 1861 The MGCP fax package itself is not known to introduce any new 1862 security concerns. However, implementers should note that T.38 1863 media is currently transported over UDP (UDPTL) or TCP in the clear 1864 and without any integrity protection. If for example security 1865 services are in place to protect RTP media streams, these will thus 1866 not be in effect for the T.38 media stream. If such lack of 1867 security is a concern, the fax LocalConnectionOptions allowing T.38 1868 in this package SHOULD NOT be used, i.e. the "off" (or a new secure 1869 extension) fax LocalConnectionOption should be used. 1871 5. IANA Considerations 1873 The IANA is hereby requested to register the following MGCP package: 1875 Package Title Name Version 1876 ------------- ---- ------- 1877 Fax FXR 0 1879 6. Summary of Changes 1881 Changes since -03: 1883 * Boiler plate updated per RFC 3978 and RFC 3979. 1885 * Clarified that Fax LCO values are ordered by preference with 1886 caveats around the "gateway" procedure (Section 2.1) . 1888 * Added cautionary note around omitting both LCOs and a 1889 RemoteConnectionDescriptor in CreateConnection (Section 2.1). 1891 * Added "t38-loose" to list of values that may be omitted when 1892 auditing capabilities (Section 2.1). 1894 * Upgraded use of RFC 3407 capability declarations to MUST (Section 1895 2.1.1) 1897 * Clarified that muting of media applies to both the send and 1898 receive direction (Section 2.1.1). 1900 * Clarified that timeouts may also occur while waiting for the call 1901 agent to switch to "image/t38" (Section 2.11). 1903 * Defined how a call agent can abort a T.38 procedure (Section 1904 2.1.1). 1906 * Added new Section 2.1.5 on detecting a fax call. 1908 * Added new Section 2.1.6 on considerations for which procedure to 1909 request. 1911 * Clarified when and how the T38(start), T38(stop), and T38(failure) 1912 events are generated (Section 2.2.3). 1914 * Added new Section 2.4 on Negotiation of T.38 Parameters. 1916 * Added new Implementation Considerations in Section 2.5. 1918 * Added new example call flow showing interaction with SIP endpoints 1919 (Section 3.3.) 1921 7. Normative References 1923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1924 Requirement Levels", BCP 14, RFC 2119, March 1997. 1926 [RFC3435] F. Andreasen, B. Foster, "Media Gateway Control 1927 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 1929 [T38] ITU-T Recommendation T.38, "Procedures for real-time 1930 Group 3 facsimile communication over IP networks", 03/2002. 1932 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) 1933 Simple Capability Declaration", RFC 3407, October 2002. 1935 8. Informative References 1937 [T30] ITU-T Recommendation T.30, "Procedures for document 1938 facsimile transmission in the general switched telephone network", 1939 07/03. 1941 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. 1942 Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: 1943 Session Initiation Protocol", RFC 3261, June 2002. 1945 9. Acknowledgements 1947 Several people have contributed to the development of the MGCP fax 1948 package. In particular, the author would like to thank Bill Foster, 1949 Paul Jones, Gary Kelly, Rajesh Kumar, Dave Horwitz, Hiroshi Tamura, 1950 Rob Thompson and the CableLabs PacketCable NCS focus team for their 1951 contributions. 1953 10. Author's Address 1955 Flemming Andreasen 1956 Cisco Systems 1957 499 Thornall Street, 8th Floor 1958 Edison, NJ 08837 1960 Email: fandreas@cisco.com 1962 David Hancock 1963 CableLabs 1964 858 Coal Creek Circle 1965 Louisville, CO 80027 1967 Email: d.hancock@cablelabs.com 1968 Full Copyright Statement 1970 Copyright (C) The IETF Trust (2008). 1972 This document is subject to the rights, licenses and restrictions 1973 contained in BCP 78, and except as set forth therein, the authors 1974 retain all their rights. 1976 This document and the information contained herein are provided on 1977 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1978 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1979 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1980 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1981 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1982 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1983 FOR A PARTICULAR PURPOSE. 1985 Disclaimer of validity 1987 The IETF takes no position regarding the validity or scope of any 1988 Intellectual Property Rights or other rights that might be claimed 1989 to pertain to the implementation or use of the technology described 1990 in this document or the extent to which any license under such 1991 rights might or might not be available; nor does it represent that 1992 it has made any independent effort to identify any such rights. 1993 Information on the procedures with respect to rights in RFC 1994 documents can be found in BCP 78 and BCP 79. 1996 Copies of IPR disclosures made to the IETF Secretariat and any 1997 assurances of licenses to be made available, or the result of an 1998 attempt made to obtain a general license or permission for the use 1999 of such proprietary rights by implementers or users of this 2000 specification can be obtained from the IETF on-line IPR repository 2001 at http://www.ietf.org/ipr. 2003 The IETF invites any interested party to bring to its attention any 2004 copyrights, patents or patent applications, or other proprietary 2005 rights that may cover technology that may be required to implement 2006 this standard. Please address the information to the IETF at 2007 ietf-ipr@ietf.org. 2009 Acknowledgment 2011 Funding for the RFC Editor function is currently provided by the 2012 Internet Society.