Summary

  • RFC 5347 defines an MGCP fax package in which omission is a policy decision, not empty syntax. A connection established under T.38 Strict can later accept a ModifyConnection whose remote description lacks T.38 when the fax option is omitted; the same update would fail if t38 were repeated explicitly.
  • Procedure selection and permission to send media run on different clocks. Only a RemoteConnectionDescriptor carried in the current command can support selection, while the most recently received descriptor must authorize the media actually sent. A capability advertisement is evidence of possibility, not permission to switch.
  • t38(stop) means the gateway detected no error in the T.38 procedure. It does not prove that a page arrived, that the remote application accepted it, or that a human received the document. Operators need separate receipts for command, policy, media authority, procedure lifecycle and business outcome.

A useful refusal can carry more truth than a green command

RFC 5347's sharpest example begins with a connection that has successfully selected T.38 Strict. The Call Agent then sends a ModifyConnection containing a RemoteConnectionDescriptor that does not support T.38. If the command omits the fax LocalConnectionOption, it succeeds. The existing fax-option value remains, but T.38 is no longer invoked; when fax is detected, the gateway reports nopfax(start).

If the Call Agent includes t38 in that same modification, the command fails. Error 532 is recommended when none of the explicitly requested procedures can be satisfied. The failure is not degraded service masquerading as correctness. It is the control plane refusing to claim a method the available evidence cannot authorize.

The distinction defeats a common operational shortcut. Teams often treat a successful configuration transaction as proof that every prior intent survived the update. In this case, success proves only that the connection-changing command was acceptable under omission semantics. It does not prove that the previously required fax procedure remains enforceable.

An audit therefore cannot reduce the change to transaction ID, response code and final connection state. It must retain whether the fax option was explicit, what the option list contained, which remote description accompanied the current command, which procedure was selected, and why alternatives were skipped. Without those fields, a dashboard turns intentional loss of enforcement into ordinary success.

Omission is an authority instruction

In CreateConnection, the fax LocalConnectionOption defaults to gateway. In ModifyConnection, omission retains the current value. Neither rule means that an omitted choice has the same force as an explicit request in the current transaction.

That separation is deliberate. An explicit option tells the endpoint that the requested procedure is a condition of accepting the command. If no listed procedure can be supported, the command fails. Omission permits the connection update to proceed without making satisfaction of the retained preference a success condition.

This is why “no change” is an unsafe summary. One field may retain its stored value while the evidence needed to invoke that value changes. The configuration record looks stable; the executable authority does not.

The pattern is broader than fax. Whenever a control protocol distinguishes an explicit assertion from an inherited or defaulted value, operators need to record presence as well as value. A database row saying fax=t38 cannot reconstruct whether the Call Agent made T.38 mandatory in the transaction that installed the new remote state.

The option list is not an ordinary preference list

RFC 5347 names four procedures. t38 asks for T.38 Strict under Call Agent control. t38-loose asks for the loose form. gw delegates method choice and handling details to the gateway. off requests no special fax procedure, apart from local adjustments such as disabling echo cancellation or changing codec.

A semicolon-separated list normally describes preference order, but the choices do not all behave like fallible candidates. t38-loose can always be supported, so anything after it is unreachable. off likewise terminates the search. A gateway choice can fall through to a later non-off procedure when the gateway-selected result would provide no special fax handling.

The syntax therefore resembles an ordered list while carrying procedure-specific control flow. A validator that merely checks that every token is known can accept a policy whose later alternatives will never execute. A user interface that rearranges the list visually can change behavior without changing any individual item.

The evidence ledger should preserve the submitted order, the first eligible procedure, the reason each earlier choice failed, any gateway fall-through, and the effective result. Storing only the final method erases whether the system honored a strict requirement, accepted a loose attempt, delegated control or intentionally did nothing special.

Selection and sending obey two different clocks

The RemoteConnectionDescriptor creates the article's most important temporal split. A previously received descriptor cannot determine which fax procedure is selectable for a new command. Only a descriptor carried in that current command participates in current selection.

Media permission uses a different reference point. Before sending T.38, the gateway must look to the most recently received RemoteConnectionDescriptor and find the corresponding image/t38 media line and an acceptable transport. The gateway may begin the procedure before that descriptor arrives, but it must not send T.38 packets until the latest remote state authorizes them. A timeout while waiting ends in stop or failure.

These rules are not contradictory. Selection answers, “What may this command establish?” Sending answers, “What may leave the interface now?” The relevant evidence can be different because a later signaling exchange can update the permission surface after the procedure was selected.

Operational systems commonly flatten both into a single “negotiated SDP” field. That destroys the sequence. A defensible trace needs the descriptor attached to each command, the latest accepted descriptor at each media transmission, the selected procedure, the wait interval and the event that ended the wait.

The split also explains why packet observation is not a substitute for signaling evidence. When one address and port are reused for RTP audio and T.38 at different times, explicit signaling says which media type is expected. The receiver validates against that expected format; it is not supposed to infer the type by inspecting arbitrary packets as a demultiplexer.

Capability is not permission

An SDP capability declaration can advertise current and latent abilities. In Call Agent controlled mode, it can reveal that an endpoint knows T.38 even when the Call Agent has not authorized a switch in the command. Treating the advertisement as permission would allow the gateway to promote possibility into authority.

The reverse inference is unsafe too. A peer may support T.38 but fail to advertise it through the expected capability mechanism. Strict mode then produces a false negative: it refuses a call whose peer might in fact handle T.38. Loose mode accepts missing capability evidence, but can produce the opposite error by attempting a switch against a peer that truly lacks support.

RFC 5347 does not claim a universal answer. Strict and loose distribute uncertainty differently. Strict protects against unsupported attempts at the cost of rejecting some workable cases. Loose preserves more opportunities at the cost of trying some unsafe ones.

The policy question is therefore not “Does the endpoint support T.38?” as a timeless Boolean. It is “What evidence did the Call Agent have, which error class did it choose to tolerate, and did the current command authorize use?” Those questions belong in configuration review and incident telemetry.

Delegation delays knowledge

Gateway-controlled mode lets the gateway choose the method and manage its details without Call Agent involvement. That reduces central orchestration, but it does not guarantee that a special procedure exists. Both peers must support a common method and indicate it in exchanged SDP. Otherwise the gateway applies no special fax handling.

The Call Agent may not discover that absence when it submits the command. It may learn only when fax begins and the gateway emits nopfax(start). The green command was an accepted delegation, not a receipt for a selected fax method.

When a special gateway-controlled method does begin, gwfax(start) is the corresponding receipt. The Call Agent should avoid issuing conflicting commands until the method ends. Delegation therefore has two operational obligations: obtain evidence that delegated execution actually started, and honor a conflict-avoidance period while the delegate controls the procedure.

A configuration screen that says gw captures neither obligation. Useful observability records the delegated policy, exchanged capabilities, chosen method if disclosed, start time, blocked conflicting actions, stop or failure, and whether no special method was ultimately available.

A procedure event is not a delivery receipt

The event names can tempt dashboards into overstating results. t38(start) says fax was detected and the Call Agent controlled T.38 procedure began. t38(stop) says that procedure ended without an error detected by the gateway. RFC 5347 explicitly warns that stop does not necessarily mean a fax was successfully transmitted.

The gateway does not thereby attest to page count, remote application acceptance, document integrity, correct recipient or human receipt. t38(failure) means the procedure ended abnormally, but a clean stop and a failed business outcome can coexist.

The same boundary applies to gwfax(start|stop|failure). Those events describe the lifecycle of the gateway-controlled special procedure. nopfax(start) says fax was detected while no special fax procedure was in place; it has no stop form because off mode is not expected to infer the end of the fax from media.

An honest system keeps the event receipt and the document receipt separate. It can say that T.38 ran cleanly while leaving delivery unknown. Collapsing the two rewards infrastructure for claiming an outcome outside its observation boundary.

Detection is itself uncertain evidence

Implementations must at least detect fax from the V.21 preamble. Detection of the T.30 CNG calling tone is optional. The RFC records reports that modems produced CNG on non-fax calls, causing false fax triggers, and recommends a configuration option to disable CNG-based detection.

That warning matters because a false trigger can activate an expensive or disruptive media transition. A procedure can be correctly authorized, correctly started and correctly stopped in response to evidence that never represented a fax document.

Either endpoint, or both simultaneously, can initiate a T.38 switch. The protocol must handle that race. A trace needs the detector, signal, timestamp, endpoint role and simultaneous-initiation resolution, not just a Boolean saying fax was seen.

Detection confidence should remain distinct from method authorization. A strong signal does not give an endpoint permission to use a method the Call Agent withheld. Conversely, explicit authorization does not prove the detector was right.

Historical tolerance is not policy proof

RFC 5347 advises implementations to tolerate case variants around UDPTL and T.38 attributes and some historically erroneous Boolean encodings. This is an interoperability accommodation. It should not be repackaged as evidence that the parties negotiated the same policy or achieved successful delivery.

The document also permits connection counters to include fax packets and octets while allowing interarrival jitter and average transmission delay calculations to be suspended during fax, including T.38. A monitoring graph may therefore show a gap exactly while a critical media transition occurs.

Reusing the same address and port for RTP audio and T.38 can reduce QoS, NAT and firewall complications. It also increases the importance of preserving signaled state, because the five-tuple alone no longer identifies the expected medium.

These are examples of operational convenience changing the evidence surface. Tolerant parsing, suspended metrics and port reuse may all improve deployment. None should be allowed to weaken the distinction between what was accepted, what was authorized and what was observed.

The document's status bounds the claim

RFC 5347 was published in October 2008 as Informational. It defines a package and records implementation guidance, but it is not an Internet Standard. The RFC Editor errata search currently shows six reports held for document update. A production interpretation should consult those reports and preserve their status rather than silently rewriting the base text.

The document is most useful as a control-plane case study. It makes omission semantics unusually visible, names the strict-versus-loose trade-off, separates current-command selection from latest-state sending, and refuses to equate procedure completion with document delivery.

It does not prove that a contemporary platform implements these behaviors, that every fax deployment should choose the same mode, or that T.38 is required for successful fax. Any current implementation claim needs current vendor and deployment evidence.