By Sarah Martinez · Published August 10, 2026 · 9 min read
Quick Answer: SIP fax is a fax sent over a SIP trunk or VoIP phone system instead of a copper phone line. SIP sets the call up like a voice call; the fax then crosses either as G.711 audio or, after a SIP re-INVITE, as T.38 data packets, and it fails when any hop in the path refuses that switch, compresses the audio or drops packets. To take fax off the trunk entirely, mFax Business ports your fax number for free and lets your team fax from the web, phone and desktop apps or by email.
Moving the phones to a SIP trunk tends to go smoothly until the first fax. The machine dials, the trunk connects, and somewhere between the handshake and page two the call drops, or the pages arrive streaked. That isn't bad luck: a SIP fax call usually has to switch from voice to fax after it connects, and every device in the path has to agree to the switch.
This guide follows a fax across a SIP trunk message by message, decodes the SIP responses that show which hop broke it, and lists the settings and provider questions that fix most failures. It also covers the other way out: keeping the fax number and taking fax off the trunk.
What Is SIP Fax?
SIP fax is any fax whose call is set up with the Session Initiation Protocol. SIP never carries the pages itself: RFC 3261 defines it as "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions." The fax travels in a separate media stream that SIP describes — and that SIP can swap for a different one mid-call.
So a SIP fax call has two layers, and the fax can ride the media layer in two ways:
| Layer | Protocol | What it carries in a fax call |
|---|---|---|
| Signaling | SIP, with SDP describing the media | INVITE to start the call, re-INVITE to switch to T.38, BYE to end it |
| Media as audio | RTP with the G.711 codec ("passthrough") | The fax machines' tones, sampled like a voice call |
| Media as data | T.38 over UDPTL | The handshake and the page data, demodulated into packets |
T.38 is the ITU-T recommendation for the data option: "Procedures for real-time Group 3 facsimile communication over IP networks." The ITU first approved it in June 1998 and added Annex D, which sets T.38 up through SIP, in 2000.
Three ways to fax over SIP
What speaks SIP depends on the equipment you fax with:
| Setup | What speaks SIP | What to check first |
|---|---|---|
| Fax machine + ATA | The analog telephone adapter; the fax machine plugs into the ATA's FXS port and hears an ordinary dial tone | T.38 and fax settings on the ATA — our VoIP fax gateway guide compares models |
| Multifunction printer with SIP fax | The printer registers to your PBX or SIP server itself | Whether it's licensed: Konica Minolta's IP fax (SIP) needs an option and a service representative's setup; Xerox's SIP Fax needs its Fax over IP kit |
| Fax server | The server is a SIP endpoint on your PBX or trunk | Channel licenses and where T.38 ends — see our fax server guide |
How Does a Fax Cross a SIP Trunk?
A SIP fax call is a voice call that turns into a fax call after it connects. A working T.38 call goes through five steps:
The INVITE looks like any phone call
The calling ATA, printer or server sends an INVITE whose SDP offers voice codecs: G.711, and often G.729 as well. Nothing in it says "fax". RFC 6913 puts it plainly: "fax calls are indistinguishable from voice calls at call initiation."
The two fax machines start talking as audio
Once the call is answered, the machines use the voice path: the caller's 1100 Hz calling tone (CNG), the answering machine's 2100 Hz answer tone (CED), then the 300 bit/s V.21 handshake in which they agree on speed and resolution.
A gateway hears the fax and sends a re-INVITE
A gateway that detects the handshake sends a re-INVITE replacing the audio stream with m=image … udptl t38. The IETF's call-flow draft for SIP fax, a 2003 informational draft that has since expired, recommends that the answering side do this, triggered by the V.21 handshake rather than the CED tone.
The other side accepts or refuses
A 200 OK and an ACK switch the media to T.38. A refusal — 488, 415 or 606 — leaves the call as it was: RFC 3261 says that after a failed re-INVITE "the session parameters MUST remain unchanged."
Pages cross, the receiver confirms, BYE ends it
Page data crosses as T.38 packets over UDPTL, each carrying redundant copies of earlier ones so a lost packet can be rebuilt. The receiving machine confirms every page, and a BYE ends the call.
In a SIP trace, the switch is easy to spot. The INVITE offers audio; the re-INVITE offers an image stream:
INVITE (the call starts as voice)
m=audio 16384 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
re-INVITE (the switch to T.38)
m=image 10000 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
Payload 0 is G.711 μ-law; 18 is G.729, a codec built for speech at 8 kbit/s. If the call settles on G.729 and the re-INVITE then fails, the fax is lost, because modem tones don't survive a speech codec. UDPTL, redundancy levels and T.38's firewall needs are covered in our T.38 protocol deep dive.
The sip.fax tag: telling the network a fax is coming
RFC 6913, published in 2013, lets a call announce itself as a fax. A fax-capable device registers with +sip.fax="t38" (or "passthrough") in its Contact header, and a caller adds Accept-Contact: *;+sip.fax="t38" to its INVITE. Proxies that implement SIP caller preferences can then route the call to a device that can take it.
It's a preference, not a guarantee. The RFC tells callers not to require the tag, because any element in the path that doesn't support the mechanism could fail the call. Either way, the fax itself is still negotiated the usual way once the call connects.
Why Does SIP Fax Fail? Read the SIP Response
Most SIP fax failures come down to one hop that can't do what the call asks of it, and the SIP trace usually shows which one. These are the responses that matter, with the meaning RFC 3261 gives each:
| SIP response | RFC 3261 meaning | What it means for the fax |
|---|---|---|
| 486 Busy Here | The callee "is currently not willing or able to take additional calls" | The fax line is busy; retry in a few minutes |
| 480 Temporarily Unavailable | The callee's system was reached, but the callee is unavailable | Nothing took the call; check the number |
| 488 Not Acceptable Here | Same as 606, but only for this resource: "the request may succeed elsewhere" | A device in the path refused the T.38 offer; the call stays on audio |
| 415 Unsupported Media Type | The message body is in a format the server doesn't support | The far end can't handle a T.38 offer at all |
| 606 Not Acceptable | Some aspect of the session description wasn't acceptable | The destination refused the T.38 session outright |
| 491 Request Pending | A re-INVITE arrived while another was pending ("glare") | Both sides tried to switch to T.38 at once |
| 408 Request Timeout | No response within a suitable time | In reply to a re-INVITE, it ends the call |
| 503 Service Unavailable | The server is overloaded or down for maintenance | The trunk or a carrier is out; retry or reroute |
488 or 415: a hop refused T.38
This is the classic SIP fax failure. The refusal can come from the far end, from your trunk provider or from your own PBX: anything the PBX puts in the media path — call recording, a conference bridge, codec transcoding — has to pass T.38 too, or the PBX answers the re-INVITE with 488 itself.
Because the session stays unchanged after a refusal, what happens next depends on the audio codec. On G.711 the fax carries on as passthrough audio and may get through on a clean network; on G.729 it fails. Find the device that sent the refusal (the response's Server header often names it), then enable T.38 there or force G.711 end to end for fax calls.
491: both sides tried to switch at once
When gateways at both ends hear the fax and send a re-INVITE at the same moment, each answers the other with 491 Request Pending. RFC 3261's back-off then waits a random 2.1 to 4 seconds on the side that placed the call, and up to 2 seconds on the other, before retrying — while the two fax machines are already handshaking. Configure one side to request the switch and the other to wait for it.
No answer to the re-INVITE: blocked at the edge
If a re-INVITE gets a 408 or no response at all, RFC 3261 has the sender end the call, so the fax drops mid-handshake. Look at your network's edge first: a router's SIP ALG can rewrite the SDP, and a firewall can pass SIP while blocking the new UDPTL port the re-INVITE asked for. On a Konica Minolta printer, for example, SIP defaults to port 5060 and T.38 media to port 10000, and both have to get through. A fax that fails behind one router and works behind another points here.
Connected, but the pages fail
A 200 OK to the re-INVITE means every hop agreed to T.38, not that every hop carries it well. Streaked pages, or a fax that dies on page two, point at packet loss on the way, at a provider that negotiates T.38 and then hands the call to a carrier that handles it differently, or at a fax device asking for more than the path supports. V.34 "Super G3" speeds, for instance, only arrived with the 2004 edition of T.38.
How to Make SIP Fax Work
Most fixes are settings on your side plus five questions for your provider. Start with the devices you control.
Settings for the fax device, ATA and PBX
- Cap the speed at 14,400 or 9,600 bit/s, and turn off V.34 (Super G3) unless your provider confirms V.34 over T.38 end to end.
- Keep ECM on. Error Correction Mode lets the receiving machine ask for damaged blocks again instead of printing them.
- Enable T.38 on the ATA or printer, with UDP redundancy, and let only one side start the switch.
- Allow only G.711 on fax ports, with no silence suppression or comfort noise. G.711 is what the fax falls back to when T.38 is refused.
- Keep fax extensions out of call recording, conferencing and transcoding.
- Turn off SIP ALG on the router, and open the UDPTL port range your devices use.
- Give SIP and media traffic priority (QoS) on the internet link.
- Test the way your office faxes: several destinations, multi-page documents, different times of day. One page to one number proves little.
Five questions for your SIP trunk provider
- Do you carry T.38 on your own network all the way to the phone network, or do you hand fax calls to another carrier?
- Which side sends the T.38 re-INVITE, and do you send T.38 offers in a re-INVITE or in an UPDATE?
- If T.38 is refused, do you fall back to G.711, and is G.711 ever transcoded on your network?
- Which T.38 version and maximum bit rate do you negotiate, and do you support ECM over T.38?
- Can you pull a SIP trace, with SDP, for a failed fax by number and time?
A vague answer is an answer too. For the codec side in more depth, our T.38 fax protocol guide compares T.38 with G.711 passthrough.
When Should You Take Fax Off the SIP Trunk?
Take fax off the trunk when your provider can't confirm T.38 end to end, when failures move between destinations and days, or when only a few people fax and nobody wants to own the ATA settings. There are three ways to run fax alongside SIP phones:
| Fax over your SIP trunk | A fax-only SIP trunk | Cloud fax (mFax Business) | |
|---|---|---|---|
| What you run | ATA or SIP printer, PBX, firewall rules, the trunk | ATA, SIP printer or fax server, plus a second trunk | Nothing on site: web, iPhone, Android, Mac and Windows apps, email |
| Who must handle T.38 | Every hop: devices, PBX, provider, carriers behind it | Your devices and the fax provider | No one on your side |
| Your fax number | Stays where it is | Ported to the fax provider, or a new one | Ported to mFax free, on a Business workspace |
| When a fax fails | A SIP trace from your provider | A SIP trace from the fax provider | The fax row names the reason; 24/7 support checks the carrier log |
| Price | Your trunk's rates | The fax provider's rates | From about $9/mo, build your own plan |
mFax Business is the third column. The workspace owner starts the move in Settings › Team fax line › Move it to mFax with the number (mFax checks with the carrier whether it can be released), the account details exactly as your current carrier prints them, a recent bill and a signed letter of authorization. Porting is free, and most transfers are done within 7 business days. Keep the trunk's fax service running until mFax emails you that the number is live; our fax number porting guide has the details.
Once the number is in mFax:
- The whole office sends from the team fax line, in the web app or the iPhone, Android, Mac and Windows apps, and incoming faxes land as PDFs in a shared Received list.
- Staff can fax from their inbox. They address a message to the number at
send.mfax.to(for example12125550147@send.mfax.to) and attach the document; the address they sign in with is already authorized. See our email-to-fax guide. - Software that faxed through a fax server can call the API: one REST request per fax, delivery reported by webhook, documented at developers.mfax.to and included with every Business plan.
- Every fax reports back. It shows In Progress while the pages cross, around 40 seconds a page, then Delivered once the receiving machine confirms every page, with a PDF receipt. If it doesn't go through, the row says why: Recipient busy, No fax tone, Declined, Transmission error.
- A signed BAA comes with every plan, for practices that fax patient records.
The fax still leaves as a phone call from a telecom carrier to the receiving machine, so recipients need nothing but a fax number. The trade-off is the printer's fax button: you scan to PDF at the printer, then send from the app or by email.
Keep the Number, Drop the Fax Trunk
mFax Business gives your office a team fax line, with your ported number or a new local one, plus email to fax, the API and a signed BAA, on web, mobile and desktop. Build your own plan from about $9/mo, and cancel anytime.
Just need to get one fax out while the trunk is being fixed? Open the mFax app, upload the PDF and send it in under 2 minutes, free for 7 days.