# SIP Trunking This document provides an 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](/docs/voice/api-reference/voice/callbacks/) you can combine all different types of *incoming calls* and *outgoing calls* the Sinch platform supports, including for example Call recording and conference rooms. ![spider](/assets/spider_all.54755e568056454c2303ed455ce8678ca3b144582ffcc00529ca1d7649cc0291.eeb6343f.png) ## Use cases SIP legs are handled with *[Callback API](/docs/voice/api-reference/voice/callbacks/)* 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](/docs/voice/api-reference/svaml/actions#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. ![Diagram showing SIP termination flow](/assets/spider_sip_termination.bef339a3bc6c754d03bf4849b88ea3ecffe5acf7d8604e89240a7992b8200d53.eeb6343f.png) ### 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: > Europe: euc1.vp.sip.sinch.com North America: use1.vp.sip.sinch.com South America: sae1.vp.sip.sinch.com Southeast Asia: apse1.vp.sip.sinch.com Australia: apse2.vp.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](/docs/voice/api-reference/voice/callbacks/). 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: > Host: {region}.vp.sip.sinch.com Username/Authentication name: Your Sinch Application Key Password: Your Sinch Application Secret Realm: {region}.vp.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: ```shell > Request-Line: INVITE sip:+12345678900@euc1.vp.sip.sinch.com SIP/2.0 > > From: "+19876543210" ;tag=0c1e59a1af > > To: > > Contact: "+19876543210" ``` ## 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. ![Diagram showing SIP origination flow](/assets/spider_sip_origination.a708e4f0eab7a7f9b8a81b2400dcc5e4cb15a59f33a5c8932bb4e187c728faf5.eeb6343f.png) 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 ```shell > 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](/docs/voice/api-reference/svaml/actions#connectsip) action in your callback response. Example of ICE response: ```json { "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: ```shell > 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: ;tag=as386cfb27 > > To: > > Contact: > > 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. #### Ports > 5060 (UDP/TCP) 5061 (TCP/SIP over TLS) div div table thead tr th Geographical location th IP address tbody tr td Europe td 206.146.136.0/28 tr td North America td 206.146.133.0/28 tr td South America td 206.146.138.0/28 tr td Southeast Asia td 206.146.139.0/28 tr td Australia td 206.146.141.0/28 ### RTP Static IPs for media resources. > RTP ports: 10000–60000 (UDP) div div table thead tr th Geographical location th RTP IP address tbody tr td Europe td 206.146.136.128/26 tr td North America td 206.146.133.128/26 tr td South America td 206.146.138.128/26 tr td Southeast Asia td 206.146.139.128/26 tr td Australia td 206.146.141.128/26 ### 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: div div table thead tr th Cipher suites Supported tbody tr td i TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 br TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 br TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 br TLS_ECDHE_ECDSA_WITH_AES_256_CCM br TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 br TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA br TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 br TLS_ECDHE_ECDSA_WITH_AES_128_CCM br TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 br TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA br > **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 div div table thead tr th Cipher suites Supported tbody tr td i AEAD_AES_256_GCM br AEAD_AES_128_GCM br AES_256_CM_HMAC_SHA1_80 br AES_256_CM_HMAC_SHA1_32 br AES_192_CM_HMAC_SHA1_80 br AES_192_CM_HMAC_SHA1_32 br AES_CM_128_HMAC_SHA1_80 br AES_CM_128_HMAC_SHA1_32 br F8_128_HMAC_SHA1_80 br F8_128_HMAC_SHA1_32 br ### Certificate Requirements Sinch uses certificates issued by [Let's Encrypt](https://letsencrypt.org/certificates/). 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](https://letsencrypt.org/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.