SIP Interface

The service provides a SIP interface compliant with RFC 3261, enabling integration with SIP-based communication systems. Incoming SIP requests trigger events that facilitate interaction with external services, while APIs enable programmatic SIP request handling and call setup.

To ensure high availability and reliability, multiple redundant SIP servers provide the interface. Endpoints should use RFC 3263-defined mechanisms for DNS-based SIP server resolution to determine the appropriate SIP hosts for communication.

Each customer is provided a unique service tenant which is identified by its SIP domain. The SIP Core service provides a DNS service hosting DNS A, NAPTR and SRV records for the SIP domain. The SIP domain is a subdomain under iotcomms.io domain.

To ensure high availability and redundancy, the service operates multiple active SIP servers. Clients should use RFC 3263 to resolve SIP servers dynamically from DNS records. This mechanism ensures that if a client fails to connect to one SIP server, it will automatically attempt the next resolved server, improving reliability and fault tolerance.

• DNS SRV and NAPTR records: Clients supporting RFC 3263 should use the provided DNS SRV and NAPTR records to determine the correct SIP server to connect to.

• Failover Mechanism: If a SIP client cannot establish a connection with a resolved SIP server, it should attempt the next highest-priority server from the DNS response.

• Load Balancing: The DNS configuration distributes SIP traffic across multiple servers, ensuring balanced load distribution.

For clients that do not support RFC 3263, the service also provides A-records with multiple values in DNS. Clients using A-record resolution can attempt connections sequentially to the listed IP addresses to achieve similar failover behavior.

The service supports the following SIP transport protocols:

• UDP (Port 5060)

• TCP (Port 5060)

• TLS (Port 5061, Recommended for security)

• WebSockets (Port 7443, For browser-based SIP clients and WebRTC compatibility)

SIP/TLS

When using SIP over TLS, endpoints must be configured to use sipserver.prod-eu-north-1.iotcomms.io for EU service or sipserver.prod-us-1.iotcomms.io for US service as the outbound proxy to ensure correct certificate validation and secure communication.

SIP/WebSocket

The service supports SIP over WebSocket (RFC 7118), allowing browser-based SIP clients and WebRTC applications to establish SIP signaling over WebSockets.

• Port: 7443

• Use Case: Enables real-time communication directly from web browsers without requiring native SIP clients.

• Security: When using WebSocket Secure (WSS), SIP signaling is encrypted, ensuring secure WebRTC-based communication.

• Compatibility: Works with WebRTC-compatible SIP clients such as JsSIP and SIP.js.

The provisioning of SIP users and credentials is managed through the Device Service. The Device Service provides a centralized way to create, configure, and authenticate SIP devices before they are integrated into the SIP Interface.

• Provisioning Process: Devices must be pre-provisioned in the Device Service before they can authenticate with the SIP Interface.

• Configuration Management: The Device Service ensures that each device has the appropriate settings and credentials, reducing manual configuration errors.

• Security: All credentials and authentication settings are securely stored and managed within the Device Service, ensuring compliance with security and privacy standards.

For more details on device provisioning, refer to the Device Service documentation.

The service supports SIP Digest Authentication and Device Identifier Authentication:

• SIP Digest Authentication

  • Uses usernames and passwords or device identifiers.

  • The authentication realm should be set to the full domain, including the tenant's subdomain.

  • The username should be the provisioned deviceId, excluding the domain part.

• Device Identifier Authentication

  • Authenticates requests based on the from: address.

  • Validates the user part against the provisioned deviceId and the domain part against the tenant’s assigned domain.

  • Must only be used with TLS transport to prevent unauthorized use.

The service provides SIP trunk connectivity to facilitate communication between the SIP Core Service and remote SIP systems. SIP trunks enable seamless call routing for both inbound and outbound calls while ensuring security and network compatibility.

SIP Trunk Authentication and Authorization

• Outbound Calls: Calls to external systems support SIP Digest Authentication, ensuring secure authentication of outgoing requests.

• Inbound Calls: Calls from external systems are authorized using IP address whitelists, allowing only predefined external SIP systems to initiate inbound requests.

Routing Across Isolated Networks

The SIP trunk connectivity service supports routing calls across isolated IP networks that do not have direct IP routing. This is achieved by automatically invoking the RTP relay function to facilitate media exchange.

• Network Segmentation: When configuring a SIP trunk, an optional networkId property can be set.

• Automatic Relay Invocation: If the networkId of the originating and terminating trunk differs, the RTP relay function is automatically enabled to bridge the networks.

By leveraging SIP trunking, businesses can establish secure and scalable connections with external SIP services while ensuring compatibility across diverse network environments.

The service includes a SIP Registrar and Location Service to manage SIP device registrations.

• If no explicit routing rules exist for a SIP URI, the service will check the Location Service to determine if the device has a registered location and route requests accordingly.

• The Registrar function allows SIP devices to register and maintain their availability for call routing.

The service provides NAT traversal support for both SIP signaling and RTP media, ensuring proper connectivity for devices behind NATs.

• SIP Signaling: NAT traversal mechanisms ensure that SIP requests and responses correctly traverse NAT boundaries.

• RTP Media: The service includes RTP relay servers to anchor and facilitate media exchange for devices behind NATs, ensuring seamless voice and video communication.

• Far-End NAT Traversal: The service implements advanced NAT traversal techniques to maintain stable connectivity for SIP devices.

NAT Traversal Requirements

1. TLS Connection Reuse (RFC 5626)

   • To ensure proper signaling towards devices behind NATs, TLS connection reuse must be supported per the SIP outbound extension defined in RFC 5626.

2. Connection Establishment

   • If the communication starts with a SIP message request, the established TLS or TCP connection must be kept open until the incoming SIP messages have been received.

   • If the received SIP messages indicate that a SIP call will be placed or received, the same connection must remain open for subsequent SIP INVITE requests.

3. Connection Keep-Alive

   • If TLS or TCP is used, the device must send CRLF keep-alive messages per section 3.5.1 in RFC 5626 to maintain an active connection.

4. Symmetric Port Use (RFC 3581)

   • If UDP is used, devices must support receiving inbound SIP requests on the same port that the outbound request was sent from, ensuring proper traversal of NAT devices.

By implementing these NAT traversal strategies, the service ensures reliable connectivity for SIP devices, even in complex network environments with restrictive NAT configurations. The service provides NAT traversal support for both SIP signaling and RTP media:

• SIP Signaling: NAT traversal mechanisms ensure that SIP requests and responses correctly traverse NAT boundaries.

• RTP Media: The service includes RTP relay servers to anchor and facilitate media exchange for devices behind NATs, ensuring seamless voice and video communication.

The service supports SIP Recording (SIPRec) as per RFC 7866, enabling SIPRec-compatible clients to perform call recordings.

SIPRec Workflow:

1. When a SIPRec INVITE is received, the service triggers a newCall API request to a remote system.

2. The remote system determines if the call should be recorded.

3. If recording is enabled, the service initiates a recording session and stores the file in temporary storage.

4. Upon call completion:

   • An event is sent to the provisioned SNS topic notifying the recording completion.

   • The system requests an S3 bucket location for storing the recording.

   • The recording is copied to the designated S3 bucket.

   • The system issues a delete command to remove the temporary file.

   • A final event is sent confirming deletion.

Retention Policy:

• Recordings remain in temporary storage for up to 10 days.

• If the DELETERECORDING command is not issued within this period, recordings are automatically deleted to free storage.