Terminating to SIP

With regards to SIP termination, the below outlines the different options that can be configured on your numbers within our platform.

Direct IP TerminationDomain TerminationPSTN
Sip:[IP1]:[Port]SIP Domain (Auto-failover via proxy or SBR)+E164 Answer Point
Sip:[IP2]:[Port] (Secondary)

Sip:[IP3]:[Port] (Tertiary)

Please note, the SIP invite will contain the inbound number in E164 format, example as below:

INVITE sip:611300854185057@;user=phone SIP/2.0

INVITE sip:61291906781@;user=phone SIP/2.0

The original caller ID will be in the From: details of the invite:

From: <sip:61426624861@>;tag=3749845943-1288075583

From: “anonymous” <sip:anonymous@>;tag=Kjyg0v1vg2crK

To configure services within the platform you can set the SIP termination in the following syntax:


Note: If you run on the default SIP port 5060 you don’t need to specify the ports as per the example above. Also, if you want to have a PSTN based redundancy you can also specify +E164 formatted answer points after your SIP endpoints/domain.

We would highly recommend working with us to enable this as a feature as you would be able to take advantage of:

  •          Fewer points of failure due to fewer carrier networks included in the call topology.
  •          Greater control at the SBC or PBX level, to create rules based on SIP invite/headers.
  •          Ability to use secondary+ routing options with your SIP IP as the primary and landline/mobiles as redundant lines.
  •          Full call path visibility for advanced troubleshooting and quicker fix time.

IP Whitelisting

To ensure connectivity when setting up a new service, please ensure you have our whitelisted, our IPs are listed below all of which originate from GCP (Google Cloud Platform):

SIP Proxies:


RTP Proxies:




SIP Traffic will come from one of the SIP proxies, however we ask that you whitelabel our Freeswitch IPs as redundancy. We will ensure notification is given of any changes to these IPs.

SIP Failover


Failover to SIP will occur in the following scenarios:

  •          When the host responds with an ICMP Destination Unavailable packet.
  •          When the host does not respond, and timers expire.
  •          When call setup times out.
  •          On specific ITU-T Q.850 codes.
  •          On specific SIP status codes.
  •          ICMP Destination Unavailable

If the destination host is alive but the SIP service is not running, the operating system may respond with an ICMP Destination Unavailable packet.  If this is received, failover will occur immediately.

Transaction Timers:

If the destination host does not respond in a timely manner to the initial SIP INVITE, failover will occur after attempting to retransmit the SIP INVITE.

Retransmission attempts will occur at T+500ms, T+1000ms and T+2000ms.  If no response is received by T+4000ms, failover will occur.

ITU-T Q.850:

If the call attempt is actively rejected by the destination host and contains a ITU-T Q.850 Reason header, the ITU-T Q.850 code will be used to control the failover and the SIP status code will not be used.  Failover will occur on the following codes:

  •          PROTOCOL_ERROR

SIP Status Code:

If the ITU-T Q.850 Reason header is not specified, failover will occur based on the SIP response code.  Failover will occur on certain 4xx and 5xx status codes.

  •          400
  •          406
  •          408
  •          415
  •          416
  •          481
  •          485
  •          500
  •          501
  •          502
  •          503
  •          504
  •          603



We will make all efforts to transcribe audio where possible but we would ask that clients use G.711A Law as this is the preferred codec on our network as well as most other carrier networks in Australia.


We have notifications and monitoring set for most 5XX and 6XX codes for all traffic running through the network. SMS’ are sent to ops team members for repeated failures codes within predefined parameters but customers should still ensure their own due diligence is completed through their own monitoring services as this is a broader network wide monitoring.


If you are having issues with your numbers please when possible provide at least 2 examples with a PCAP (Packet Capture) of the issue and pass this through to support along with the time, date and A/B parties. If your issue is urgent please ensure you call through the issue through after lodging a ticket to ensure that the issue is resolved as soon as possible.