SIP Trunk to Mitel - Cannot send extension # as the caller ID to Mitel

Status
Not open for further replies.

JJ-3CX-TX

Customer
Joined
Sep 9, 2020
Messages
21
Reaction score
0
I have a trunk setup between 3CX and Mitel CONNECT on-prem. Both way calls are flowing properly but calls from 3CX to Mitel end up with trunk main number as caller ID.

From Mitel side the trunk is setup with standard config:
Screen Shot 2020-11-18 at 8.57.11 AM.png

and SIP Trunk is setup this way
Screen Shot 2020-11-18 at 8.58.24 AM.png

Screen Shot 2020-11-18 at 8.58.36 AM.png

on 3CX side the trunk is setup with main Trunk number 1180 (It cannot be blank so I decided to match the Mitel side)

Mitel trunk switch IP => 10.123.241.13
3CX Server => 10.123.249.87

I used this page for guidance: https://www.3cx.com/docs/sip-trunk-outbound-calls/#h.fl1a9lt7gvi6 and I have tried every possible option in the Outbound parameters tab for 'From: User part' but it is not passing the actual extension number to Mitel.


When I use 'default value' the trunk uses the virtual extension and I get the following:

{..........INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.123.249.87:5060;branch=z9hG4bK-524287-1---099ac65c9f90004a;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: <sip:[email protected]>
From: "CCC Agent 1"<sip:[email protected]>;tag=b4003574
Call-ID: gN3SPA3whN5FCPH11mvdgg..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
User-Agent: 3CXPhoneSystem 16.0.6.655 (655)
Remote-Party-ID: "CCC Agent 1"<sip:[email protected]:5060>;party=calling
Remote-Party-ID: <sip:1273>;party=called
Content-Length: 626


when i change it to 'CallerNum' I get the main trunk number in from field.

{..........INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.123.249.87:5060;branch=z9hG4bK-524287-1---7562435997088d6c;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: <sip:[email protected]>
From: "CCC Agent 1"<sip:[email protected]>;tag=4aa14c16
Call-ID: fYZcAQNhajTKYWiHMvXQUw..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
User-Agent: 3CXPhoneSystem 16.0.6.655 (655)
Remote-Party-ID: "CCC Agent 1"<sip:[email protected]:5060>;party=calling
Remote-Party-ID: <sip:1273>;party=called
Content-Length: 627


Could someone please advise what I can do to fix this.

Thank you
 
How is the trunk set-up in 3CX, not a Bridge Trunk?
 
Bridge mode gives me 404 auth failure from Mitel. I can make calls from 3CX to Mitel but not vice versa.

So I have setup a standard IP based SIP trunk. Not the most ideal setup because now I have to create a DID map for each extension (5121,5121) on 3CX side for Mitel to be able to call into 3CX.
 
That being the case, there are a number of fields, in the outbound trunk parameters that determine from where, caller ID is taken. It may be, that you have not stumbled upon the correct combination. Have you set the extensions outbound caller ID, to that of the extension number?
 
I have tried every possible field in the 'From: User part' including 'leave default value' is there a way for me to generate a verbose debug log for deeper analysis?


Screen Shot 2020-11-18 at 9.01.12 AM.png
 
The option that "seems" to work, in many cases (all providers are different), is OriginatorsCallerID. Again, you will have to figure out which field.
 
Last edited:
i tried that too and that sends full 10-digit callerID of that extension instead of the 4-digit extension number. Thank you for taking time and responding promptly :)
 
i opened a support ticket with 3CX. Lets see if we can get this resolved. Thank you for help
 
i tried that too and that sends full 10-digit callerID of that extension instead of the 4-digit extension number.
...and you put in a 4 digit number?
 
yes I tried that too but no luck. I am going to try something different now and if it works I will update this thread. I sought support from 3CX team and they told me basically that only one callerID is possible. Either set at extension level or at trunk level and there is no way to send extension number as outbound caller ID over a SIP trunk so that explains why it is not working. My question remains though, why leave the custom variables such as 'CallerNum' in the Outbound parameters tab for a SIP trunk if it is not used.
 
i also want to clarify I am not a 3CX expert so I don't mean to bash 3CX. It is a great product undoubtedly
 
and there is no way to send extension number as outbound caller ID over a SIP trunk so that explains why it is not working.
Well, I've had no problem sending the extension number alone , in the past. Nowadays it will be blocked by most providers, as it does not conform to a "standard" number format.
 
Perhaps this is not a good question but I will ask anyways. Why would 3CX block sending out the extension number as the caller ID on a SIP trunk when it allows receiving a 4-digit caller ID from the other side on the same trunk just fine.

Would it break any RFC? or would pose any security threat?

In my use case I need to be able to pass the calling 3CX extension's CallerNum (4-digit extension number) to Mitel so while I migrate 500+ users they don't complain. Everything else has so beautifully worked out except this one small glitch that I cannot get around. I am particularly annoyed because in the 'Outbound Parameters' tab of the sip trunk it gives you the option to manipulate the headers but its misleading really and does not do what it says it would. For example: when I choose 'CallerNum' as the outbound caller ID, it instead uses the trunk ID.

I really wish that somebody from 3CX can read this and provide some support to why this is not being allowed.

https://www.3cx.com/docs/sip-trunk-outbound-calls/
 
I respect your opinion @leejor but I have run pcap trace for all possible combinations over the last three days. Also opened a ticket with 3CX (and paid for it) but I was told that sending the extension ID over SIP trunk is not supported. I should have taken that answer for a no but being a stubborn person I decided to take a stab at it anyway and tried all variables in the console but regardless what I do the outbound INVITE packet either keeps it blank (if there is no default) or uses my trunk id for 'From: user' portion.
 
Did you see the link I attached later?
 
i did indeed. there are a couple of issues, that case has all 3CX systems bridge together but we are using a SIP trunk to connect to the Mitel.
In that instance as the person highlighted, if you change the outbound caller ID of the extension it effects ALL outbound calls including the normal PSTN calls going out the ITSP trunk which breaks it.

Master bridge type with Mitel does not work at all because of auth failure and that has been mentioned elsewhere on the forums. Slave bridge type allows us to call out to Mitel but Mitel users cannot call to 3CX again due to auth failure

Auth failure is either due to realm mismatch or URI formatting issue I am not sure but it is not due to credentials.
 
if you change the outbound caller ID of the extension it effects ALL outbound calls including the normal PSTN calls going out the ITSP trunk which breaks it.
Yes, unfortunately, that will be the case as 3CX considers all calls over a trunk, as outbound, and will use the number datafilled against the extension, in all cases. Unless the Mitel has a way to modify incoming caller ID (strip digits), per trunk group, as 3CX can, then they will, I assume, receive the "normal" PSTN number.
 
so I managed to hack my way through. Not the most ideal setup but I managed to make it work. I first adjusted the extension outbound caller-id to be XXXX-YYYYYYYYYY

Then for my internal SIP trunk I created a custom outbound caller Id rule (....)(-)(.*) -> \1 which then sends the extension number as caller ID to Mitel.

I created another custom outbound caller Id rule on my main SIP trunk (....)(-)(.*) -> 1\3 because my SIP trunk provider expects an 11-digit string.

I still need to map 4-digit DIDs on the internal SIP trunk to extension so direct calls to 3CX extensions work. Since, this is going to be only temporary while we migrate users off of Mitel to 3CX I am okay with it.
 
Good work-around, I'm sure someone else will make use of that in the future.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,990
Messages
590,163
Members
164,926
Latest member
tohoken1