- Joined
- Oct 18, 2019
- Messages
- 89
- Reaction score
- 95
Hi,
we have a strange problem:
Call forwards show correctly the OriginatedCallerID (origninal Caller Number) at the forwarded target. This is done by clip no-Screening.
Example: Caller calls pbx (Number 123) ==> 3CX receives call and forwards to target ==> Target receives call and shows (Number 123)
OK!
But when the caller is anonymous it doesn´t reflect the anonymous call at the target, instead it shows the trunk main number.
Example: Caller calls pbx (Number Anonymous) ==> 3CX receives call and forwards to target ==> Target receives call and shows number of the used sip trunk
NOK!
Why is the PBX doing this and how can we change this?
We did a WireShark trace and we can confirm that pbx places the trunk number into the From: Display Name field.
The sip trunk provider confirmed that they receive it like the trace tells us.
PBX ist on v18 Update 9 and hosted by 3cx.
SIP provider is EasyBell, so all the way supported.

We replicated this on another pbx instance (hosted by 3CX, too), with a different trunk and get the same behaviour.
Who can help?
we have a strange problem:
Call forwards show correctly the OriginatedCallerID (origninal Caller Number) at the forwarded target. This is done by clip no-Screening.
Example: Caller calls pbx (Number 123) ==> 3CX receives call and forwards to target ==> Target receives call and shows (Number 123)
OK!
But when the caller is anonymous it doesn´t reflect the anonymous call at the target, instead it shows the trunk main number.
Example: Caller calls pbx (Number Anonymous) ==> 3CX receives call and forwards to target ==> Target receives call and shows number of the used sip trunk
NOK!
Why is the PBX doing this and how can we change this?
We did a WireShark trace and we can confirm that pbx places the trunk number into the From: Display Name field.
The sip trunk provider confirmed that they receive it like the trace tells us.
PBX ist on v18 Update 9 and hosted by 3cx.
SIP provider is EasyBell, so all the way supported.
We replicated this on another pbx instance (hosted by 3CX, too), with a different trunk and get the same behaviour.
Who can help?
Last edited: