SIP INVITE 488 failures breaking bullseye routing expansion in eu-central-1

A/B tests between skills-based and bullseye routing show a 12% SLA drop when the SIP trunk returns 488 Not Acceptable Here on the second INVITE retry. The fallback logic doesn’t kick in because the queue timer resets instead of hitting the preferred agent pool. It’s probably just the codec mismatch in the SDP payload that the last community thread on SIP retransmission windows missed, so the retry loop burns through the 5s timeout before the queue even evaluates the next agent. Doing jack all on the debug side right now.

• Genesys Cloud v2023.12.1
• NICE CXone SIP Trunk integration (v4.2)
• Routing strategy: Bullseye expansion (max 3 hops)

SDP shows PCMU/8000 but the trunk expects PCMA/8000. Console logs show the retry loop hitting the timeout.

import { Injectable } from '@angular/core';
import { firstValueFrom } from 'rxjs';
import { TelephonyService } from '@genesyscloud/client-app-sdk';

@Injectable({ providedIn: 'root' })
export class DesktopCallHandlerService {
 constructor(private telephony: TelephonyService) {}

 async initSipFallback() {
 const stream = await firstValueFrom(this.telephony.getCallStream());
 stream.subscribe(({ event, payload }) => {
 if (event === 'callStateChanged' && payload?.sipCode === 488) {
 this.telephony.forceFallbackToPreferredPool();
 }
 });
 }
}

The 488 Not Acceptable Here triggers on the second INVITE because the trunk rejects the primary codec in the SDP payload. The desktop runtime drops the event before the routing engine evaluates the fallback pool. Hooking into the TelephonyService call stream catches the state change synchronously. You’ll need to push a custom postMessage to the iframe to bypass the default 5s timeout window. The actual fix sits in the trunk configuration though. Reorder the SDP codec list to prioritize G.711 alaw/mulaw before opus. Check the mediaEncoding array in the SIP trunk JSON. It’s usually defaulting to a broad list that confuses legacy gateways.

The event stream fires a bit late sometimes. messy timing. Don’t rely on the queue timer to handle media negotiation failures. Are you overriding the supportedCodecs array in the desktop initialization config? The SDK exposes a setMediaPreference hook that forces the client to negotiate a compatible format upfront. Pass the explicit codec array during the telephony.init() call.