I’m completely stumped as to why the new SIP trunk provisioned via Terraform is failing to register with the Genesys Cloud telephony gateway. The environment is Genesys Cloud v2024-Q3, Terraform Provider v1.12.0. The deployment pipeline runs in GitHub Actions, pushing changes to the staging org. The HCL block for genesyscloud_telephony_providers_edges_sip_trunk looks correct. I have verified the credentials in the secret manager. The remote media port is set to 5060. The local media port is 5061. TLS is enabled. The registration state in the Genesys Cloud UI shows ‘Failed’. The logs show a 403 Forbidden error from the edge. I ran the gccli telephony sip-trunk get command to inspect the resource. The output shows the trunk ID and the status. The status is not registering. I checked the network connectivity. The firewall allows outbound traffic on UDP 5060-5061. The DNS resolution is correct. The hostname resolves to the correct IP. I tried recreating the trunk using terraform taint. The result is the same. The 403 error persists. I compared the configuration with a manually created trunk that works. The manual trunk has the same settings. The only difference is the creation method. The manual trunk registers immediately. The IaC trunk fails. I suspect there is a timing issue with the certificate validation. Or perhaps the edge is rejecting the client certificate before the registration request completes. I added a sleep command in the GitHub Actions workflow. It did not help. I checked the Genesys Cloud API documentation for the SIP trunk endpoint. It mentions that the trunk must be associated with a routing user. I verified the routing user assignment in the HCL. The user exists. The user is active. The user has the correct roles. I am stuck. The error message is not helpful. It just says 403 Forbidden. No details on why. Is there a specific attribute in the HCL that controls the registration behavior? Or is this a known issue with the provider? I have attached the redacted HCL code below. Please let me know if you need more logs.
The way I solve this is by checking if the SIP trunk configuration in Terraform matches the exact certificate requirements for TLS, as a 403 often indicates a trust issue rather than just bad credentials. In my experience with legal hold exports and secure integrations, the certificate chain must be complete and valid. Ensure the certificate attribute in your genesyscloud_telephony_providers_edges_sip_trunk resource points to a valid, uploaded certificate in Genesys Cloud. Also, verify that the remote IP addresses are correctly listed in the remote_ips array. A common oversight is missing the correct port in the remote IP definition or having an expired certificate. Check the certificate status in the admin console under Telephony > Providers > Certificates. If the certificate is self-signed, it might not be trusted by the gateway. Consider using a CA-signed certificate for better compatibility. Additionally, review the firewall rules to ensure port 5061 is open for TLS traffic. The error might also stem from a mismatch between the expected and actual TLS version. Genesys Cloud typically requires TLS 1.2 or higher. Verify that your SIP trunk provider supports this. If the issue persists, enable detailed logging in the Genesys Cloud admin console under System > Logs to capture the exact rejection reason. This can provide clues about whether the issue is related to authentication, authorization, or network connectivity. Sometimes, the Terraform state file might have outdated information, so running terraform refresh before applying changes can help align the state with the actual configuration.