Telstra Consumer SIP Trunk

[garrick.cobcroft@gsconsul]

Hi, I've just done a 3CX hosted install. And when getting onsite found that the clients trunks are with Telstra consumer (ie delivered through ATA in Telstra modem). I've had the client call Telstra and obtain the SIP credentials, but the noticed two things.

1. Telstra doesn't appear to show as a trunk provider in the Pro version, only in Enterprise???
2. I tried to add an extra Trunk in my NFR tenancy in order to test the credentials, but it doesn't seem to attempt to register. There is no failure on the registration, it simply doesn't seem to want to try and attempt the registration.

Thanks in advance,
Garrick

 

[Alejandro_3CX]

Hi Garrick Telstra trunk are not compatible with Hosted by 3CX



There are three Telstra Templates, you may check the configuration guide for each one here

Have a good one!

 

[garrick.cobcroft@gsconsul]

Thanks Alejandro,

I have read the guides, the problem is that the trunk doesn't try to authenticate, this is the same with an on-prem 3cx system.

Also, the 3 telstra templates don't appear as options in Pro?

Thanks,
Garrick

 

[YiannisH_3CX]

Also, the 3 telstra templates don't appear as options in Pro?

License version plays no role in this. On an on-premise installation the templates will be available for all license versions. The difference is that the templates are not available in Hosted by 3CX and SMB because they are not compatible.

I have read the guides, the problem is that the trunk doesn't try to authenticate, this is the same with an on-prem 3cx system.

Assuming that you set up the trunks correctly the issue might be that the TCP connection is failing. When the transport is TCP then a connection must be established first before attempting a registration.

If you are still having issues I would also contact Telstra support.

 

[garrick.cobcroft@gsconsul]

Hi Yiannis,

Thanks for the response and clarification.

The explanation around TCP vs UDP transports is the key information I was looking for, this explains the issue and gets me on a path to a working solution. I should reiterate, this installation is a Telstra consumer connection, where the guides relate to Telstra Business and Telstra Enterprise. The consumer connection is just a regular SIP channel much like any other carrier, and doesn't require any additional hardware like the business and enterprise offerings. Nonetheless, I understand it's not supported, so I'l l continue to do my own investigation into the network topology to get it working, and hopefully this will help 3CX to support it in the future.

Moving forward with my current client though, if I were to install a 3CX SBC onsite to authenticate the trunk, and have this link to the 3CX hosted edition, would this be a workable solution? My other option is to take the PSTN output of the Telstra modem into a gateway, then setup the gateway as the 3CX trunk?

Thanks,
Garrick

 

[YiannisH_3CX]

Hi Garrick,

I would recommend using a supported provider for cloud installations to avoid these types or workarounds. I have not tried any of the proposed solutions so I cannot offer an opinion. Perhaps someone else has done it and can assist.

 

[garrick.cobcroft@gsconsul]

Hi Yiannis, yes - that would be the ideal scenario, but unfortunately I have no choice over the provider. The telstra service is pre-existing as part of the Telstra NBN package, so I'm constrained by that. I did try to sway them into splitting the services today, so I could get them onto a Vocus SIP trunk, but in the end it was easier to sell them more hardware.

 

[garrick.cobcroft@gsconsul]

Hi Nick,

While I appreciate what you're saying, unfortunately it's too late to ask the customer to choose another company. I've already rolled out quite a lot of kit for them, unfortunately I was blind sided by the telstra connection as I was just told there were existing SIP trunks in place but given that the whole organisation is non technical, no one could tell me anything about them. Sadly, this is not unusual when dealing with small business.

From our end, we're system integrators, so we're used to building solutions for our customers out of unsupported strategies. With the majority of our suppliers, we work closely with them to turn these solutions into supported solutions for the wider market.

At this stage, I'm happy to get this customer up and running without support, but i do hope 3cx is willing to come onboard and support the solution in the future, Telstra is the largest carrier in Australia, so rightly or wrongly, the majority of our business customers use Telstra as their primary carrier. In addition most small businesses here have well and truly bought into the cloud services model, so the goal is to deliver hosted solutions wherever possible

 

[garrick.cobcroft@gsconsul]

Hi Yiannis & Nick,

