SIP Trunking

This document provides a overview of Sinch SIP trunking service.

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.

Sending calls to Sinch platform from your SIP infrastructure (SIP-terminated calls)

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

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

Europe: euc1.sip.sinch.com

North America: use1.sip.sinch.com

South America: sae1.sip.sinch.com

Southeast Asia: apse1.sip.sinch.com

Australia: apse2.sip.sinch.com

For redundancy, Sinch uses the above FQDNs. Each of these domains will return to you at least one active and working SIP endpoint to which you can send your traffic. Use these FQDNs as a Termination URI in your communications infrastructure to direct SIP traffic towards Sinch. For each region we've 2 IP addresses that are used for reliability purposes (see IP address in allowlists section). Each of these IP addresses represents a unique public edge for our SIP Trunking services, distributed across multiple Availability Zones for reliability. Sinch strongly recommends to use FQDN for addressing traffic towards Sinch. If using an FQDN is not possible, make sure you are not restricted to use only one single IP address. Make sure to utilize all IP addresses and failover in case one IP is not responding.

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 dashboard, Sinch will try to terminate your call to PSTN using To address in your incoming SIP message as destination phone number.

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

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 dashboard. If this isn't set, Sinch will set private as your caller ID number going out to PSTN network.

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

Authentication

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

Host: {region}.sip.sinch.com

Username/Authenticationname: Your Sinch Application Key

Password: Your Sinch Application Secret

Realm: Need to match host {region}.sip.sinch.com

SIP termination example

Example SIP INVITE sent to Sinch with SIP termination:

> 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>

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

Receiving calls from Sinch platform to your SIP infrastructure

You can route any type of call from the Sinch platform to your SIP server. You can automatically forward calls to your SIP server using the SIP forwarding option in the Sinch Portal (setting available under Apps >> Voice and Video >> Connect Calls). If you need more control, you can instruct a call to be connected to your SIP server by responding to the Incoming Call Event callback with the ConnectSIP action.

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:

> 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:4690001@52.214.25.57>
>
> Contact: <sip:+46733478561@18.194.168.245:5060>
>
> X-My-Header: This is my header

More Examples

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

IP allowlisting

You must allowlist ALL of Sinch IP addresses and ports on your firewall for SIP signalling and RTP media traffic.

SIP

You need to allow your SIP server to receive traffic from this IP. Sinch recommends that you allowlist all of its IP addresses.

RTP

Sinch scales its media resources on demand and therefore has no fixed set of IP addresses where it sends media from. Media always comes from the same port range though.

RTP ports used: 10000–20000

Codecs

Sinch currently supports the following codecs:

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

Secure SIP interconnect

Encryption ensures that the call media and associated signaling remains private during transmission. Transport Layer Security (TLS) provides encryption for SIP signaling and Secure Real-time Transport Protocol (SRTP) provides encryption for call content/media packets.

The TLS protocol is designed to establish a secure connection between a client and a server communicating over a data network. It's typically used for communication over a insecure network like public Internet.

TLS Specifications:

Secure trunking supports TLSv1 (or higher) with this crypto suites:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-SHA256

NOTE: Sinch recommends using TLSv1.2

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

SRTP Specifications:

Sinch will offer and accept the following crypto suites:

• AES CM 128 HMAC SHA1 80_
• AES CM 128 HMAC SHA1 32_
• AES 192 CM HMAC SHA1 80_
• AES 192 CM HMAC SHA1 32_
• AES 256 CM HMAC SHA1 80_
• AES 256 CM HMAC SHA1 32_
• F8 128 HMAC SHA1 80
• F8 128 HMAC SHA1 32

Sinch Root CA certificate

TLS is used to encrypt SIP signaling between SIP endpoints. In order for this to function properly it's required that certain devices in the network import an SSL certificate. Sinch uses certificates from a CA (Certificate Authority). Our CA for this is Let’s encrypt, make sure to install their Root certificate. For more information about Let’s encrypts root certificates, see https://letsencrypt.org/certificates/.