SIP Trunking

This document provides an overview of Sinch SIP trunking service.

Infrastructure upgrade

We are in the process of upgrading our SIP infrastructure to enhance performance, reliability and scalability.

Please see documentation sections called "Upgraded infrastructure".

Regions upgraded currently: Europe

Migration will continue in the coming quarters, and we will provide updates beforehand.

Overview

When using Sinch for voice calling, the Sinch platform can be seen as a big telephony switch. It receives incoming phone calls (also known as incoming call “legs”), sets up outgoing phone calls (also known as outgoing call “legs”), and bridges the two. In Sinch SIP trunking service the incoming call legs and outgoing call legs is to your own SIP infrastructure such as a SIP IP-PBX, SBC or similar equipment. Using SIP trunking together with Callback API you can combine all different types of incoming calls and outgoing calls the Sinch platform supports, including for example Call recording and conference rooms.

Use cases

SIP legs are handled with Callback API or via a Static SIP trunk configuration.

Static SIP trunk

A Static SIP trunk consists of SIP termination, SIP origination or both flows combined. The most common use case is to configure a SIP trunk to handle below flows:

• SIP termination to PSTN.
• PSTN to SIP origination.

Each flow needs its own app configuration in the Sinch Build Portal. How this is configured is described under SIP termination, SIP origination and Application config sections below.

SIP trunk with API Callback

If you need more control or advanced calls flow, you can instruct a call to be connected to your SIP server by responding to the Incoming Call Event callback with the ConnectSIP action. The Callback could handle both SIP termination and SIP origination.

SIP termination

Sending calls to Sinch platform from your SIP infrastructure

SIP-terminated calls are calls that are being routed from your SIP infrastructure to the Sinch platform through a SIP interconnection/trunk.

Termination URIs

Sinch operates voice services in multiple geographical regions. You can configure your SIP infrastructure to use any of the following Sinch geographical locations:

Upgraded infrastructure

Europe: euc1.vp.sip.sinch.com

Original infrastructure

North America: use1.sip.sinch.com

South America: sae1.sip.sinch.com

Southeast Asia: apse1.sip.sinch.com

Australia: apse2.sip.sinch.com

The above FQDNs provide redundancy. Use these as a Termination SIP URI in your communications infrastructure to direct SIP traffic towards Sinch. For each region there are several IP addresses used for reliability purposes (see current IP address/CIDR block in allowlists section). Each of these IP addresses represents a unique public edge for our SIP Trunking services, distributed across multiple Availability Zones.

Both UDP and TCP are supported for calls terminating to Sinch.

• If you can't use FQDNs, reach out to support@sinch.com.

Once the call arrives in the Sinch platform, your backend will get an Incoming Call Event callback, notifying of the incoming call. You can control how you would like the call to be connected by responding to this event. For details on how and what you can respond, check out Callback API. If no callback is specified in Sinch Build Portal, Sinch will try to terminate your call to PSTN using To address in your incoming SIP message as destination phone number.

Make sure that any phone number sent via SIP to Sinch is always E.164-formatted (e.g +12345678900).

Authentication

In order to use a trunk for termination it must have a Termination SIP URI and at least one authentication scheme, see below.

You need to authenticate your SIP infrastructure to make outbound calls via the Sinch SIP trunk:

Upgraded infrastructure

Host: euc1.vp.sip.sinch.com

Username/Authentication name: Your Sinch Application Key

Password: Your Sinch Application Secret

Realm: euc1.vp.sip.sinch.com

Original infrastructure

Host: {region}.sip.sinch.com

Username/Authentication name: Your Sinch Application Key

Password: Your Sinch Application Secret

Realm: sip.sinch.com

Allowed caller ID number (CLI) for terminating calls

You must specify a caller ID number that corresponds to a Sinch DID on your account or a phone number verified in your Sinch Build Portal.

SIP termination example

Example SIP INVITE sent to Sinch with SIP termination:

Upgraded infrastructure

> Request-Line: INVITE sip:+12345678900@euc1.vp.sip.sinch.com SIP/2.0
>
> From: "+19876543210" <sip:+19876543210@euc1.vp.sip.sinch.com>;tag=0c1e59a1af
>
> To: <sip:+12345678900@euc1.vp.sip.sinch.com>
>
> Contact: "+19876543210" <sip:+19876543210@10.186.9.38:51103;ob>

Original infrastructure

> Request-Line: INVITE sip:+12345678900@euc1.sip.sinch.com SIP/2.0
>
> From: <sip:+19876543210@euc1.sip.sinch.com>;tag=as09cb5a21
>
> To: <sip:+12345678900@euc1.sip.sinch.com>
>
> Contact: <sip:+19876543210@52.214.25.57:5060>

SIP origination

Receiving calls from Sinch platform to your SIP infrastructure

You can route any type of call from the Sinch platform to your SIP server.

There are two options for routing calls: SIP forwarding and Callbacks.

SIP forwarding

You can automatically forward calls to your SIP server using the SIP forwarding option in the Sinch Build Portal (setting available under: Voice and Video >> Apps >> Settings >> Handle call events with >> SIP Forwarding).

To Configure SIP forwarding see below SIP URIs options.

Valid SIP URIs

> sip:22444032@213.213.1.213
>
> sip:22444032@yoursipserver.com
>
> sip:22444032@yoursipserver.com:5061
>
> sip:22444032@yoursipserver.com:5061;transport=tls - optionally provide transport protocol: udp (default), tcp, or tls
>
> sip:{number}@yoursipserver.com - {number} will be replaced by the Inbound Number connected to each call

X-headers

If you want a private header in incoming calls to your SIP infrastructure use callHeaders property in ConnectSip action in your callback response.

Example of ICE response:

{
  "action": {
    "name": "connectSip",
    "callHeaders": [
      { "key": "X-My-Private-Header-1", "value": "bar" },
      { "key": "X-My-Private-Header-2", "value": "qux" }
    ]
  }
}

Please note that SIP header names will be prepended with X-, if missing (for example My-Private-Header => X-My-Private-Header).

Limitations:

• The maximum size of private SIP headers is 1024 bytes
• Max length of header name is 50 characters

SIP origination example

Example SIP INVITE sent to your SIP infrastructure:

Upgraded infrastructure

> Request-Line: INVITE sip:+123456789@52.214.25.57:5060;transport=udp SIP/2.0
>
> Via: SIP/2.0/UDP 206.146.136.0:5060;branch=z9hG4bK04d7
>
> From: <sip:+46733478561@18.194.168.245>;tag=as386cfb27
>
> To: <sip:+123456789@52.214.25.57:5060;transport=udp>
>
> Contact: <sip:+46733478561@206.146.136.0;did=27e.fecc2a1>
>
> X-My-Header: This is my header

Original infrastructure

> Request-Line: INVITE sip:+123456789@company.com SIP/2.0
>
> Record-Route: <sip:18.184.175.4;ftag=as386cfb27;lr=on>
>
> Via: SIP/2.0/UDP 18.184.175.4:5060;branch=z9hG4bKd43d.c0cbe68202c12a896a67e9451d13adc2.0
>
> From: <sip:+46733478561@18.194.168.245>;tag=as386cfb27
>
> To: <sip:+123456789@52.214.25.57>
>
> Contact: <sip:+46733478561@18.194.168.245:5060>
>
> X-My-Header: This is my header

Application configuration

Static SIP trunk

Add one application for SIP termination. This application's key and secret is used for SIP authentication. Add one application for SIP origination. On this application SIP forwarding should be configured and number(s) be assigned.

SIP trunk with Callback

Configure one application with a Callback URL set. This application could handle both SIP termination and SIP origination call flows.

IP allowlisting

You must allowlist ALL of Sinch's IPs, subnets and ports on your firewall for SIP signalling and RTP media traffic.

SIP

You need to allow your SIP server to receive traffic from those IPs and subnets (CIDRs). Sinch strongly recommends that you allowlist all of its IP addresses and subnets.

Italic letters in table below represent upgraded infrastructure. Please pay attention to that subnet 206.146.X.0/28 covers IP range 206.146.X.0 - 206.146.X.15. All IPs in that range need to be whitelisted.

Ports

5060 (UDP/TCP)
5061 (TCP/SIP over TLS)

RTP

Original infrastructure

Sinch dynamically scales its media resources, so there is no fixed set of IP addresses from which RTP media traffic originates. However, media always comes from the same port range.

RTP ports: 10000–60000 (UDP)

Upgraded infrastructure

Our new infrastructure has static IPs for media resources.

RTP ports: 10000–60000 (UDP)

Codecs

Sinch currently supports the following codecs:

• G.711u
• G.711a
• Opus
• G.729

Secure SIP trunk

Sinch offers support for encryption to ensure that the call media and associated signaling remains private during transmission.

SIP Signaling Encryption (TLS)

Sinch supports TLS (Transport Layer Security) to encrypt SIP signaling between your SIP infrastructure and Sinch.

Sinch recommends using TLSv1.2

Supported TLS Cipher Suites

Secure trunking supports TLSv1.2 with these cipher suites:

Note: If your equipment does not support these cipher suites, contact Sinch support.

Media Encryption (SRTP)

SRTP provides a framework for encryption of RTP & RTCP. SRTP is offered and accepted when TLS is used as transport for your signaling.

Supported SRTP Cipher Suites

Certificate Requirements

Sinch uses certificates issued by Let’s Encrypt.
To ensure successful TLS connections, install the Let’s Encrypt root and intermediate certificates on your SIP devices.

How to install:

1. Download the root and intermediate certificates from Let’s Encrypt Certificates .
2. Follow your device vendor’s instructions to import these certificates.

Tip: If you experience certificate errors, verify that your device’s trust store is up to date.

Troubleshooting

• No SIP response: Check that Termination SIP URI host is the FQDNs and not the SIP proxy IPs.
• 403 Forbidden: Check your SIP credentials and authentication realm.
• TLS handshake failures: Verify your device trusts Let’s Encrypt root certificates.
• One-way audio: Ensure RTP ports (10000–60000 UDP) from any IP are open on your firewall.