Presenting Original Caller ID on Diverted (Call-Forwarded) Calls

Voice
1 of 1 rows
TopicPresenting a calling number that is not allocated to you, where the call results from a call forward or diversion

1. What you can do

Where one of your numbers receives a call and forwards it elsewhere, you may present the original caller's number to the final recipient rather than your own forwarding number.
Two conditions apply:
  1. The call must be a genuine diversion of a real inbound call.
  2. It must carry a SIP Diversion header naming the number that was called and forwarded, and that number must be one you hold on the Atom network.
Without the Diversion header we cannot tell a genuine forward from a customer simply presenting a number they don't hold. Those calls are rejected or have the CLI replaced.
Read Section 6 before you build to this - there are things about the regulatory position you should know, and they affect how much protection this pattern actually gives you.

2. What to send us

All requirements apply to the forwarded (outbound) leg you send to Atom.

2.1 Headers

5 of 5 rows
FromThe original caller's number - unless the caller withheld their CLI, in which case see Section 3.
P-Asserted-IdentityThe original caller's number. Where From carries the number, the user parts must match.
DiversionMandatory. The diverting number - your number that received and forwarded the call - with a reason parameter. Must be a number you hold on our network.
PrivacyRequired where the original caller withheld their CLI. See Section 3.
To / Request-URIThe final destination.

2.2 Number format

Use the format in your interconnect schedule. Unless it says otherwise, that is E.164 with the 61 country code, no leading +, no spaces or punctuation - for example 61491570006.
Do not present:
  • 13, 1300, 1800 or 1900 numbers as the calling number. This is prohibited outright, including on diverted calls. If the original caller presented one of these to you, you cannot pass it through - present your diverting number instead and keep the Diversion header.
  • Numbers from unallocated ranges, including the ranges reserved for film and television use.
  • Numbers that cannot receive a return call.
  • Extension-length or otherwise non-conformant digit strings.

2.3 The reason parameter

Set reason to the value that reflects what actually happened. The defined values are:
unknown, user-busy, no-answer, unavailable, unconditional, time-of-day, do-not-disturb, deflection, follow-me, out-of-service, away
Use unknown only where your platform genuinely doesn't have the condition. Don't default everything to unconditional for convenience - we rely on this when investigating CLI complaints raised against your traffic.

2.4 Chained diversions

Where a call is forwarded more than once, Diversion headers stack: each diverting party is added as an additional header (or an additional entry in a comma-separated header), most recent first. Don't collapse the chain to a single header, and don't overwrite an inbound Diversion header with your own.

2.5 History-Info

We use Diversion as the primary diversion indication. History-Info may be sent in addition and will be preserved, but it is not accepted in place of Diversion unless agreed in your interconnect schedule.

3. Privacy - withheld numbers

If the original caller withheld their number, that suppression must survive the diversion. Omitting the number from your own display logic is not enough; the restriction has to be signalled onward so no downstream network presents it.
Privacy: id on its own is not sufficient. It only withholds P-Asserted-Identity at the trust boundary — it does nothing about From or Contact. A call that sets Privacy: id while leaving the caller's number in the From URI still discloses it in cleartext.
On the forwarded leg:
  • Anonymise the From and Contact URIs - conventionally "Anonymous" <sip:anonymous@anonymous.invalid>. Alternatively send Privacy: user;id and rely on us to anonymise From; confirm which applies to your trunk before deploying.
  • Include Privacy: id.
  • Keep P-Asserted-Identity with the original caller's number so the call can be traced if required. Mark it private - don't delete it.
  • Don't populate any display name that gives away the withheld identity.
This breaks most often when a platform rebuilds the outbound INVITE rather than relaying it, and the inbound privacy indication is lost in the rebuild. Test this path explicitly.

4. Worked example

0491 570 006 calls (02) 5550 1234, which forwards unconditionally to 0491 570 156. The recipient should see 0491 570 006.
Numbers below are from the ACMA film/TV reserved ranges and IPs are from the documentation range, so this exact INVITE would fail the validation in Section 5. Substitute live numbers when testing.
text
INVITE sip:61491570156@[provider-sbc]:5060 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bK7a1c3e...
Max-Forwards: 69
From: <sip:61491570006@203.0.113.10>;tag=b00286f5d2c9f07d
To: <sip:61491570156@[provider-sbc]>
Call-ID: 30d79b547e329d0f3bf2dec353b56eb4@203.0.113.10
CSeq: 200 INVITE
Contact: <sip:61491570006@203.0.113.10:5060>
Diversion: <sip:61255501234@203.0.113.10>;reason=unconditional
P-Asserted-Identity: <sip:61491570006@203.0.113.10>
Content-Type: application/sdp
Content-Length: 257
From and P-Asserted-Identity carry the original caller. Diversion carries your number, evidencing that this is a forward. No Privacy header because the caller didn't withhold.

4.1 Defects to look for in your own traffic

  • A display name of Anonymous next to a visible number, with no Privacy header - e.g. Contact: Anonymous <sip:61491570006@...>. This almost always means an inbound privacy request was half-dropped in a B2BUA rebuild: the display name survived, the privacy indication and URI anonymisation didn't. Trace the inbound leg; if the caller withheld, apply §3 in full.
  • Privacy: id set but the number still in the From URI. See Section 3.
  • One Diversion header on a multi-hop diversion. See Section 2.4.
  • reason=unconditional on everything. See Section 2.3.
  • A Diversion number in a range you don't hold. Rejected at validation.

5. What we won't carry

We validate diverted calls before carriage. Where a call presents a number you don't hold:
7 of 7 rows
No Diversion headerRejected, or CLI replaced with your allocated number
Diversion number isn't one you hold on our networkRejected
No correlating inbound call for the asserted diversionRejected; referred for investigation
Calling number is 13, 1300, 1800 or 1900Rejected
Calling number is in an unallocated or non-conformant rangeRejected
Malformed or non-E.164 formatRejected
Inbound privacy indication not carried forwardRejected, or privacy re-applied
Repeated non-compliant diverted traffic is treated as suspected CLI spoofing. We are obliged to investigate it, notify others in the call chain, and report to the ACMA.

6. What you should understand about the compliance position

This section is short but it matters. Don't treat the pattern above as a regulatory safe harbour.
There is no rule that authorises this. No Australian legislation, code or guideline says a diverted call should present the original caller's number, and none mentions the Diversion header at all. The Diversion header comes from an IETF specification (RFC 5806), not from anything Australian. What exists is a carve-out in industry code C661:2022 that relieves transit and terminating carriers of the duty to validate calling number accuracy on calls "received via call redirection or call forwarding from a B-Party." That carve-out clearly assumes original-number pass-through happens - but it doesn't mandate it, and it doesn't authorise it.
The general rule still applies to you. C661 requires originating providers to prevent carriage of calls where the caller doesn't hold rights of use to the number presented. If a forwarded call is characterised as a new origination by your platform rather than a genuine diversion, that rule bites in full and the overstamp is prohibited.
So everything turns on whether the diversion is real. That is why we require the Diversion header and why we correlate it against an inbound call. It's the evidence that distinguishes your traffic from spoofing.
The line you must not cross. Spoofing under C661 means unauthorised use of a number combined with an attempt to mask or mislead the recipient about who is calling. A genuine forward showing the genuine original caller does neither - nothing is masked, and the recipient sees the person who actually called. But a Diversion header naming a number you don't hold, or asserting a forward that never happened, supplies both limbs of that definition. The header is not a formality.
Our requirements are contractual. Because the regulatory position is thin, the requirements in Section 2 and Section 3 are [Provider]'s interconnect terms rather than restatements of a rule. Other carriers may require something different - don't assume a configuration that works with us will be accepted elsewhere.
On privacy specifically. The requirement in Section 3 is ours. The industry guideline on Calling Number Display recommends that a caller's number blocking survives a diversion, but it is a guideline drafted as "should", not a binding code. We enforce it as a contractual requirement, and we'd expect any well-run network to do the same.

7. Your obligations

By sending diverted calls with an overstamped calling number over our network, you warrant on each call that:
  1. The call is a genuine diversion of an inbound call to the number in the Diversion header.
  2. You hold rights of use to that number.
  3. The number presented as the calling number is what you received from the original caller, unaltered.
  4. Any caller-applied CLI restriction has been carried forward per Section 3.
  5. You'll retain records sufficient to demonstrate the above and provide them on request within your interconnect schedule's timeframes, including in response to an ACMA enquiry.
You remain responsible for your own downstream customers and resellers in respect of the traffic you send us.

8. FAQ

Can I present any number I like as long as I add a Diversion header? No. The header asserts that a specific number you hold forwarded a specific call, and we validate both. Asserting a diversion that didn't happen is spoofing and is escalated as such.
The recipient is seeing my forwarding number instead of the original caller. Either the Diversion header was missing and we substituted a compliant number, or your platform is putting the diverting number in From and P-Asserted-Identity instead of the original caller. Check Section 2.1, then raise a ticket with a SIP trace of the outbound INVITE.
Can I use History-Info instead of Diversion? Not by default. See Section 2.5.
What about overstamping that isn't a diversion - a contact centre presenting one 1300 callback number, say? Different situation, different rules, and note that 13/1300/1800/1900 numbers can't be used as a calling number at all. Talk to us before configuring it.
Does the original caller's number need to be Australian? Internationally-originated calls are handled differently. Talk to us before diverting them with the original number presented.
My platform can't populate the Diversion header. Then present a number you hold - typically the diverting number - until it can. We can't carry an unvalidated overstamped calling number.

9. Further reading

This article sets out Atom's interconnect requirements and our reading of the applicable framework. It is not legal advice. Where it conflicts with your interconnect schedule, the schedule prevails.
Was this article helpful?
Ask AVA about this