What is the standard approach to resolve the persistent SIP 488 (Not Acceptable Here) errors occurring during high-volume predictive dialing campaigns routed through our Asia-Pacific BYOC infrastructure?
We are managing 15 BYOC trunks, with three specifically allocated for Singapore (AP-SG) operations. The issue manifests exclusively when the predictive dialer attempts to bridge calls via the primary carrier failover path. The initial SIP INVITE is accepted by the carrier gateway, but the subsequent request to complete the call leg returns a 488 error with a body containing Reason: Q.850;cause=21 (Incorrect Information). This happens approximately 40% of the time during peak hours (09:00 - 11:00 SGT).
The environment details are as follows:
- Genesys Cloud Release: R23Q4 (Build 23.4.1)
- BYOC Trunk Type: SIP Trunk (SBC Proxy)
- Carrier: Local SG Tier-1 Provider
- Dialing Strategy: Predictive (Answering Machine Detection enabled)
We have verified the following configurations:
- SIP credentials are valid and registered with 200 OK responses.
- Outbound routing rules prioritize the AP-SG trunk for calls matching the +65 prefix.
- The carrier has confirmed that the called number format (E.164 with leading 0 stripped) is correct.
Steps to reproduce the issue:
- Initiate a predictive campaign with a target list of 500+ Singapore mobile numbers.
- Set the concurrency to 50 simultaneous calls.
- Monitor the Architect flow logs for the ‘Call’ widget.
- Observe that while the dialer reports ‘Connected’, the carrier returns SIP 488 before the customer can answer.
Is there a specific header modification or codec negotiation issue causing the carrier to reject the call after the initial handshake? We suspect the SDP payload might be missing specific attributes required by this specific carrier’s SBC, but the standard Genesys BYOC configuration does not expose granular SDP editing. Any insights into debugging the SIP transaction trace between the Genesys SBC and our carrier would be appreciated.