RFC 5347
Media Gateway Control Protocol Fax Package
RFC 5347: Media Gateway Control Protocol Fax Package 🦋
Part 1 of 8 🎀
okay bestie, this is RFC 5347 📜 It's an Informational doc from October 2008, so it's giving "here's useful info," not "this is a standard." 💅 The authors are F. Andreasen from Cisco Systems and D. Hancock from CableLabs, and it comes from the Network Working Group. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo 📝
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract 💜
So this doc defines a Media Gateway Control Protocol (MGCP) package for supporting fax calls 📠 There are two ways a fax call can work. The first one uses ITU-T Recommendation T.38 for fax relay, and the Call Agent is in charge of it 🎀 The second one lets the gateway pick how to send the fax and handle the whole call on its own, with zero Call Agent involvement. Iconic, honestly 👑
Table of Contents 🌸
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Fax Package Definition ..........................................3
2.1. LocalConnectionOptions .....................................3
2.1.1. T.38 Procedure (Strict or Loose) ....................6
2.1.2. Gateway Procedure ...................................8
2.1.3. Off Procedure .......................................8
2.1.4. Mode Operation ......................................8
2.1.5. Detecting a Fax Call ...............................10
2.1.6. Considerations for Determining Which
Procedures to Request ..............................11
2.2. Events and Signals ........................................13
2.2.1. Gateway Controlled Fax (gwfax) .....................13
2.2.2. No Special Fax Handling (nopfax) ...................14
2.2.3. T.38 Fax Relay (t38) ...............................14
2.3. Connection Parameters .....................................15
2.4. Negotiation of T.38 Parameters ............................16
2.5. Implementation Considerations .............................18
2.5.1. Media IP Address and Port for T.38 .................18
2.5.2. Case Sensitivity ...................................18
2.5.3. Boolean Indicator After T.38 Parameters ............19
3. Call Flow Examples .............................................19
3.1. Call Agent Controlled T.38 Strict .........................20
3.2. Multiple and Different Options ............................29
3.3. Interaction with SIP Endpoints ............................37
4. Security Considerations ........................................44
5. IANA Considerations ............................................44
6. Normative References ...........................................44
7. Informative References .........................................451. Introduction ✨
This doc defines a Media Gateway Control Protocol (MGCP) [RFC3435] package that lets MGCP controlled gateways support fax calls 📠 Fax calls can be handled in two different ways. The first one uses ITU-T Recommendation T.38, over either UDP Transport Layer (UDPTL) or TCP (see [T38]), for fax relay under the control of the Call Agent. The second one lets the gateway decide on a fax transmission method and handle the details of the call without Call Agent involvement 🦋
The fax package definition is in Section 2. Then in Section 3 we get three call flow examples showing how to use it 🧚 Security considerations are in Section 4, and after that come the IANA considerations and references 💖
1.1. Conventions Used in This Document 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC-2119 [RFC2119]. These are the official "rules words" 🫶
2. Fax Package Definition 🎀
A package is defined for fax. The package defines new LocalConnectionOptions, events, and connection parameters, and the details are below 💅
- Package Name:
FXR - Package Version:
0
2.1. LocalConnectionOptions 🌸
okay so this part is the big one. A new Fax LocalConnectionOptions (LCO) parameter is defined for fax handling 💅 The Call Agent uses this fax LCO to tell the Media Gateway which fax handling procedure it wants. The fax LCO holds a list of wanted procedures ordered by preference, with the most wanted one first ✨ When the parameter is explicitly included in a command, the gateway MUST be able to use at least one of the listed procedures for the command to succeed. No pressure 😭 Right now the list can name one or more of these procedures (see Sections 2.1.1 to 2.1.4 for the deep dive on each):
- T.38 Strict: Use T.38 [T38] with either UDPTL or TCP for fax relay, and have the Call Agent control it. If the procedure can be used (see Section 2.1.1), a switch to T.38 procedures starts once fax is detected, and a
"t38(start)"event gets generated (see Section 2.2). This mode needs an indication of T.38 support from the remote side before it can be used, as described more in Section 2.1.1 🎀 - T.38 Loose: Identical to the T.38 Strict procedure, except the remote side doesn't have to indicate T.38 support for the procedure to be used 🦋
- Off: Don't invoke any special fax procedure, except for echo cancellation adjustment and possibly switching to another codec 🙈
- Gateway: Let the gateway control things and decide how to handle fax calls without Call Agent involvement. This includes the case where the gateway doesn't do anything special for fax, so by definition this procedure can always be supported 👑 If the gateway invokes a special procedure once it detects fax, it generates a
"gwfax(start)"event to tell the Call Agent (see Section 2.2). The Call Agent SHOULD then refrain from sending potentially conflicting commands to the gateway until the gateway ends its special fax handling procedure 🫶- A gateway that ends up not being able to invoke any special procedure for fax will generate a
"nopfax(start)"event (see Section 2.2) once it detects fax 💀
- A gateway that ends up not being able to invoke any special procedure for fax will generate a
The set of possible values (aka procedures) for the fax LCO can be extended 🌈 The prefix x-, which means an optional extension, and the prefix x+, which means a mandatory extension, are reserved for vendor-specific use ✨
In CreateConnection commands, the fax LCO value defaults to gateway. In ModifyConnection commands, the fax LCO value defaults to its current value on the connection. So if LocalConnectionOptions are left out, or the fax LCO isn't included in a ModifyConnection command, the previous fax LCO value for the connection is kept without changing the outcome of the command. That means the gateway may now not apply any special procedure to fax 😬 If the Call Agent wants a command to succeed only when a fax procedure is applied, the command needs to include the fax LCO explicitly 🔥
As an example, say the CreateConnection command successfully specified "T.38 Strict", and then a ModifyConnection command comes in without the fax LCO but with a RemoteConnectionDescriptor that doesn't support T.38. In this case the ModifyConnection command succeeds, but T.38 procedures won't be invoked when fax is detected (a "nopfax" event gets generated). If the Call Agent had instead included the fax LCO set to "T.38 Strict", the command would have failed 💔
If multiple fax parameter values are provided, the gateway MUST choose one of the procedures specified, following the order they were supplied in, except as follows:
- If
"gateway"would have been selected and it would have resulted in no special procedure being applied, and - if there are procedures other than
"off"specified after"gateway"(e.g.,"t38"),
then the gateway MUST use the most preferred of those subsequent procedures that can be supported. If none of those subsequent procedures can be supported, the gateway goes back to not invoking any special procedure for fax. For more on figuring out which procedures can be supported, check Section 2.1.4 🧚
The fax LCO parameter is encoded as the keyword fx (prefixed with the package name per [RFC3435]), followed by a colon and then a semicolon-separated list of values. T.38 Strict is encoded as t38, T.38 Loose is encoded as t38-loose, gateway is encoded as gw, and off is encoded as off 🍓 Here's an example where PCMU or G.729 is used for audio, and T.38 Strict fax relay (preferred) or gateway control is used for fax 🎀
L: a:PCMU;G729, fxr/fx:t38;gwIt's worth knowing that MGCP lets the CreateConnection command leave out both LocalConnectionOptions and RemoteConnectionDescriptor, which lets the gateway pick the media parameters itself 🤔 When the T.38 fax package is supported, the gateway could then choose to do either audio or T.38 fax relay in those cases. Most likely the Call Agent needs one or the other, so it SHOULD NOT leave out both LocalConnectionOptions and RemoteConnectionDescriptor in CreateConnection commands 🙅♀️
When auditing capabilities, the fax LCO may come back with a semicolon-separated list of supported fax handling parameters. The values "t38", "t38-loose", "off", and "gw" MAY be left out of such a list, because they're always implied 🧠 Gateways that implement additional parameters SHOULD return those extra parameters when capabilities are audited. Here's an example:
A: a:image/t38, fxr/fx:mypar, ...In the following subsections, we get into more detail on the fax procedures defined above 💜
2.1.1. T.38 Procedure (Strict or Loose) ✨
okay so when a gateway gets told to use one of the T.38 procedures (strict or loose), aka Call Agent controlled T.38 mode 🎀, the SDP it hands back has an m= line that does NOT say UDPTL or TCP T.38 (unless the gateway was also told to use image/t38 for the media stream) 💀. So anyone else looking at that SDP has no clue if T.38 is supported, and therefore no clue if it's safe to switch to T.38 when fax gets detected. The fix is giving everyone the T.38 capability info (if it's supported) using the SDP Simple Capability Declaration extensions [RFC3407], and that info MUST be included 🫶. Other capabilities get included too, even if the Call Agent didn't authorize them in the connection handling command. Trying to actually use them later might still fail, e.g., because the Call Agent's LCO doesn't allow them 🙈. Here's an example of the RFC 3407 [RFC3407] capability descriptor. Notice it has both the current (audio) and latent (T.38) capabilities, as specified in RFC 3407 [RFC3407] 👑:
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18
a=cdsc: 2 image udptl t38If you want the list of T.38 related parameters to put in the SDP, check T.38 Annex D [T38] 📚.
Now, when fax gets detected, a gateway that was successfully told to use one of the T.38 procedures will:
- Start the T.38 fax relay procedure and mute the media channel in both the send and receive direction (unless the media channel is already using T.38) 🔇.
- Generate a
t38(start)event 🚀. - Wait for more instructions from the Call Agent before making the actual media change (unless the media channel is already using T.38) ⏳.
The Call Agent tells the gateway to do the media change by sending it a ModifyConnection command with image/t38 listed as the encoding method in the LocalConnectionOptions. Receiving a ModifyConnection without LocalConnectionOptions, but with a RemoteConnectionDescriptor containing an m= line with the MIME type image/t38, gets you the same result 💅. Following the normal MGCP codec negotiation procedures (see [RFC3435] Section 2.6), if a RemoteConnectionDescriptor is included too, it needs an m= line with image/t38 as an acceptable media format for the command to succeed 🌸. The gateway can pick between the UDPTL and TCP transport protocols at its own discretion, as long as it follows those normal MGCP codec negotiation procedures. (Real talk, TCP-based implementations are currently rare in practice 🦋.)
If a RemoteConnectionDescriptor was NOT included with the ModifyConnection sent to a gateway that started the T.38 procedure, it's possible (honestly, likely) that the last RemoteConnectionDescriptor it got didn't have an m= line listing image/t38 as an acceptable media format. In that case the endpoint can't send T.38 media to the other side 😭. The endpoint MUST instead wait for an updated RemoteConnectionDescriptor that has image/t38 as an acceptable media format and a supported transport protocol (UDPTL or TCP) 🧚. The T.38 fax procedure picks back up once an acceptable RemoteConnectionDescriptor shows up. An acceptable RemoteConnectionDescriptor has an m= line with the image/t38 MIME type (using the normal SDP syntax) and a supported transport protocol (UDPTL or TCP) ✨. If the fax call fails while the gateway is waiting for either the Call Agent to switch it to image/t38 or for an acceptable RemoteConnectionDescriptor (e.g., because of a fax timeout), a t38(stop) or a t38(failure) event MUST be generated 💔. When the T.38 procedure ends, a t38(stop) or t38(failure) event MUST be generated too 🔥.
Last thing: the Call Agent might need to abort a T.38 procedure that's already going. This can happen, for example, when the remote side can't switch to T.38 and a fallback to fax passthrough using an audio codec gets attempted 🍓. The Call Agent aborts an in-progress T.38 procedure with the "off" fax LCO, like this:
L: fxr/fx:offNow let's name a couple of moments. "time t38init" is the point in time where the T.38 procedure got initiated, and "time t38abort" is the point in time where the Call Agent aborts an in-progress T.38 procedure 🕰️. If at time t38abort the Call Agent tells or enables the endpoint to go back to one or more codecs that were in use just before time t38init, the endpoint SHOULD use media stream parameters that copy the most recent LocalConnectionDescriptor issued before time t38init 🪞. For example, the IP address and UDP port, payload formats used and their payload type mapping should all be the same as before time t38init. That makes the fallback as rapid as possible ⚡. A LocalConnectionDescriptor is returned as usual, meaning only if one or more parameters changed since the last LocalConnectionDescriptor got issued (e.g., if a T.38 LCD was issued or a transport address in the audio LCD changed) 💜.
2.1.2. Gateway Procedure 🌈
A gateway using the gateway procedure, also called Gateway controlled mode, can start special fax handling when it detects a fax call 📠. The details of that special handling are outside the scope of this document 🙅♀️. BUT, to use any special fax handling at all, support for it MUST be negotiated with the other side by passing and recognizing the relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor (this includes using RTP-based T.38) 🤝. If the other side hasn't indicated support for the special fax handling the gateway wants, the gateway MUST NOT attempt to start it 🚫. When special fax handling starts, a gwfax(start) event MUST be generated. That lets the Call Agent tell apart Call Agent controlled and gateway controlled mode while still being told about the actual switch to fax 👀. When the special gateway handling of fax ends, a gwfax(stop) or gwfax(failure) event MUST be generated 🎬.
2.1.3. Off Procedure 🫥
A gateway using the "off" procedure won't invoke any special fax procedures (e.g., T.38) when it detects a fax 🙃. It can still adjust local echo cancellation and/or switch to an alternative codec as needed 🎧. Also, a nopfax(start) event MUST be generated, but a corresponding "stop" event won't be 🤷♀️.
Here's why: generating a "stop" event would mean the gateway had to figure out when the fax call ends, which means processing the media stream. In "off" mode, that kind of processing isn't expected to happen, so no "stop" event 🫠.
2.1.4. Mode Operation 🧠
For each of the modes above, the RemoteConnectionDescriptor tells you what procedure(s) the other side supports 💁♀️. These rules decide which procedure gets used:
- Whatever the Call Agent specified in the Fax
LocalConnectionOptionsfor the current command MUST be adhered to 📋. If the gateway can't satisfy any of the options, the command fails. Error code 532 (unsupported value(s) inLocalConnectionOptions) is RECOMMENDED 🙅♀️. - If both Fax
LocalConnectionOptionsand aRemoteConnectionDescriptorare provided, the procedure selected MUST be supported by both sides. This is currently only an issue for "T.38 Strict" 🧩. A procedure can be satisfied by the remote side if:- the relevant MIME media type, e.g.,
image/t38, is included in them=line in theRemoteConnectionDescriptor, or - the relevant MIME media type is included as a capability (see [RFC3407]) in the
RemoteConnectionDescriptor.
- the relevant MIME media type, e.g.,
If the gateway can't select any of the procedures in the Fax LocalConnectionOptions, the command fails (error code 532 is RECOMMENDED) 😬. Also note: "T.38 Loose", "gateway", and "off" are, by definition, always supportable by an implementation that supports this package, no matter what the RemoteConnectionDescriptor says 💖.
- If the Call Agent didn't include any Fax
LocalConnectionOptionsor aRemoteConnectionDescriptorwith the command, the gateway MUST continue using whichever procedure it's currently using 🔁. - If the Call Agent didn't include any Fax
LocalConnectionOptions, but aRemoteConnectionDescriptorwas included, the gateway MUST follow rule 2 when selecting a procedure. While doing that, the default FaxLocalConnectionOptions(i.e., "gateway" inCreateConnection, or the current value inModifyConnection) MUST be used. ForModifyConnection, the outcome of the command doesn't depend on the gateway being able to pick one of these "default" procedures (as described in Section 2.1) 🎯. This isn't an issue forCreateConnection, since the default value can always be supported by definition ✅. - A previously received
RemoteConnectionDescriptordoesn't affect which procedure can be selected. Only aRemoteConnectionDescriptorsupplied with the current command affects the procedure selection 🙅♀️. BUT, to send media of a given type (e.g.,image/t38), the most recently receivedRemoteConnectionDescriptorMUST include a corresponding media line 📡.
Okay, now the examples so the rules actually click 💅. Per rule 1, a gateway that only supports standard T.38 fax relay will fail a command that only contains the fax option "mypar", but it will succeed with a command that contains "t38-loose", "gw", "off", or no fax LCO. A command that only contained "t38" (i.e., T.38 in "strict" mode) may or may not succeed, depending on the RemoteConnectionDescriptor 🎲.
A gateway that supports T.38 and gets a CreateConnection command with the fax handling LCO set to "t38" and a RemoteConnectionDescriptor with neither a T.38 capability nor a T.38 media stream will fail per rule 2 💀. If the fax handling LCO had included "t38-loose", "gw", or "off" instead, the command would've succeeded, and any of the included procedures could've been selected 🌟.
Say a gateway supporting T.38 has successfully run a CreateConnection command with fax handling set to "t38" (i.e., strict). If that gateway then gets a ModifyConnection command without a fax handling LCO, but with a RemoteConnectionDescriptor that has neither a T.38 capability nor a media stream with image/t38, the command will succeed (because rule 1 has no effect there) 🫧. BUT per rules 2 and 4, there won't be any T.38 procedure in place 🙃. If the Call Agent had instead included a fax handling LCO set to "t38" again, the command would've failed per rule 2 ❌.
Finally, a switch to T.38 can be started by the originating gateway, the terminating gateway, or both 🔄. So implementations MUST be prepared to handle this. That includes the case where both sides start the switch, which can happen, for example, when the originating fax generates Calling Tone (CNG) and the terminating fax detects the V.21 fax preamble (see [T30]) before the switch to T.38 has happened on the terminating side 📞🫶.
2.1.5. Detecting a Fax Call ✨
okay so a fax call can get detected a few different ways (like the V.21 fax preamble, the T.30 CNG tone, or V.8 signals), and which one you use depends on the fax transmission method being used 📠. Implementations of this package MUST at a minimum detect a fax call based on the V.21 fax preamble. no exceptions bestie 🔥
Triggering off the T.30 CNG tone MAY be done, and it's generally considered acceptable for G3 and lower fax speeds 🌸. BUT when you use it with T.38 version 2 or earlier, it impacts V.34 high-speed fax 😭. Why? T.38 version 2 (and earlier) doesn't support the V.8 ANSam and CM signals that V.34 fax uses, so V.34 faxes will downspeed to G3 (14.400 bps) or lower when using T.38 version 2 (or earlier). Also, a few rare cases of modems generating T.30 CNG tones for non-fax calls have been reported, and those modems would cause a false trigger for fax 💀. So because of all that, it is RECOMMENDED that implementations of this package that support T.30 CNG-based fax detection provide a configuration option to disable it for T.38 version 2 (or earlier) 🎀.
2.1.6. Considerations for Determining Which Procedures to Request 💅
It's important to understand what each procedure implies 🧠. Multiple alternative procedures can be requested too, but not every combo makes sense, so we'll cover both issues here.
Use of the T.38 Strict mode is ideal in an environment where it's known that other endpoints generate RFC 3407 [RFC3407] capability descriptions with T.38 fax relay information. If a RemoteConnectionDescriptor without T.38 fax relay capabilities is received in that kind of environment, you know the other side doesn't support T.38, so you can avoid an unsuccessful switch to T.38 (which may lead to a failed fax call) ✨. If you don't know whether other endpoints support the RFC 3407 [RFC3407] capability descriptors, the trade-off is less clear. The upside: a switch to T.38 is only attempted if the other side is known to support it. The downside: endpoints that don't indicate T.38 support may still support it, but T.38 won't be used with them, which may lead to unnecessary fax failures with low-bandwidth codecs or lossy networks 😤.
Use of the T.38 loose mode has the same considerations as T.38 Strict, but the pros and cons are flipped 🔄. If a peer endpoint doesn't support T.38, the T.38 loose mode will still attempt to switch to T.38 (and fail), which may lead to a failed fax call. On the flip side, if the peer endpoint doesn't support the RFC 3407 [RFC3407] capability descriptors but does in fact support T.38, T.38 would still be used with this mode 🙌.
In summary, there's no single good answer for T.38 Strict or T.38 loose mode. It depends on the capabilities of the endpoints involved and on the trade-off between letting fax calls fail due to missing capability indications (where T.38 is otherwise supported) versus letting them fail due to an unsuccessful switch to T.38 (because T.38 in fact wasn't supported). It should be noted that Call Agents may have means beyond RFC 3407 [RFC3407] capability descriptors to determine whether a peer endpoint supports T.38. For example, when SIP is used as the signaling protocol with other peers (e.g., Call Agents or other SIP devices), the SIP OPTIONS method can be used to learn whether T.38 is supported. Also, if the Call Agent allows high-bandwidth codecs with redundancy when support for T.38 isn't indicated, fax calls may still succeed without T.38, even in networks with non-negligible packet loss 🌈.
When the gateway controlled mode is selected, there will only be special fax handling if the two peer endpoints support the same fax handling method. The details of that method are entirely up to the vendor 🏭. Also, if the two peer endpoints don't support the same method for fax handling, or the method isn't indicated in the SDP exchanged, there will be no special fax handling in place. Furthermore, the Call Agent won't be aware of this until the fax transmission starts and a "nopfax(start)" event is generated 👀.
The off mode is straightforward: there will be no special procedure in place for fax handling, except for the usual handling of echo cancellation and possibly a change to a higher bandwidth codec 😌.
Having looked at the individual procedures in more detail, here are some combinations you might request:
- T.38 strict: If the T.38 strict procedure is placed after the T.38 loose or the off procedure (both of which can always be supported), it will not be selected. Apart from this, it makes little sense to request both T.38 strict and T.38 loose.
- T.38 loose: The T.38 loose procedure can always be supported, so any procedure specified after T.38 loose will not be selected.
- Gateway: The gateway controlled procedure can always be supported. If the gateway controlled procedure would have resulted in no special fax procedure and further options (except off) are provided, those procedures will be attempted. If neither of those procedures can be supported, there will be no special fax procedure in place.
- Off: The off procedure can always be supported. Any procedure specified after this one will not be selected.
2.2. Events and Signals 🦋
The following events are defined in support of the above:
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| gwfax | Gateway controlled fax | x | |
| nopfax | No special fax handling | x | |
| t38 | T.38 fax relay | x | |
------------------------------------------------------------------The definitions of the individual events are provided in the following subsections.
2.2.1. Gateway Controlled Fax (gwfax) 💖
The "gateway controlled fax" event occurs when the gateway handled fax procedure either starts, stops, or fails. The event is encoded as gwfax, and the following event parameters, which apply to ObservedEvents only, are defined:
- start: Gateway controlled fax procedure was initiated. The Call Agent SHOULD refrain from issuing media handling instructions to the gateway until either a "gwfax(stop)" or "gwfax(failure)" event is generated.
- stop: Gateway controlled fax procedure ended and the gateway did not detect any errors. Note that this does not necessarily imply a successfully transmitted fax. It merely indicates that the gateway controlled fax procedure has ended and the procedure itself did not encounter any errors. Media parameters for the connection are as they were before the gateway handled fax procedure started.
- failure: The gateway controlled fax procedure ended abnormally. Some kind of problem was encountered in the gateway controlled fax procedure, and the procedure ended. Media parameters are as they were before the gateway handled fax procedure started.
One of the above parameters will be present when the event is reported. The gwfax event MAY be parameterized with additional parameters in ObservedEvents, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored.
The following example illustrates the encoding of the gwfax event:
O: fxr/gwfax(start)
O: fxr/gwfax(stop, foobar)2.2.2. No Special Fax Handling (nopfax) 🙈
The "no special fax handling" event occurs when there is no special fax handling procedure in place and a fax call is detected. This can happen either because no special fax handling procedure was requested (including "off") or because negotiation resulted in no special fax handling procedure being supported. The event is encoded as nopfax, and the following event parameter, which applies to ObservedEvents only, is defined:
- start: No special fax handling procedure is in place, however a fax call is now detected. The Call Agent may have to issue further commands in order to ensure a successful fax call (e.g., switch to another codec).
The above parameter will be present when the event is reported. The nopfax event MAY be parameterized with additional parameters on ObservedEvents, however it is RECOMMENDED that the above parameter is the first parameter supplied. Unknown parameters MUST be ignored. Note that this event currently cannot be parameterized with "stop" or "failure" as it only detects the beginning of a fax call.
The following example illustrates the encoding of the nopfax event:
O: fxr/nopfax(start)2.2.3. T.38 Fax Relay (t38) 📞
okay so the "T.38 fax relay" event pops off whenever one of the T.38 fax relay procedures (strict or loose) starts, stops, or fails 💅. It's encoded as t38, and these are the event parameters (they only apply to ObservedEvents, fyi 🫶):
- start: A fax call was detected on the endpoint and the Call Agent controlled T.38 fax relay procedure got kicked off 🔥. The Call Agent SHOULD modify each side of the connection to start using the
image/t38media format, unless they already do. Note that, as long as use of the Call Agent controlled T.38 relay procedure is in effect, the event will be generated upon fax call detection, irrespective of the current encoding method on any connections on the endpoint (incl.image/t38). Thet38(start)event MUST be generated at most once by the endpoint per fax call, regardless of whether or not it is requested again in a subsequent requested events list. 🎀 - stop: The Call Agent controlled T.38 fax relay procedure ended and the gateway did not detect any errors ✨. Note that this does not necessarily imply a successfully transmitted fax. It merely indicates that the Call Agent controlled T.38 fax relay procedure has ended and the procedure itself did not encounter any errors. The Call Agent may want to modify the media parameters for each side of the connection. Note that, in contrast to the gateway controlled fax procedure case, media parameters such as codecs do not automatically revert to their values before the start of the fax call; however, echo cancellation and silence suppression do per the procedures in [RFC3435] Section 2.3.5. The
t38(stop)event MUST NOT be generated unless a correspondingt38(start)event for the fax call in question was generated earlier. 🦋 - failure: The Call Agent controlled T.38 fax relay procedure ended abnormally 💀. Some kind of problem in the procedure was encountered, and it ended. The Call Agent may want to modify the media parameters for each side of the connection. Note that, in contrast to the gateway controlled fax procedure case, media parameters such as codecs do not automatically revert to their state before the start of the fax call; however, echo cancellation and silence suppression do per the procedures in [RFC3435] Section 2.3.5. The
t38(failure)event MUST NOT be generated unless a correspondingt38(start)event for the fax call in question was generated earlier. 🥲
One of the above parameters will be present when the event is reported. The t38 event MAY be parameterized with additional parameters, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored. 🧚
Here's how the t38 event gets encoded:
O: fxr/t38(start)
O: fxr/t38(stop, foobar)2.3. Connection Parameters
The connection parameters for the connection, the ones that measure packets and octets sent and received, MUST include packets and octets for fax handling as well. Interarrival jitter and average transmission delay calculation however MAY NOT be performed while fax is in progress, e.g., if T.38 is used. In those cases, the calculations are simply suspended until they can resume, e.g., by changing back to an RTP-based media stream. 🌸
In addition to these connection parameters, the fax package defines the following connection parameters, which gateways MAY support:
Number of fax pages sent (PGS): The cumulative number of fax pages sent by the endpoint for the life of the connection. The parameter is encoded as PGS, and the value supplied is a string of up to nine decimal digits. 📄
Number of fax pages received (PGR): The cumulative number of fax pages received by the endpoint for the life of the connection. The parameter is encoded as PGR, and the value supplied is a string of up to nine decimal digits. 📨
Example time:
P: FXR/PGS=3, FXR/PGR=0, PS=1245, OS=62345, ...2.4. Negotiation of T.38 Parameters
okay this section is a little bit of a plot twist 🙈. T.38 Annex D [T38] defines a bunch of T.38 parameters that can be negotiated in the SDP. Right now, T.38 doesn't specify procedures for how each of these parameters gets negotiated, or whether each side has to use the same value. So we considered adding those definitions and procedures here. BUT it's expected that T.38 will rectify the above, which could lead to conflicting definitions and procedures 😭. To avoid that, we instead assume the existence of an offer/answer [RFC3264] section for T.38, where the T.38 Annex D parameters are classified as either declarative or negotiated, and then we give guidelines for how to map those definitions and procedures to the MGCP fax package defined here. Iconic restraint, honestly 👑.
MGCP doesn't specify use of the offer/answer model. Instead, it works with the concept of connection handling commands (e.g., CreateConnection and ModifyConnection) that may include a RemoteConnectionDescriptor (SDP) and in turn may generate a LocalConnectionDescriptor (SDP) in their response. 🧩
When an MGCP endpoint receives a CreateConnection command without a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for generating an initial offer and return the resulting SDP in its LocalConnectionDescriptor.
When an MGCP endpoint receives a CreateConnection command with a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for receiving an initial offer and generating an answer to it. The resulting SDP is returned in the LocalConnectionDescriptor.
When an MGCP endpoint receives a ModifyConnection command with a RemoteConnectionDescriptor, it cannot determine whether this corresponds to an answer to an initial offer or to a new offer. This is not an issue for declarative parameters, since they can be specified independently in either direction. Negotiated parameters, however, need some consideration:
When an offerer receives an answer to a previous offer, the negotiation has completed, and the negotiated parameters can no longer be changed with this offer/answer exchange. The negotiated parameters may be subject to certain validation checks. Conversely, when an answerer receives an offer, the negotiation is open and the answerer may change some of the offered negotiated parameters. Since the MGCP endpoint doesn't know which situation it's in, it cannot perform the "offerer" validation checks. Likewise, in order to ensure that any required negotiation actually takes place, it needs to process an incoming SDP as an offer. If the SDP in fact does correspond to an offer, then this is obviously correct behavior. However, if the SDP corresponds to an answer, and one or more negotiated parameters did change, then this will result in a new SDP. The Call Agent may or may not contain sufficient intelligence to determine whether or not this new SDP needs to result in another offer/answer exchange. 🤔
For example, if the initial offer (in response to aCreateConnectionwithout SDP) contained fax version 2, and the answer (in response to aCreateConnectionwith SDP) contained fax version 0, then the correspondingModifyConnectioncommand (with SDP) will result in an updated SDP with fax version also set to zero. If this was the only change in the updated SDP, a new offer/answer exchange would not be needed. Note that this example does not imply that it is generally considered a good idea for Call Agents to parse SDP in order to determine whether or not new offer/answer exchanges are needed. 🙅♀️
Finally, a ModifyConnection without SDP that generates an SDP needs to be considered. The SDP generated may either correspond to an initial offer/answer exchange or a subsequent offer/answer exchange. 🫠
The endpoint should generate SDP as if it were part of a subsequent offer/answer exchange. If the Call Agent doesn't want those semantics, it can simply create a new connection instead. ✨
2.5. Implementation Considerations
2.5.1. Media IP Address and Port for T.38
When an endpoint is instructed to change to or from T.38 for a media stream, it SHOULD continue using the same IP address and port the media stream is currently using, since this will minimize any Quality of Service, Network Address Translator (NAT), and Firewall interactions from the change. However, if an endpoint has a good reason, it MAY choose not to follow this recommendation. 🛡️
When an endpoint uses the same port for RTP audio and T.38 with either UDPTL or TCP, packets of one type (e.g., T.38) may be received while expecting packets of another type (RTP audio). Since there is explicit signaling to indicate which type is expected at any given point in time, this doesn't introduce any new problems. In other words, the receiver doesn't operate as a demultiplexer with a need to determine if a given packet received is an RTP audio packet or a T.38 UDPTL/TCP packet. The receiver simply processes incoming packets as usual. If T.38 packets are expected, then incoming packets are validated against T.38, and if RTP audio packets are expected, then incoming packets are validated against RTP. 🎧
2.5.2. Case Sensitivity
IANA has registered the uppercase string UDPTL as the transport protocol identifier for UDP-based T.38. However, the examples in Recommendation T.38, as well as most (if not all) current implementations, use the lowercase string udptl instead. Implementations conforming to this package SHOULD generate the lowercase string udptl and accept the lowercase, uppercase, and mixed upper/lowercase strings as being equivalent. 🔤
The attribute T38MaxBitRate was once incorrectly registered with IANA as T38maxBitRate (lowercase "m"). In accordance with the T.38 examples and common implementation practice, the form T38MaxBitRate SHOULD be generated by implementations conforming to this package. 🧁
In general, it is RECOMMENDED that implementations of this package accept lowercase, uppercase, and mixed upper/lowercase encodings of all the T.38 attributes. 💜
2.5.3. Boolean Indicator After T.38 Parameters
Some implementations incorrectly use a colon (':') followed by a number (zero or one) after the attributes T38FaxFillBitRemoval, T38FaxTranscodingMMR, and T38FaxTranscodingJBIG. Implementations that receive such erroneous encodings MAY interpret the value :0 as lack of support for the option, and all other values as support for the option. 🙃
3. Call Flow Examples 🎬
In this section, we provide three example call flows. The first one illustrates a T.38 fax call under Call Agent control on both the originating and terminating side. The second one illustrates the use of multiple and different options on the two sides. The third one illustrates the interaction with a SIP endpoint. Let's gooo 🚀
3.1. Call Agent Controlled T.38 Strict 🎀
okay bestie, this one is giving full strict-mode drama 💅 Both sides are under strict T.38 Call Agent control, so the call agents are literally running the whole show. We assume the originating and terminating Call Agents talk to each other over the Session Initiation Protocol (SIP) [RFC3261]. Also, the originating fax machine does not make CNG tone, which is super typical of early fax machines (the pre-1993 ones) 📠✨
Here's the whole flow at a glance 👀
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | | <- ANS/ |
| | | | | T.30 CED |
|10| | | | <- V.21 fax |
| | | | | preamble |
|11| | | <-|NTFY(t38 start)|
|12| | | 200|-> |
|13| | | MDCX(t38)|-> |
|14| | | <-|200(sdp-t2) |
|15| | <-|INVITE(sdp-t2) | |
|16| <-|MDCX(sdp-t2) | | |
|17| 200(sdp-o2)|-> | | |
|18| | 200(sdp-o2)|-> | |
|19| | | MDCX(sdp-o2)|-> |
|20| | | <-|200 |
|21| V.21 fax -> | | | |
| | preamble | | | |
|22|NTFY(t38 start)|-> | | |
|23| <-|200 | | |
|24| <-|RQNT(T38 event)| | |
|25| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|26| | | | (fax ends) |
|27| | | <-|NTFY(t38 stop) |
|28| | | 200|-> |
|29|NTFY(t38 stop) |-> | | |
|30| <-|200 | | |
------------------------------------------------------------------Step 1: The Call Agent sends a CreateConnection command to the gateway ✨ It tells the gateway to use PCMU media encoding and to run the strict Call Agent controlled T.38 procedure. So the Call Agent asks the gateway to notify it of the "t38" event 🔔
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38
M: recvonly
R: fxr/t38
X: 1Step 2: The gateway acknowledges the command and includes SDP with codec info and RFC 3407 [RFC3407] capability info 🧚
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 3: The originating Call Agent sends a SIP INVITE with that SDP to the terminating Call Agent 📨
Step 4: The terminating Call Agent sends a CreateConnection command to the terminating gateway 💌 It also asks for PCMU media encoding and the strict Call Agent controlled T.38 procedure, so it asks the gateway to notify it of the "t38" event too 🔔
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:t38
M: sendrecv
R: fxr/t38
X: 20
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 5: The terminating gateway supports T.38 🙌 The RemoteConnectionDescriptor it got says the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure can be used. The gateway sends back a success response with its own SDP, which also has capability info 💖
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 6: The terminating Call Agent sends a SIP 200 OK back to the originating Call Agent, which then sends a SIP ACK (not shown) 🫶
Step 7: The originating Call Agent sends a ModifyConnection command to the originating gateway 🦋
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Heads up, this part is a little tricky 👀 The ModifyConnection command doesn't repeat the LocalConnectionOptions from before. So as far as fax handling goes, the gateway keeps using whatever fax handling procedure it already had, which is strict Call Agent controlled T.38. Since the capability info says the other side supports T.38, the gateway really can use the strict Call Agent controlled T.38 procedure. If the RemoteConnectionDescriptor had shown no T.38 support, this command would still succeed, but there'd be no special fax handling procedure at all, because strict mode couldn't be supported 🙈
Step 8: The gateway acknowledges the command 💅 Now a call is set up using PCMU encoding, and if a fax call gets detected, the Call Agent controlled T.38 procedure kicks in 🔥
Steps 9-11: Now the fax call happens 📠 The T.30 CED tone (a.k.a. V.25 ANS) gets sent, and in this case it just passes straight through the current PCMU encoding. The tricky part is that both fax and modem calls can start with this same sequence, so nobody can tell it's a fax call until step 10, when the V.21 fax preamble shows up 👀
Once the gateway knows the Call Agent wants the Call Agent controlled T.38 procedure for fax calls, it starts muting audio, generates the "t38(start)" event, and notifies the Call Agent 🔇
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: fxr/t38(start)
X: 20Step 12: The Call Agent acknowledges the Notify command ✅
200 2500 OKStep 13: The Call Agent tells the terminating gateway to use the "image/t38" MIME type instead 🌈
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21Step 14: The gateway switches over to T.38 and sends back a success response with updated SDP 🎉
200 2002 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Pay attention here 👑 The gateway's current RemoteConnectionDescriptor (not the LocalConnectionDescriptor returned just now) doesn't list "image/t38" as a valid encoding method yet. So the terminating gateway is still muting the media and is waiting for an updated RemoteConnectionDescriptor that includes "image/t38" 🙈
Step 15: The terminating Call Agent sends a re-INVITE with the updated SDP to the originating Call Agent 📨
Step 16: The originating Call Agent sends a ModifyConnection command to the originating gateway 🫶
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 17: The originating gateway switches to T.38 and sends back a success response with updated SDP 💖
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 18: The originating Call Agent sends a SIP 200 OK with the updated SDP to the terminating Call Agent, which then sends a SIP ACK (not shown) 🦋
Step 19: The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway ✨
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 20: The terminating gateway sends back a success response 🌸
200 2003 OKSince the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start swapping T.38 with the originating gateway 📠💜
Steps 21, 22: The originating endpoint detects the V.21 fax preamble 👀 Even though it's already using "image/t38" for media, it still generates a "t38(start)" event and notifies the Call Agent 🔔
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: fxr/t38(start)
X: 1Steps 23, 24: The Call Agent acknowledges the Notify command, then sends a new request for notification of the "t38" event 🙌
200 3500 OK
.
RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0
R: fxr/t38
X: 2Step 25: The gateway acknowledges the command 💅
200 1004 OKSteps 26, 27: When the fax ends, the terminating endpoint generates a "t38(stop)" event, and that gets notified to the Call Agent 🏁
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: t38(stop)
X: 21Step 28: The Call Agent acknowledges the Notify command ✅
200 2501 OKStep 29: The originating endpoint also generates a "t38(stop)" event, which gets notified to the Call Agent 🌈
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: t38(stop)
X: 2Step 30: The Call Agent acknowledges the Notify command 🎀
200 3502 OKAnd that's the whole fax call, done and dusted 🥳 The Call Agent can now switch back to a voice codec, delete the connection, or do something totally different, whatever it wants 💖
3.2. Multiple and Different Options 💅
okay so this one is the ultimate choice-your-own-adventure example 🎀 the originating gateway is told to use the gateway procedure, but the terminating gateway gets to pick between the gateway procedure and the strict t38 procedure. and the originating fax machine is blasting CNG tone the whole time 📠🔥
Here's the full call flow at a glance 🦋
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| CNG ->| | | |
|10| | | |<- ANS/T.30 CED|
|11| | | |<- V.21 fax |
| | | | | preamble |
|12| | | <-|NTFY(t38 start)|
|13| | | 200|-> |
|14| | | MDCX(t38)|-> |
|15| | | <-|200(sdp-t2) |
|16| | <-|INVITE(sdp-t2) | |
|17| <-|MDCX(sdp-t2) | | |
|18| 200(sdp-o2)|-> | | |
|19| | 200(sdp-o2)|-> | |
|20| | | MDCX(sdp-o2)|-> |
|21| | | <-|200 |
|--|---------------|---------------|---------------|---------------|
|22| | | | (fax ends) |
|23| | | <-|NTFY(t38 stop) |
|24| | | 200|-> |
------------------------------------------------------------------Step 1:
The Call Agent tells the gateway to use PCMU media encoding and to go with the gateway procedure. so the Call Agent also asks the gateway to notify it about the "gwfax" event 🫶
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:gw
M: recvonly
R: fxr/gwfax
X: 1Step 2:
the gateway acknowledges the command and sends back SDP with its codec info and capability info ✨
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123we're assuming the gateway supports some other fax scheme, and it shows that by including the attribute "X-FaxScheme: 123" 🧚
Step 3:
the originating Call Agent sends a SIP INVITE with the SDP over to the terminating Call Agent 💌
Step 4:
the terminating Call Agent tells the terminating gateway to use PCMU media encoding and to use either the gateway procedure OR the strict Call Agent controlled T.38 procedure. so it asks the gateway to notify it about both the "gwfax" and "t38" events 👑
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:gw;t38
M: sendrecv
R: fxr/t38, fxr/gwfax
X: 20
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123Step 5:
the terminating gateway doesn't support any special gateway fax handling, BUT it does support T.38, and the RemoteConnectionDescriptor it got shows the other side supports T.38 too. so the strict T.38 Call Agent controlled procedure that was requested can be honored 🦋 it sends back a success response with its SDP, which also has capability info:
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 6:
the terminating Call Agent sends a SIP 200 OK back to the originating Call Agent, which then sends a SIP ACK (not shown) 🎀
Step 7:
the originating Call Agent then sends a ModifyConnection command to the originating gateway 🌸
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38ngl this part is so sneaky 🙈 the ModifyConnection command does NOT repeat the LocalConnectionOptions that were sent before. so for fax handling, the gateway just tries to keep doing what it was already doing, which is the gateway procedure. BUT the SDP that comes back doesn't include "X-FaxScheme: 123", so the originating gateway won't invoke any special fax handling procedure for this call 💀
Step 8:
the gateway acknowledges the command. at this point, a call is established using PCMU encoding, and if a fax call is detected, no special fax handling procedure will happen 🫶
Steps 9-12:
the originating fax generates CNG tone, which tells everyone "hey, this is a fax call" 📠 if the gateway were using either of the T.38 modes, or if it had negotiated support for a special gateway handling procedure with the other side, a "t38(start)" or "gwfax(start)" event would have been generated right now, and the switch to T.38 (or special gateway handling) could start. BUT since the negotiation with the terminating gateway ended up with the originating gateway not doing anything special for fax, no such event is generated. instead, the "nopfax(start)" event is generated, but since the Call Agent never asked for that event, it isn't detected and isn't reported to the Call Agent. so the CNG tone just goes right through the current PCMU encoding, and the (originating) Call Agent has no clue there's a fax call happening 🙈
then the T.30 CED tone (a.k.a. V.25 ANS) shows up. in this case it also just passes straight through the current PCMU encoding 🌈 and here's the tricky part: both fax and modem calls can start with this exact sequence, so it's not possible to tell that it's a fax call until step 11, where the V.21 fax preamble gets detected ✨
over on the terminating side, the gateway is using the Call Agent controlled T.38 procedure for fax calls. so it starts muting audio, generates the "t38(start)" event, and notifies the Call Agent 🔥
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: fxr/t38(start)
X: 20Step 13:
the Call Agent acknowledges the Notify command 💖
200 2500 OKStep 14:
the Call Agent then tells the terminating gateway to use the "image/t38" MIME type instead 🧚
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21Step 15:
the gateway switches to T.38 and sends back a success response with updated SDP 🦋
200 2002 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38wait, this is important 👀 the terminating gateway's last RemoteConnectionDescriptor (not the LocalConnectionDescriptor returned here) did NOT list "image/t38" as a valid encoding method. so the terminating gateway is STILL muting the media and is waiting for an updated RemoteConnectionDescriptor with "image/t38" 🫠
Step 16:
the terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP 💌
Step 17:
the originating Call Agent sends a ModifyConnection command to the originating gateway 🌸
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 18:
the originating gateway switches to T.38 and sends back a success response with updated SDP 🎀
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 19:
the originating Call Agent sends a SIP 200 OK with the updated SDP to the terminating Call Agent, which then sends a SIP ACK (not shown) ✨
Step 20:
the terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway 🧚
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 21:
the terminating gateway sends back a success response 💖
200 2003 OKsince the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway. the T.38 era has officially begun 👑
Steps 22, 23:
when the fax ends, a "t38(stop)" event is generated and notified to the Call Agent 🏁
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: t38(stop)
X: 21Step 24:
the Call Agent acknowledges the Notify command 🫶
200 2501 OKand that's the fax call done and dusted 💅 the Call Agent can now decide to switch back to a voice codec, delete the connection, or do something totally different 🌈
3.3. Interaction with SIP Endpoints ✨
okay so this one is about a SIP endpoint that does not support the RFC 3407 [RFC3407] capability descriptors 😭 to handle that, the T.38 loose mode gets used, even though it means T.38 might get started toward an endpoint that can't actually do it 💀 also, the originating fax doesn't generate CNG tone here, just like before 🎀
------------------------------------------------------------------
| #| GW-o | CA-o | SIP-UA-t | fax |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | <-|200(sdp-t) | |
| 5| | ACK|-> | |
| 6| <-|MDCX(sdp-t) | | |
| 7| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 8| | | | <- ANS/ |
| | | | | T.30 CED |
| 9| | | | <- V.21 fax |
| | | | | preamble |
|10| | <-|INVITE(sdp-t2) | |
|11| <-|MDCX(sdp-t2) | | |
|12| 200(sdp-o2)|-> | | |
|13| | 200(sdp-o2)|-> | |
|14| | <-|ACK | |
|15| V.21 fax -> | | | |
| | preamble | | | |
|16|NTFY(t38 start)|-> | | |
|17| <-|200 | | |
|18| <-|RQNT(T38 event)| | |
|19| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|20| | | | (fax ends) |
|21| | <-|BYE | |
|22| | 200|-> | |
|23|NTFY(t38 stop) |-> | | |
|24| <-|200 | | |
------------------------------------------------------------------Step 1:
The Call Agent tells the gateway to CreateConnection, asking for PCMU media encoding and the loose Call Agent controlled T.38 procedure 🎀 so the Call Agent asks the gateway to notify it about the "t38" event:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38-loose
M: recvonly
R: fxr/t38
X: 1Step 2:
The gateway acknowledges the command and includes SDP with the codec info and the RFC 3407 [RFC3407] capability info 💖
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 3:
The originating SIP User Agent (UA) sends a SIP INVITE with the SDP over to the terminating Call Agent. (Not all of the SIP details are shown here, bestie 🧚)
INVITE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/sdp
Content-Length: 167
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 4:
The terminating SIP User Agent sends a SIP 200 OK response back to the originating Call Agent (again, not all SIP details shown) 🌸
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 100
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0Note that the terminating SIP User Agent does not use the RFC 3407 [RFC3407] capability descriptor to say whether it supports T.38, or doesn't 🙈
Step 5:
The originating Call Agent gets the SIP 200 response and sends a SIP ACK message to the terminating SIP UA 🦋
Note that the Call Agent doesn't know whether the peer supports T.38. To find out, the Call Agent could send a SIP OPTIONS request to the terminating SIP UA, asking it to return its capabilities (not shown). This can of course be done toward any SIP peer. For example, if the other side were a Call Agent speaking SIP, it could be done there too ✨
Step 6:
The originating Call Agent then sends a ModifyConnection command to the originating gateway 💅
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0The ModifyConnection command doesn't repeat the LocalConnectionOptions that were sent before. So as far as fax handling goes, the gateway keeps using the current fax handling procedure, which is loose Call Agent controlled T.38 💖 the T.38 loose procedure can always be supported, so if the originating gateway detects a fax call, it will try switching to T.38 🔥
Step 7:
The gateway acknowledges the command. Now a call is set up using PCMU encoding, and if a fax call gets detected, the Call Agent controlled T.38 procedure kicks off 🎀
Steps 8, 9:
A fax call happens now. The T.30 CED tone (also known as V.25 ANS) is sent. In this case it's just passed through the current PCMU encoding 🍓 both fax and modem calls can start with this same sequence, so it's not possible to tell it's a fax call until step 9, when the V.21 fax preamble gets detected 👀
Step 10:
The terminating SIP UA does support T.38, so when it detects the fax call, it tries to switch to T.38. So it sends a re-INVITE to the originating Call Agent, with updated SDP that shows the switch to T.38 🦋
INVITE sip:ca@ca-o.example.net SIP/2.0
...
Content-Type: application/sdp
Content-Length: 100
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38Step 11:
The originating Call Agent then sends a ModifyConnection command to the originating gateway 🧚
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38Step 12:
The originating gateway switches to T.38 and sends back a success response with updated SDP 🌈
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 13:
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating SIP User Agent 💜
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 167
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38Step 14:
The terminating SIP User Agent gets the SIP 200 and sends a SIP ACK 🫶
Now that the terminating SIP User Agent has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway, and the other way around too 🔥
Steps 15, 16:
The originating endpoint detects the V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it still generates a "t38(start)" event and notifies the Call Agent 😭
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: fxr/t38(start)
X: 1Steps 17, 18:
The Call Agent acknowledges the Notify command, then issues a new (piggybacked) request to be notified about the T38 event ✨
200 3500 OK
.
RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0
R: fxr/t38
X: 2Step 19:
The gateway acknowledges the command 🎀
200 1004 OKSteps 20-22:
When the fax ends, the terminating SIP UA decides to tear the call down, so it sends a SIP BYE message, and the Call Agent responds with a SIP 200 🌸
Step 23:
The originating endpoint also generates a "t38(stop)" event, which gets notified to the Call Agent 💀
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: t38(stop) X: 2Step 24:
The Call Agent acknowledges the Notify command 🦋
200 3502 OKAnd that's the fax call done, bestie 🎉 the Call Agent can now switch back to a voice codec, delete the connection, or do something totally different ✨
4. Security Considerations 🔐
Okay, real talk, this section is important 💀 The MGCP fax package itself isn't known to bring in any new security concerns. BUT implementers need to know that T.38 media currently travels over UDP (UDPTL) or TCP in the clear, with no integrity protection at all 😭 so if you've got security services protecting RTP media streams, those won't cover the T.38 media stream 🙈 if that lack of security is a concern for you, the fax LocalConnectionOptions that allow T.38 in this package SHOULD NOT be used. Instead, use the "off" fax LocalConnectionOption (or a new secure extension) 🛡️
This one is a big deal: the fax LocalConnectionOptions that allow T.38 in this package SHOULD NOT be used if the lack of security is a concern 🚨
5. IANA Considerations 🌷
IANA has registered the following MGCP package:
Package Title Name Version
------------- ---- -------
Fax FXR 06. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[T38] ITU-T Recommendation T.38, "Procedures for real-time Group
3 facsimile communication over IP networks", March 2002.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.7. Informative References 🧠
[T30] ITU-T Recommendation T.30, "Procedures for document
facsimile transmission in the general switched telephone
network", July 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.Acknowledgements 🫶
Lots of people helped build the MGCP fax package, and the author really wants to thank Bill Foster, Paul Jones, Gary Kelly, Rajesh Kumar, Dave Horwitz, Hiroshi Tamura, Rob Thompson, and the CableLabs PacketCable NCS focus team for their contributions 💖
Authors' Addresses 💌
Okay bestie, here are the people who wrote this one! 🫶 Flemming Andreasen is at Cisco Systems, and David Hancock is at CableLabs. Here are their addresses, exactly as written:
Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th Floor
Edison, NJ 08837
EMail: fandreas@cisco.com
David Hancock
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
EMail: d.hancock@cablelabs.comFull Copyright Statement 🎀
The copyright belongs to The IETF Trust (2008) 📜. This document is covered by the rights, licenses and restrictions in BCP 78. Outside of what BCP 78 says, the authors keep all their rights 💅.
The document and everything in it is shared "AS IS" 🧃. Here's the legal part, word for word, because it's important:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
The IETF doesn't take a side on whether any Intellectual Property Rights (IPR) or other rights that someone might claim over the tech in this document are valid, or how far they reach 🤷♀️. It also doesn't say whether licenses for those rights are available. And it hasn't tried to hunt down any of those rights itself ✨. If you want the rules about rights in RFC documents, check out BCP 78 and BCP 79 📚.
IPR disclosures made to the IETF Secretariat are a thing you can look up, along with any promises of licenses. The same goes for the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec 🔍. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🌸.
Last but not least, the IETF is always happy when someone tells it about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🙌. Send that info to the IETF at ietf-ipr@ietf.org 💜. Periodt 💅.
📦 where this page comes from
- ietf: rfc5347 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms