What causes phantom calls?

SIP phones and analogue telephone adapters (ATAs) can receive unwanted calls when they are reachable from the internet and configured to accept direct IP-to-IP calls. Automated scanning systems can send unauthorised SIP call requests directly to the device, causing repeated ringing even though no legitimate call has been placed to your telephone number.

These calls may display unusual caller IDs such as 100, 700, 800, 900 or 1000 and can occupy lines or disrupt a connected telephone system.

Calls that reach your equipment directly in this way bypass IXICA’s network and are not delivered through your IXICA SIP trunk. The solution is to restrict which incoming call requests your equipment accepts.

Recommended settings for Grandstream ATAs

Log into the ATA’s web interface using administrator access and configure the following:

Apply the relevant settings to every active FXS port or SIP profile. Menu locations and wording vary by model and firmware. On models that display Enable Direct IP Call instead, set that option to No.

Important: The Check SIP User ID for Incoming INVITE option checks whether an incoming call is addressed to the configured SIP user ID. Certain configurations may use a different destination identifier for legitimate calls. If normal incoming calls stop working after enabling this option, change only this optional setting back to No, apply the change and test again.

Save and apply the changes, reboot the ATA if required, and test normal incoming and outgoing calls. Rebooting alone does not correct the configuration that allows phantom calls.

Additional protection and troubleshooting

Keep the ATA’s firmware current, use a strong administrator password, and have your IT provider review firewall rules to prevent unsolicited internet traffic from reaching the device. Any SIP access restrictions must continue to allow IXICA’s authorised service addresses.

An unusual caller ID alone does not prove that a call bypassed IXICA. If the problem continues, contact IXICA Support with the affected telephone number, example call dates and times, and the ATA model. These details help distinguish direct-to-device phantom calls from unwanted calls arriving through the telephone network.

Why Does IXICA Not Support SIP REFER?

IXICA does not support SIP REFER on its SIP trunks. This security policy helps reduce exposure to unauthorized call transfers, toll fraud, and the disclosure of sensitive call information.

Customers should configure their telephone systems to manage transfers within the PBX rather than rely on carrier-side SIP REFER.

What is SIP REFER?

SIP REFER is a signalling method that asks another telephone system or device to contact a specified destination. It is commonly used for call transfers, with the destination supplied in a field called Refer-To.

SIP REFER is a legitimate protocol feature and is not inherently a security vulnerability. However, it requires careful authentication, authorization, and handling to prevent misuse. Improperly configured systems may accept transfer requests from parties that should not have permission to redirect calls or initiate new connections.

Why has IXICA chosen not to support it?

IXICA takes a preventative approach to call-transfer security. We do not support this mechanism on our SIP trunks because improperly controlled transfer requests can introduce several risks.

Toll fraud and unauthorized charges

An inadequately protected telephone system may allow an outside party to trigger calls to unauthorized destinations, including expensive international or premium-rate numbers. Abused transfer permissions can generate substantial charges without the account holder’s knowledge or approval.

Unauthorized call redirection

A malicious or compromised system may attempt to redirect an active call to a destination that neither the caller nor the account holder intended. Without appropriate authorization checks, a telephone system could process that request as though it were a legitimate transfer.

Misleading transfer identities

A transfer request may claim to originate from a trusted person or system. Information such as the Referred-By identity is not, by itself, proof of authorization. Without appropriate protection and verification, that information can be falsified or reused to influence how a call is handled.

Exposure of sensitive information

Depending on the implementation, status notifications associated with REFER can reveal endpoint availability, IP addresses, or other signalling details. Excessive information in these notifications can undermine privacy and disclose information that would otherwise remain protected.

Our policy is to avoid this additional transfer mechanism at the carrier connection and require customers to use PBX-managed alternatives.

Does this mean I cannot transfer calls?

No. Not supporting carrier-side SIP REFER does not prevent call transfers altogether.

A compatible, properly configured PBX can manage transfers itself, including:

• Blind transfers: Sending the caller to another destination without first speaking to the recipient.
• Attended transfers: Speaking with the recipient before completing the transfer.

These functions can be handled within the PBX rather than delegated to the carrier. The exact configuration and supported behaviour depend on your telephone system.

Can my phones still use SIP REFER internally?

Yes. This policy concerns the SIP connection between your telephone system and IXICA.

Your phones may still use REFER internally to communicate transfer instructions to your PBX, provided the PBX processes those instructions locally instead of passing them to IXICA.

Do not disable internal transfer functions indiscriminately. Your administrator should distinguish between transfers handled within your telephone system and transfer requests sent across the IXICA SIP trunk.

How should transfers to external telephone numbers work?

Configure your PBX to retain control of the call and bridge it to a separate outbound call, rather than ask IXICA to complete a carrier-side REFER transfer.

For example, when an incoming caller needs to be transferred to an employee’s mobile phone, the PBX can place an outbound call to that mobile number and connect the two call legs. The PBX remains responsible for managing the connection.

The new outbound call should remain subject to your normal calling permissions and destination restrictions. A transfer should not provide a way around the restrictions that apply when a user dials an external number directly.

What should my telephone system administrator configure?

Ask your administrator or PBX provider to review the following:

• Disable carrier-side REFER for the IXICA trunk. Configure transfers to be handled by the PBX instead of relying on IXICA to process a REFER request.
• Restrict external transfer destinations. Permit only the destinations your business requires, and limit international or high-cost calling to authorized users.
• Control access to SIP services. Use appropriate authentication and trusted-source restrictions. Where a Session Border Controller (SBC) is deployed, configure it to reject disallowed REFER requests at the trunk boundary—not merely remove individual headers.
• Maintain and monitor the system. Apply vendor security updates promptly and review unusual outbound calling activity. Network access restrictions are not a substitute for correcting vulnerabilities in the telephone system itself.

Test both internal and external transfers after making configuration changes.

Does using authentication or an SBC change IXICA’s policy?

No. SIP REFER remains unsupported on IXICA SIP trunks.

Authentication, access restrictions, and an SBC can provide important security protections, but they do not change IXICA’s supported transfer method. Your telephone system must remain configured to use PBX-managed transfers.

Does this policy eliminate all toll-fraud risks?

No. Restricting one transfer mechanism is not a complete defence against telephone fraud.

Outbound calling permissions, destination restrictions, secure credentials, access controls, software maintenance, and monitoring remain important safeguards. Customers should review these controls regularly with their telephone system administrator.

Where can I get help?

Contact IXICA Support at support@ixica.com with your PBX make, software version, and a description of the transfer you are trying to perform.

Include whether the destination is an internal extension or an external telephone number, and whether the issue occurs during a blind or attended transfer. This information will help us review the issue and guide you toward an appropriate configuration.

If you are calling a toll-free number from your VoIP line and the call does not complete, but the same toll-free number works from another phone line, the most likely cause is the caller ID being sent with your outbound call.

Many toll-free providers require the calling party to send a valid caller ID. This caller ID may be used to determine where the call is coming from, whether the caller is allowed to reach the toll-free number, and how the toll-free provider should rate or route the call.

This is especially important when the toll-free number has geographic restrictions.

---

Why does caller ID matter when calling toll-free numbers?

Toll-free numbers are different from regular local numbers. With toll-free service, the owner of the toll-free number pays for the inbound call.

Because of this, toll-free providers often need to know where the caller is calling from. They may use the caller ID, ANI, charge number, or related call signaling information to determine the caller’s location or rate centre.

This information can affect:

1. Whether the call is accepted
2. Whether the call is blocked
3. How the call is rated
4. Where the call is routed
5. Whether the caller is within an allowed geographic area

If the caller ID is missing, invalid, incomplete, or not usable for rating, the toll-free provider may reject the call.

---

Why does the call work from my mobile phone or landline but not from VoIP?

Your mobile phone or landline normally sends a valid caller ID or charge number that the toll-free provider can recognize and rate.

A VoIP system, PBX, or SIP trunk may be configured to send a caller ID that is not acceptable to the toll-free provider. For example, the PBX may send only an internal extension, an invalid number, or a toll-free number as the outbound caller ID.

When this happens, the toll-free provider may reject the call even though the number itself is working.

---

What caller ID problems can cause toll-free calls to fail?

Calls to toll-free numbers may fail if your outbound caller ID is not valid or not usable by the receiving toll-free provider.

Common caller ID issues include:

1. Sending only an internal extension, such as 101 or 2001
2. Sending fewer than 10 digits
3. Sending an invalid 10-digit or 11-digit number
4. Sending a number that is not assigned to you
5. Sending a disconnected or non-working number
6. Sending a toll-free number as your caller ID
7. Sending anonymous, private, blocked, or restricted caller ID
8. Sending malformed caller ID with extra characters or incorrect formatting
9. Sending a caller ID that does not represent a valid North American geographic number

Any of these issues may cause a call to a toll-free number to fail, especially if the toll-free number has calling restrictions.

---

Can I use a toll-free number as my outbound caller ID?

In many cases, using a toll-free number as your outbound caller ID can cause problems when calling other toll-free numbers.

Many toll-free providers expect the caller ID or charge number to be a valid non-toll-free number. This is because they may use that number to determine the caller’s geographic location or rate centre.

A toll-free number usually does not identify the caller’s local rate centre in the same way that a geographic number does. As a result, some toll-free platforms may reject the call.

For best results, use a valid local caller ID number assigned to your account when calling toll-free destinations.

---

What are geographic restrictions on toll-free numbers?

Some toll-free numbers are configured to accept calls only from specific geographic areas.

For example, a toll-free number may only accept calls from:

1. Canada only
2. The United States only
3. A specific province or state
4. A specific city or rate centre
5. A group of approved regions
6. Certain carriers or call types

If your caller ID does not allow the toll-free provider to identify your location, or if the caller ID appears to be outside the allowed area, the call may be rejected.

---

Can IXICA confirm the restrictions on the toll-free number I am calling?

Usually, no.

IXICA can only confirm toll-free routing restrictions for toll-free numbers owned or managed by IXICA.

If the toll-free number belongs to another provider or business, IXICA generally cannot see how that number is configured. The number may have restrictions, routing rules, carrier blocks, fraud controls, or geographic limitations that are only visible to the toll-free number’s provider.

---

Is this an IXICA switch issue?

Usually, no.

If the same toll-free number completes from another line but fails from your VoIP line, the issue is often related to the outbound caller ID or call signaling being sent from your VoIP service.

This is not unique to IXICA. It is common across the telecom industry. Many toll-free platforms and upstream carriers require valid caller identification before accepting calls.

IXICA can help review the caller ID being sent from your service, but IXICA cannot override the call acceptance rules of a toll-free number hosted by another provider.

---

What caller ID should I send when calling toll-free numbers?

We recommend sending a valid North American geographic number assigned to your account.

The caller ID should generally be:

1. A valid 10-digit local number, such as 4165551234
2. A valid 11-digit North American number, such as 14165551234
3. A number assigned to your account or authorized for your use
4. A number that is active and reachable
5. A non-toll-free number

Avoid sending:

1. Internal extensions
2. Anonymous or blocked caller ID
3. Invalid numbers
4. Toll-free numbers
5. Numbers not assigned to or authorized for your account
6. Disconnected numbers
7. International caller ID when calling North American toll-free numbers, unless specifically supported

---

What should I check in my PBX or VoIP system?

If toll-free calls are failing, check your PBX, SIP trunk, or outbound route configuration.

Review the caller ID being sent in:

1. Outbound route settings
2. Extension caller ID settings
3. Trunk caller ID settings
4. SIP From header
5. P-Asserted-Identity header, if used
6. Remote-Party-ID header, if used
7. Any caller ID override rules
8. Any emergency or outbound CID settings

Make sure the caller ID is not being replaced with an extension, blank value, toll-free number, or invalid number.

---

Why does the toll-free provider need a “charge number”?

Some toll-free networks use a charge number, ANI, or caller ID information to identify the origin of the call. This helps determine how the toll-free call should be rated and whether the call should be allowed.

If the charge number or caller ID is missing or invalid, the toll-free provider may not be able to determine the call origin. In that case, the call may be rejected.

---

What can IXICA do to help?

IXICA can help verify the outbound call details from your side of the call.

When possible, IXICA may be able to check:

1. The caller ID being sent
2. The caller ID format
3. Whether the caller ID is assigned to your account
4. Whether your SIP trunk or PBX is sending an unexpected number
5. Whether the call is being rejected upstream
6. Whether a different valid caller ID should be tested

However, if the toll-free number is hosted by another provider, IXICA cannot confirm or change that provider’s toll-free restrictions.

---

What should I include when opening a support ticket?

If you need IXICA to investigate a failed toll-free call, please provide:

1. The toll-free number you are calling
2. The caller ID number you are sending
3. The date and time of the failed call
4. The SIP account or trunk used for the call
5. Whether the call works from another phone line
6. Whether the call fails for one toll-free number or multiple toll-free numbers
7. Any error message, recording, SIP response code, or fast-busy behaviour
8. A sample call within the last 24 hours, if possible

This information helps determine whether the issue is related to caller ID, routing, toll-free restrictions, or upstream rejection.

---

Summary

If a toll-free number works from one phone line but fails from your VoIP line, the most common cause is the caller ID being sent.

Many toll-free providers require a valid non-toll-free caller ID or charge number so they can determine the caller’s location, rate centre, and eligibility to reach the toll-free number.

To avoid issues, send a valid, active, authorized local caller ID number when calling toll-free destinations. Avoid using extensions, invalid numbers, blocked caller ID, or toll-free numbers as your outbound caller ID.

When you place outbound calls, the person receiving the call may see labels such as Spam, Spam Likely, Possible Spam, Scam Risk, or similar warnings.

These labels are usually applied by the recipient’s mobile carrier, mobile device, operating system, or a third-party spam detection application. They are not labels added by IXICA.

Spam labels may appear for several reasons, including:

1. The number has been reported as spam by call recipients.
2. The number appears in one or more spam reputation databases.
3. The number has unusual calling patterns, such as high outbound call volume or many short-duration calls.
4. The caller ID number is not formatted correctly.
5. The caller ID number is not assigned to, or authorized for, the party using it.
6. The receiving carrier or device cannot fully verify the call.
7. A third-party spam detection app is installed on the recipient’s phone.
8. The number may have been used by a previous owner and already has a poor reputation.

In many cases, these labels are based on reputation scoring and analytics rather than a direct block placed by IXICA.

---

Can IXICA remove a Spam Caller label from my number?

In most cases, no.

IXICA does not control the spam labels shown on the recipient’s mobile device. These labels are typically generated by mobile carriers, handset manufacturers, operating systems, or third-party analytics providers.

IXICA can help confirm whether your outbound caller ID is being sent in the correct format and whether the caller ID being used is valid for your service. However, IXICA generally cannot directly remove a spam label from an external database or from a recipient’s device.

---

Does the recipient’s phone or app affect the label?

Yes.

Different phones, carriers, and apps may use different spam detection sources. This means the same call may show normally on one device but appear as Spam Likely on another.

For example:

1. Some Samsung devices use spam protection services such as Hiya.
2. Some Android devices use built-in caller ID and spam protection features.
3. Some iPhones may use carrier-provided spam identification or third-party call filtering apps.
4. Some customers may install apps such as Hiya, Truecaller, or carrier-branded call protection tools.

Because there are multiple systems involved, there is no single central database that controls all spam labels.

Hiya, for example, offers caller reputation tools that allow businesses to check or manage how their numbers may appear in supported Hiya-powered environments. Hiya is a third-party service and is not owned, operated, or controlled by IXICA.

---

What is STIR/SHAKEN?

STIR/SHAKEN is a caller ID authentication framework used by carriers in North America to help reduce caller ID spoofing and fraudulent calls.

It allows carriers to verify whether the caller ID number being presented on a call is authorized and trustworthy. The FCC describes caller ID authentication as a system designed to reduce illegal spoofing and help protect consumers from scam robocalls.

In Canada, the CRTC has also required implementation of STIR/SHAKEN for IP-based voice calls to improve caller information integrity and reduce nuisance calls.

---

Does STIR/SHAKEN decide whether my call is spam?

Not by itself.

STIR/SHAKEN helps authenticate the caller ID. It does not necessarily decide whether the call is wanted, unwanted, legitimate, or spam.

However, if a call is not properly authenticated, or if the caller ID appears suspicious, some carriers or analytics systems may be more likely to label the call as suspicious.

For example, spam labeling may be more likely if:

1. You send a caller ID number that is not assigned to you.
2. You send a caller ID number in an invalid format.
3. You frequently change outbound caller ID numbers.
4. Your calls fail authentication or receive a lower trust rating.
5. Your number has previous spam complaints or poor reputation history.

---

What caller ID format should I use?

Caller ID should be sent in a valid North American format.

In most cases, the number should be sent as a valid 10-digit or E.164-format number, depending on your PBX or platform configuration.

Examples:

Valid 10-digit format:
4165551234

Valid E.164 format:
+14165551234

Avoid sending caller ID values such as:

1. Anonymous text instead of a number
2. Internal extension numbers
3. Incomplete numbers
4. Invalid numbers
5. Numbers with extra characters
6. Numbers that are not assigned to your account
7. Numbers that belong to another business or customer

If the caller ID number is malformed or not authorized, the call may be treated as suspicious by downstream carriers or receiving networks.

---

Can I send any caller ID number I want?

No.

You should only send caller ID numbers that you are authorized to use. Ideally, the caller ID should be a number assigned to your account or a number that has been verified and approved for your use.

Sending a number that is not assigned to you, not authorized for your use, or does not belong to your organization may cause call completion, authentication, or spam labeling issues.

It may also violate carrier policies or regulatory requirements, especially if the number is used in a misleading or deceptive way.

---

Why was my number marked as spam if I did nothing wrong?

Spam labels are not always accurate.

A number can be mislabeled for several reasons:

1. A recipient may have incorrectly reported the number as spam.
2. A previous user of the number may have created a poor reputation before the number was assigned to you.
3. High call volume may trigger analytics-based scoring.
4. Short calls, abandoned calls, or unanswered calls may look suspicious to analytics platforms.
5. The number may appear in a third-party database that has not yet been updated.
6. The recipient’s mobile app may make its own spam determination.

These systems are not perfect. In some cases, the label may clear over time as reputation databases update and normal calling patterns are established.

---

What can I do to reduce the chance of being marked as spam?

To improve caller ID reputation and reduce the risk of spam labeling, we recommend the following:

1. Use only caller ID numbers that are assigned to your account or authorized for your use.
2. Send caller ID in a valid format.
3. Avoid rotating through many caller ID numbers unnecessarily.
4. Avoid high-volume calling patterns that resemble robocalling or auto-dialing abuse.
5. Avoid repeated short-duration calls.
6. Make sure your business name, callback number, and call purpose are clear to recipients.
7. Respect Do Not Call, consent, and opt-out requirements where applicable.
8. Register your numbers with major caller reputation providers where possible.
9. If using Samsung/Hiya environments, review your number reputation through Hiya’s business tools.
10. Ask recipients who know your business to save your number as a contact, where appropriate.

These steps do not guarantee that a spam label will be removed, but they can help improve reputation over time.

---

Can IXICA troubleshoot this?

IXICA can help review the technical side of your outbound calling setup.

For example, IXICA may be able to check:

1. Whether the caller ID number is being passed correctly.
2. Whether the number format appears valid.
3. Whether the number is assigned to or authorized for your account.
4. Whether your PBX or platform is sending unexpected caller ID values.
5. Whether changes are needed to your SIP trunk or outbound configuration.

However, IXICA cannot guarantee how a receiving carrier, mobile device, or third-party spam application will label a call.

---

What should I include when opening a support ticket?

If you believe your outbound caller ID is being incorrectly labelled as spam, please include the following information when opening a ticket:

1. The caller ID number being displayed.
2. The number you called.
3. The date and time of the test call.
4. The label shown on the recipient’s device.
5. The recipient’s carrier, if known.
6. The recipient’s device type, such as iPhone, Samsung, Google Pixel, etc.
7. A screenshot of the spam label, if available.
8. Whether this happens with all recipients or only specific carriers/devices.
9. Whether the caller ID number is assigned to your IXICA account.
10. Whether the call was placed from a PBX, dialer, contact centre, or other platform.

This information helps determine whether the issue is related to caller ID formatting, number authorization, recipient-side filtering, or third-party reputation databases.

---

Summary

Spam caller labels are controlled by mobile carriers, devices, operating systems, and third-party spam detection providers. IXICA does not directly control these labels.

IXICA can assist with confirming that your caller ID is valid, properly formatted, and authorized for your account. However, if the label is being applied by a third-party app, mobile device, or external reputation database, the correction may need to be handled through that provider’s process.

To reduce the risk of spam labeling, always use valid and authorized caller ID numbers, maintain responsible calling practices, and ensure your outbound calls comply with applicable carrier and regulatory requirements.

Overview

An ATA (Analog Telephone Adapter) can be used to connect IXICA SIP service to a traditional analog fax machine. However, this type of setup is not recommended for mission-critical faxing.

While ATA-based faxing may work successfully in many cases, fax over IP remains sensitive to packet loss, jitter, codec handling, signaling behavior, and device compatibility. For that reason, successful fax delivery cannot be guaranteed 100% of the time, even in environments where T.38 is supported.

For customers who require dependable fax service, the most reliable options remain:

• a traditional analog line
• a true virtual fax service

IXICA offers a variety of virtual fax solutions, including API integrations for custom software and applications, such as workflows commonly used in medical, logistics, and pharmaceutical environments.

Traditional analog lines are also available in select areas of Ontario and Quebec, Canada.

Recommended Options

If faxing is essential to your operations, IXICA recommends either a traditional analog line or a virtual fax service. ATA-based faxing should be considered a convenience option, not a guaranteed solution for critical communications.

Important Notice About ATA Faxing

Using an ATA with a fax machine over SIP can work, but it should be treated as a best-effort configuration.

Fax transmissions are far less tolerant than voice calls. A voice call may sound normal even when the network is experiencing minor impairments, but a fax session can still fail under those same conditions. Packet loss, timing variation, codec changes, and intermediate network handling can all affect fax reliability.

For that reason, ATA faxing should not be relied upon for legal, medical, compliance-sensitive, or otherwise mission-critical communications.

If You Still Wish to Proceed with an ATA/Fax Setup

1) Do not place the ATA behind a PBX

Connecting an ATA through a PBX or other intermediate voice platform will often result in failed fax transmissions. Faxing over SIP is more reliable when the path is kept as simple and direct as possible.

2) The ATA must connect directly to IXICA

For the best chance of success, the ATA should register directly to IXICA using its own SIP credentials.

This reduces the risk of signaling issues, codec changes, or other handling problems that can interfere with fax delivery.

3) Use a dedicated SIP account for the ATA

We strongly recommend ordering a dedicated SIP account — either metered or unmetered — and using that account’s username and password directly on the ATA.

This provides the highest expected success rate for ATA-based faxing.

4) Do not use voice service credentials on the ATA

Do not use your existing voice service username and password on the ATA.

Using voice service credentials on an ATA for faxing may interfere with, disrupt, or break your existing voice services.