I have reverted this site to an on-prem instance of 3CX, in order to have a supported solution for the SIP provider. Following the guide at https://www.3cx.com/docs/sip-trunk/telstra-sip-connect-australia/ still fails to authenticate with the on-prem instance of 3CX. I have also attempted to follow the instructions at https://www.3cx.com/voip-gateways/grandstream-fxo/#h.re6k7p7mwer2 in order to use a gateway instead of a trunk. Again, the gateway is configured in the on-prem installation, but does not authenticate.

Are you able to help now that this is configured as a supported solution please?

Thanks,
Garrick

 

[garrick.cobcroft@gsconsul]

Following up from the gateway solution above, I did realise there was a port missing from the provisioning link for the Grandstream. Updating the link to add port 5000 caused the gateway to reboot, then the 3CX instance registered to the Gateway. I can now make outgoing calls, although the CallerID doesn't seem to be passing through to the gateway. For incoming calls, I can see the call connecting at the gateway, but it doesn't pass through to 3CX???

Cheers,
Garrick

 

[leejor]

I can now make outgoing calls, although the CallerID doesn't seem to be passing through to the gateway. For incoming calls, I can see the call connecting at the gateway, but it doesn't pass through to 3CX???

If , as I believe, Australia uses Bellcore Type Caller ID, then the gateway may be set to send the call to 3CX before caller ID is collected, between the first and second ring.

 

[garrick.cobcroft@gsconsul]

Thanks Leejor, yes. Australia uses Bellcore Caller ID. Although I'm not sure I understand your response correctly. ATM, the call doesn't seem to be passing to 3CX at all. Or, are you saying that if the call is passed through too early, 3CX won't be able to match the call to an inbound rule and therefore won't handle it? Either way, which setting on the gateway would need to be altered to correct this?

 

[garrick.cobcroft@gsconsul]

Further update, by changing the Number of Rings before pickup to 2, the gateway now passes the call to 3CX. However, CallerID isn't passed through, and the gateway doesn't hang up the line on silence detection. I now believe this is a similar issue to https://www.3cx.com/community/threa...australia-with-grandstrean-gxw4104-fxo.82525/

I have sent Grandstream a support ticket to see if I can obtain the updated firmware.

 

[leejor]

re you saying that if the call is passed through too early, 3CX won't be able to match the call to an inbound rule and therefore won't handle it?

If you are expecting to use DID rules, then think again, as a gateway will only be able to send caller ID.
You might want to use a caller ID device to confirm that caller ID is indeed being sent and that the gateway is currently set to detect the correct type.

If the phone line provides it and the ATA has the option, you are best to use/enable CPC Call Party Control, or Open Loop Disconnect (It may be called something else on the gateway). This is an option where phone line power will be removed for a short duration when the far end hangs up. Not all phone companies, and in this case, an ATA, support this, but, if available is more reliable than silence detect..

 

[garrick.cobcroft@gsconsul]

Thanks Leejor. With the DID rules, I was only using these to indentify the incoming calls from the ATA as per the Grandstream Gateway guide:-

Step 6: Inbound Rules​

Analog lines (FXO) can present the calling number but not the called number. Therefore each FXO port is reflected with a fix DID number. This allows you to individually route calls received from FXO 1 to destination A while calls to FXO 2 are routed differently and so on. The mapping is as follows:

• FXO 1 indicates the dialed number: 000000
• FXO 2 indicates the dialed number: 000001
• FXO 3 indicates the dialed number: 000002
• FXO 4 indicates the dialed number: 000003

Create those DIDs within the gateway to allow calls to be routed based on the port the call was received on. General information on how to manage inbound calls can be found here.

I was able to confirm that Telstra wasn't supplying caller ID, so the ATA wasn't receiving it. It looks as though I may have to get a caller ID device to confirm that the gateway is set to detect the correct caller ID format, as eveything else is working now, it's just the caller ID that remains an issue.

Cheers,
Garrick

 

[leejor]

It's been a long time since I used a gateway that was capable of sending a DID equivalent", (some can't), and I had completely forgotten about that feature. Some will also allow you to change the DID number that it sends.

It's always handy, when working with PSTN phone lines, to have a separate caller ID device, to confirm it is even being sent, before tearing out your hair wondering what setting is preventing the gateway from passing it on.