SIP Protocols & StandardsKnowledge baseGeneric SIP ยท ITU-T T.38 / RFC 3362

Understanding T.38 Fax over IP (FoIP) SIP Signaling Flows and SDP Negotiation

Overview

This guide explains the SIP signaling architecture and SDP offer/answer model used to establish T.38 Fax over IP (FoIP) sessions. You will learn how audio sessions transition to T.38 using SIP re-INVITEs, how T.38 SDP media attributes are structured, and how to handle fallback mechanisms when T.38 negotiation fails.

Illustration for Understanding T.38 Fax over IP (FoIP) SIP Signaling Flows and SDP Negotiation

Key takeaways

  • T.38 replaces RTP audio stream with a dedicated UDPTL or TCP image stream for reliable fax relay across IP networks.
  • Fax calls typically begin as standard G.711 voice calls until fax tone detection (CED or CNG) triggers a SIP re-INVITE.
  • The transition to T.38 is declared in SDP using the 'm=image <port> udptl t38' media line alongside T.38-specific 'a=T38Fax...' attributes.
  • Error correction parameters like Forward Error Correction (FEC) or Redundancy (a=T38FaxUdpEC) mitigate packet loss on IP networks.
  • If a endpoint responds with '488 Not Acceptable Here' to a T.38 re-INVITE, media gateways must gracefully fall back to G.711 pass-through or terminate the call.

Prerequisites

  • Understanding of basic SIP signaling (INVITE, 200 OK, ACK) and RFC 3261 principles.
  • Familiarity with the SIP Offer/Answer model and SDP structure (RFC 3264).
  • Fundamental knowledge of PSTN faxing concepts (T.30 protocol, CNG/CED tones).

Guide

  1. section #1

    Introduction to T.38 Fax over IP Architecture Traditional PSTN fax transmission relies on ITU-T T.30 modems exchanging analog tones over circuit-switched networks. When transmitting fax over IP networks, simple audio encoding (G.711 pass-through) frequently fails due to jitter, packet loss, and codec compression artifacts. ITU-T T.38 solves this issue by demodulating the T.30 signal at the originating VoIP gateway, converting the fax control and image data into digital Facsimile Packetizing Protocol (IFP) packets, transporting them across the IP network using UDPTL or TCP, and remodulating them back to T.30 analog signals at the receiving gateway.

  2. section #2

    Initial Voice Call Establishment (G.711 Phase) Most T.38 sessions do not originate as fax calls at the SIP level. Instead, the call originates as a standard audio call using G.711 (PCMU or PCMA). This allows human speech or automated auto-attendant prompts to run initially without committing network resources to fax relay. The calling gateway sends an INVITE with an SDP audio offer (m=audio 10000 RTP/AVP 0 8 101), and the receiving gateway answers with a 200 OK containing its matching audio capabilities. Media flows as bidirectional RTP audio until a fax signal is detected.

    sip
    INVITE sip:fax-receiver@example.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK776asdhds
    From: <sip:sender@example.com>;tag=12345
    To: <sip:fax-receiver@example.com>
    Call-ID: c3039485720@192.168.1.10
    CSeq: 1 INVITE
    Content-Type: application/sdp
    
    v=0
    o=FaxSender 1000 2000 IN IP4 192.168.1.10
    s=SIP Call
    c=IN IP4 192.168.1.10
    t=0 0
    m=audio 10000 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
  3. section #3

    Fax Tone Detection and SIP Re-INVITE Trigger Once the voice media path is open, the receiving fax machine sends a Call Electric Signal (CED) 2100 Hz tone, or the transmitting machine sends a Comfort Noise Generator (CNG) 1100 Hz tone. Upon detecting this tone, the receiving gateway initiates the transition to FoIP by generating an in-dialog SIP re-INVITE (or receiving a SIP UPDATE). This re-INVITE changes the session description from an audio media stream (m=audio) to an image media stream (m=image).

  4. section #4

    Deconstructing the T.38 SDP Attribute Offer The re-INVITE SDP replaces the RTP audio stream definition with m=image <port> udptl t38. Key SDP attributes govern the T.38 parameters: a=T38FaxVersion specifies the T.38 standard version (typically 0 or 3); a=T38FaxMaxBuffer sets maximum buffer capacity; a=T38FaxMaxDatagram specifies maximum packet size; a=T38FaxRateManagement dictates control flow (localTCF or transferredTCF); and a=T38FaxUdpEC declares error correction method (t38UDPRedundancy or t38UDPFEC).

    sip
    INVITE sip:sender@example.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK99823abc
    From: <sip:fax-receiver@example.com>;tag=abcde
    To: <sip:sender@example.com>;tag=12345
    Call-ID: c3039485720@192.168.1.10
    CSeq: 2 INVITE
    Content-Type: application/sdp
    
    v=0
    o=FaxReceiver 1000 2001 IN IP4 192.168.1.20
    s=T.38 Fax
    c=IN IP4 192.168.1.20
    t=0 0
    m=image 12000 udptl t38
    a=T38FaxVersion:0
    a=T38FaxMaxBuffer:1024
    a=T38FaxMaxDatagram:400
    a=T38FaxRateManagement:localTCF
    a=T38FaxUdpEC:t38UDPRedundancy
  5. section #5

    End-to-End T.38 SIP Call Flow Ladder Diagram The standard sequence involves four distinct phases: Audio setup, Tone detection & Re-INVITE, UDPTL Fax Transmission, and Call Disconnect. Below is a conceptual representation of the complete end-to-end flow between Originating Gateway (OGW) and Terminating Gateway (TGW).

    text
    OGW (Caller)                       TGW (Callee)
        |                                    |
        |-------- INVITE (Audio SDP) ------->|
        |<------- 200 OK (Audio SDP) --------|
        |-------------- ACK ---------------->|
        |                                    |
        |======== RTP Voice Stream ==========|
        |                                    |
        |           [CED Tone Detected]      |
        |<------- re-INVITE (T.38 SDP) ------|
        |-------- 200 OK (T.38 SDP) -------->|
        |<------------- ACK -----------------|
        |                                    |
        |======== UDPTL T.38 Stream =========|
        |        (Fax Pages Exchanged)       |
        |                                    |
        |<-------------- BYE ----------------|
        |--------------- 200 OK ------------>|
  6. section #6

    Handling T.38 Negotiation Failures and G.711 Fallback If the remote side or an intermediate Session Border Controller (SBC) does not support T.38, it will reject the re-INVITE with a 488 Not Acceptable Here or 606 Not Acceptable response. Upon receiving a 488, the requesting gateway must ACK the error response and send a new re-INVITE reverting the media session back to G.711 audio. To maximize the success of G.711 pass-through fallback, gateways must disable Voice Activity Detection (VAD/silence suppression), turn off echo cancellation, and lock the codec to G.711u or G.711a.

Further reading

  • ITU-T Recommendation T.38: Procedures for real-time Group 3 facsimile communication over IP networks
  • RFC 3362: Real-time Facsimile MIME Subtype Registration
  • RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)