GFI Support Home Start a conversation Sign in
Start a conversation
  1. GFI FaxMaker
  2. Articles
  3. Public Articles

Planned Fax Number Port/Cutover Preparedness (GFI FaxMaker + Brooktrout SR140 + SIP Trunk)

Table of Contents

Overview

This article is for planned production fax number ports/cutovers to a new on-premises GFI FaxMaker environment using Brooktrout SR140 with a SIP trunk provider, where production DIDs cannot be fully tested until the carrier port completes.

If faxing works with a provider-supplied test number, the priority is cutover preparedness and rapid triage readiness (pre-validating configuration and pre-staging diagnostics capture). No product defect has been identified.

Key Information

  • Error / symptom status
    • Error message: None reported (pre-cutover planning request).
    • Current state: Test faxing with the SIP provider’s test number works, but production DIDs cannot be validated until the port completes.
    • Primary risk window: the port/cutover window (for example, <port_date_time> <time_zone>), when carrier routing/provider-side variables may change.
  • Information to have ready before the cutover (to enable rapid triage)
    • Final confirmed port date/time and the time zone
    • Best phone number to reach you during the port window
    • SIP trunk provider and authentication type:
      • Registration-based, or
      • IP-based (IP-auth)
    • GFI FaxMaker version/build on the new server/VM
    • Number of fax lines / DIDs being ported (inbound and outbound expectations)
  • Pre-cutover checklist (complete before the port window)
    1. Validate Brooktrout SR140 configuration
      • Confirm SR140 settings match the SIP trunk/provider requirements (commonly including IP, T.38, and RTP-related settings).
      • Ensure SR140 is installed and configured according to standard SR140 setup guidance.
    2. Verify DID/DTMF routing rules in FaxMaker
      • Number porting is handled at the carrier/telephony layer, but FaxMaker inbound routing must match the production DIDs that will become active post-port.
      • If inbound faxes are routed to users/mailboxes based on DID/DTMF, confirm your routing entries align with the full set of production numbers that will be live after the port.
    3. Check FaxMaker Monitor (line readiness)
      • In the FaxMaker web interface, confirm all fax lines show as initialized/ready.
      • This is also a quick “day-of” status check during the port.
    4. Back up Brooktrout configuration files
      • Save copies of key Brooktrout TR1034 configuration files (commonly including callctrl.cfg and btcall.cfg) from your Brooktrout TR1034 configuration directory.
      • Example directory pattern: <FaxMaker_install_dir>\Brooktrout\TR1034\...\Config\
      • Keeping a pre-port snapshot enables fast comparison/rollback if settings drift during changes.
    5. Pre-install Wireshark on the FaxMaker server
      • Install in advance so you can capture SIP/T.38 traffic immediately during the port window.
    6. Run a final pre-port test fax
      • Shortly before the port, do a final send/receive test using the provider test number to confirm the “known-good” baseline still works.
  • If anything fails after the port (execute immediately)
    1. Step 1 — Quick checks
      1. Open FaxMaker Monitor and verify the lines are still initialized/ready.
      2. Attempt one outbound and one inbound test using a newly ported number.
      3. Collect basic FaxMaker logs from your FaxMaker logs directory (example default path): C:\Program Files (x86)\GFI\FaxMaker\logs
    2. Step 2 — Collect diagnostics (attach when requesting assistance)
      1. Run the FaxMaker Troubleshooter and save/upload the resulting bundle.
      2. Enable and capture Dialogic/Brooktrout ECC (advanced) logging for SR140-related failures.
      3. Capture a Wireshark PCAP on the FaxMaker server during a failed fax attempt (start shortly before the attempt; stop shortly after it fails).
    3. Step 3 — Provide correlation details
      • Exact timestamp(s) of 1–2 failed attempts (include time zone)
      • Source and destination fax numbers used (redact if required by policy; preserve enough digits to distinguish numbers)
      • Whether the failure is send, receive, or both
      • Any immediate on-screen error text (if shown)
  • Post-port verification (success criteria)
    1. Confirm inbound calls to each newly ported DID reach the SIP trunk (use provider-side validation if available).
    2. In FaxMaker Monitor, confirm lines remain initialized/idle as expected.
    3. Perform:
      • At least one inbound fax test to a ported DID
      • At least one outbound fax test from FaxMaker
    4. Confirm inbound routing delivers to the expected recipients based on your DID/DTMF rules.

Customer Impact

Recommended action: Complete the pre-cutover checklist and pre-stage diagnostics capture (Troubleshooter bundle, ECC logging, and Wireshark PCAP capability) before the port window begins.

Expected outcome: If inbound or outbound faxing fails immediately after the port, you can provide complete diagnostics (logs + PCAP + timestamps/numbers) right away to accelerate root-cause analysis and reduce downtime during the cutover window.

Frequently Asked Questions

1. How do I know this article applies to me if I don’t have an error message yet?
It applies when you are planning a production fax number port/cutover to a new GFI FaxMaker environment (often SR140 + SIP trunk) and cannot test the real production DIDs until the carrier port completes, but you want a rapid-response plan if send/receive fails right after cutover.
2. What information should be ready before the cutover to avoid delays if something breaks?
Have the final port time/time zone, best callback number, SIP provider and authentication type (registration vs IP-auth), FaxMaker version/build, and number of lines/DIDs. Also validate SR140 settings, verify DID/DTMF routing, and install Wireshark so a PCAP can be captured immediately.
3. What are the most important artifacts to attach if faxing fails immediately after the port?
A FaxMaker Troubleshooter bundle, SR140/Dialogic ECC (advanced) logs, and a Wireshark PCAP captured during a failed attempt—plus exact timestamps (with time zone) and the source/destination numbers used.
4. Test faxing works on the provider’s test number—why might production DIDs still fail after port?
The SR140 + FaxMaker baseline may be healthy, but production failure can still occur due to carrier/SIP routing changes, DID/DTMF mapping differences, authentication/routing changes at cutover, or inbound routing rules in FaxMaker not matching the production numbers once they go live.
5. What should I check first if inbound faxes don’t reach the right users after the port?
Verify DID/DTMF routing rules in FaxMaker match the ported numbers and expected formats, then confirm in FaxMaker Monitor that lines are initialized and that inbound attempts appear in logs. If routing still fails, attach Troubleshooter logs, ECC logs, and a PCAP with timestamps for deeper analysis.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments