Terminating to SIP

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

 

Direct IP Termination

Domain Termination

[IP1]

SIP Domain (Auto-failover via proxy or SBR)

[IP2] (Secondary)

 

[IP3] (Tertiary)

 

Further advanced SIP routing is offered through use of optional feature toggles for both a custom endpoint URI as well as custom ports to receive your calls on. Examples of SIP in the platform as below:

 

                                               

First Configuration

When configuring your first SIP Address in a new call node, the node will default to be a phone number. This must be removed from the routing if you wish to attempt your SIP Address first. To do this, click ‘Add SIP Address’, then using the 'Move Node' symbol, you must click and drag the SIP Address to replace the phone number line (this will swap them). You can then remove the PSTN configuration option using the ‘x’.



    

Dynamic Userinfo

With Dynamic Userinfo, the user portion of your INVITE is pre-configured to be the inbound number receiving the call. This is handed off in E164 format as below:

 

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

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

 

                                               



Dynamic Userinfo is on by default and is the simplest of configuration options. If you wish to terminate calls like this, ensure that the ‘Add User Info’ box is unticked. Calls will automatically have the SIP header appended with the inbound number. To configure this option, click ‘Add SIP Address’ and insert your IP or domain. A name is also required for reporting purposes.

 

 

Custom Userinfo

If you would like to terminate to a custom URI, this can be done through the ‘Add User Info’ tickbox. When ticked, this will append a new blank field in the call node panel. You can then input any user information you wish to see. this can be any valid option from extensions to names of users, provided you have setup the endpoint to receive calls from us.

 

INVITE sip:123456789@203.134.129.78;user=phone SIP/2.0

INVITE sip:testuri@203.134.129.78;user=phone SIP/2.0


                                                



Custom Ports

You may also control the ports to accept calls on using the ‘Add Port’ tickbox. If you run on the default SIP port 5060, you don’t need to specify the ports as per the example at the start of this guide, both custom UserInfo and custom ports can be used together.

                                               

 

Caller ID Example

The caller ID will be in the From: details of the invite, likewise in the E.164 format:


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

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

 

 

Final Notes

PSTN redundancy can also be used. You can add in your PSTN number to be a failover, either in the same node or as a separate call node/set of routing after the original node.

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 & Port Whitelisting

To ensure connectivity when setting up a new service, please ensure you have whitelisted our IPs & Ports as listed below. All of which originate from GCP (Google Cloud Platform) & our Internal Infrastructure:

SIP Proxies:

  •          35.234.224.96
  •          35.234.224.97
  •          35.234.224.98
  •          103.121.233.21
  •          103.121.232.21

SIP Port: 

  •       UDP 5060


RTP Proxies:

  •          35.234.224.102
  •          35.234.224.103
  •          35.234.224.104

RTP Port: 

  •          UDP 5535-65535

FreeSwitch:

  •          35.234.224.99
  •          35.234.224.100
  •          35.234.224.101          

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

Overview:

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:

  •          NO_ROUTE_TRANSIT_NET
  •          NO_ROUTE_DESTINATION
  •          FACILITY_REJECTED
  •          NORMAL_CIRCUIT_CONGESTION
  •          NETWORK_OUT_OF_ORDER
  •          NORMAL_TEMPORARY_FAILURE
  •          SWITCH_CONGESTION
  •          REQUESTED_CHAN_UNAVAIL
  •          BEARERCAPABILITY_NOTAVAIL
  •          SERVICE_UNAVAILABLE
  •          FACILITY_NOT_IMPLEMENTED
  •          SERVICE_NOT_IMPLEMENTED
  •          RECOVERY_ON_TIMER_EXPIRE
  •          PROTOCOL_ERROR
  •          PROGRESS_TIMEOUT

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

Other

Codecs:

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.

Monitoring:

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.

Troubleshooting:

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.