Trunk Requirements

SIP trunking is a method of delivering voice communication over IP networks using the Session Initiation Protocol (SIP). It enables the connection between traditional telephony infrastructure (such as the PSTN) and cloud-based services like those provided by iotcomms.io.

The iotcomms.io platform follows a Bring Your Own Trunk (BYOT) model. This means that iotcomms.io does not supply public telephone numbers directly. Instead, customers must procure SIP trunk services—including DID numbers and PSTN connectivity—from a third-party provider of their choice. These trunks are then integrated with iotcomms.io’s SIP Core service to enable both inbound and outbound call capabilities.

The primary purpose of SIP trunking in this context is to allow users to interact with iotcomms.io-powered services from ordinary phones, by dialing phone numbers provided by customer’s SIP trunk provider.

This document outlines the requirements and configuration needed to connect an external SIP trunk with iotcomms.io services.

To enable inbound calls (calls from the PSTN or external SIP network into iotcomms.io), the following must be configured:

• The trunk provider must support SIP server resolution using DNS SRV records in accordance with RFC 3263. Each customer is assigned a dedicated domain name in the iotcomms.io platform, formatted as <customer>.<region>.iotcomms.io. This domain must be used in SIP requests to ensure correct routing.

• Inbound calls must be authenticated using IP address whitelisting. The trunk provider must share the source IP addresses from which SIP requests will be sent. Alternatively, the SIP headers X-Terminating-Trunk-Group-Id and X-Trunk-Key may be used to specify and authenticate against a particular inbound trunk. Header-based authentication must only be used in conjunction with TLS.

• The SIP request URI and the To: header must include the customer-specific domain name. For example, sip:<destination>@<customer>.<region>.iotcomms.io. This is necessary to correctly associate the incoming call with the customer tenant.

• SIP port 5060 is used for SIP over UDP and TCP. Port 5061 is used for SIP over TLS.

iotcomms.io supports DNS-based SIP trunk resolution in accordance with RFC 3263. This is the recommended setup and allows the remote trunk provider to offer redundancy using SRV records. If the trunk provider does not support RFC 3263 resolution, iotcomms.io can create and manage the required SRV records for them. However, it is strongly discouraged to use providers that do not support redundant connectivity.

iotcomms.io supports two authentication models toward the trunk provider:

• SIP Digest Authentication: A SIP username and password can be configured for the trunk and used in outbound requests. * IP Whitelisting: The trunk provider can choose to accept traffic from the iotcomms.io platform based on known source IP addresses.

SIP INVITE requests sent by iotcomms.io to the trunk provider will have the following format:

• The Request URI will contain the destination trunk domain. * The From and To headers will contain the customer-assigned domain (e.g., <customer>.<region>.iotcomms.io) for tenant association and traceability.

The following security practices are mandatory for any SIP trunk connection with iotcomms.io:

• IP Whitelisting: The trunk provider must whitelist iotcomms.io IP ranges (provided in the SIP Interface documentation) to allow inbound call access. Alternatively, SIP digest authentication may be used to secure outbound calls from iotcomms.io.

• TLS and SRTP: Use of SIP over TLS for signaling encryption and SRTP for media encryption is strongly encouraged and represents the best practice. If the trunk provider does not support TLS or SRTP, it is recommended to use the Connectivity Service from iotcomms.io to ensure secure transport.

• Failover Support: The trunk provider should support redundant endpoints and failover strategies. iotcomms.io supports DNS-based failover using SRV record resolution as specified in RFC 3263.