Invoke transcript control events from websocket handling

requestRealTimeTranscripts() is never called from registerTaskListeners() (repo-wide search only finds this definition), so none of the mapped AQM events actually call ApiAIAssistant.sendEvent(). In normal voice or consult flows the SDK never sends the GET_TRANSCRIPTS START/STOP handshake, which means realtime transcription streaming is never requested for any task.

Useful? React with 👍 / 👎.

Propagate AI feature flags before gating history fetch

fetchHistoricTranscripts() now hard-fails when this.aiFeature is unset, but the new ApiAIAssistant instance created in cc.ts is never given the Profile.aiFeature value loaded during cc.register(); repo search only finds the setter definition. After a standard registration flow, cc.apiAIAssistant.fetchHistoricTranscripts(...) will therefore throw REAL_TIME_TRANSCRIPTION_NOT_ENABLED even for orgs that have realtime transcripts enabled, unless the app discovers and calls the internal setter itself.

Useful? React with 👍 / 👎.

Keep AI feature lookup from blocking agent registration

Including aiFeatureFlagsPromise in this Promise.all() makes /v2/ai-feature a hard dependency of getAgentConfig(), even though parseAgentConfigs() treats aiFeature as optional. In tenants or regions where that endpoint is not rolled out yet, or returns 403/404 for orgs without the entitlement, cc.register() will now reject before the agent can log in, which is a broader regression than just disabling the new transcript feature.

Useful? React with 👍 / 👎.

Resolve live transcript events against interaction IDs

When the websocket sends REAL_TIME_TRANSCRIPTION payloads keyed by conversationId (which this new branch explicitly anticipates), task will still be undefined because taskCollection is written everywhere else by interactionId. In that case the if (task) block is skipped and no transcript event is emitted to the app, so live captions disappear on calls where conversation and interaction IDs differ.

Useful? React with 👍 / 👎.

In that case, shouldn't we be mapping the conversation against the right interaction ID? What are the cases where we can expect conversationId and interactionId to be different?

Keep transcripts running through consult and conference downgrades

Both AGENT_CONSULT_ENDED and PARTICIPANT_LEFT_CONFERENCE are non-terminal in TaskManager: the initiating agent keeps the task after consult end, and conference leave only removes secondary legs. Mapping either event to STOP will therefore send GET_TRANSCRIPTS STOP while the main customer interaction is still active, cutting off live transcription during normal consult/conference flows.

Useful? React with 👍 / 👎.

Guard transcript control requests to telephony tasks

requestRealTimeTranscripts() now runs for every mapped task event without checking the channel. TaskManager also handles chat/email tasks in this same class, and those tasks do receive AGENT_CONTACT_ASSIGNED/wrap-up lifecycle events, so accepting or ending a digital interaction will now call ApiAIAssistant.sendEvent(GET_TRANSCRIPTS, ...) with a non-voice interaction ID. In tenants where the AI endpoint rejects non-telephony interactions, that turns normal digital-task flows into repeated backend failures and noisy error metrics.

Useful? React with 👍 / 👎.

Avoid choosing an arbitrary AI feature row

/v2/ai-feature is fetched as a paginated list, but parseAgentConfigs() always stores aiFeatureFlags.data[0] as the org's feature state. If the API returns more than one resource, the SDK's behavior now depends on backend ordering: a disabled or stale first row will make fetchHistoricTranscripts() reject even when another returned row enables realtime transcripts, and the opposite ordering can expose the wrong feature set after registration.

Useful? React with 👍 / 👎.

Why is this an array? Is it intended to have only one instance of AIFeatureFlags though?

This is how we receive it from the backend so need to read the data in the same manner

In that case, shouldn't we be mapping the conversation against the right interaction ID? What are the cases where we can expect conversationId and interactionId to be different?

Should we emit only one of these events rather? Seems redundant

Yes I can optimize this

Once again, if the CC_EVENTS.REAL_TIME_TRANSCRIPTION is what we receive in payload.type and we emit an event for it, shouldn't we skip sending the event for payload.data.type ?

Would this include the IVR transcripts? Have we tried?

I have tried this API but it just returns older live transcripts. Whichever interactionId you share. Doesn't include IVR trasncripts.

I think the SDK has it's own variation of catalog. Like we did for Mobius during CC SDK initial architecture, can't we put these in the catalog by ourselves?

Discussed this during DSM

Does this mean that the Summaries will be available when the API is ready?

What else would be pending to bring those features in?

Just the API additions would be pending. These also need to invoke the same API: sendEvent with different event name and action and they need to be added as part of APIAIAssistant itself

Handle top-level websocket events without data

This branch now runs when either payload.data?.type or top-level payload.type is present, but it immediately dereferences payload.data.type without null checks. The websocket layer emits top-level events like Welcome/AGENT_MULTI_LOGIN without nested data.type, so this can throw a TypeError and break message handling during connection/registration.

Useful? React with 👍 / 👎.

Require explicit AI feature enablement before sending events

The transcript guard only stops when realtimeTranscripts.enable is explicitly false; if feature flags are absent (for example when /v2/ai-feature returns an empty list and aiFeature is unset), execution still sends GET_TRANSCRIPTS events. That means non-entitled orgs can generate repeated failing backend calls and noisy operational metrics on normal task lifecycle events.

Useful? React with 👍 / 👎.

Block transcript sends until agentId is available

requestRealTimeTranscripts() forwards this.agentId directly to sendEvent(), but task listeners are registered in TaskManager before ContactCenter.connectWebsocket() finishes getAgentConfig() and calls taskManager.setAgentId(...). If a mapped task event arrives during that registration window (for example while hydrating an already-active interaction), the SDK sends transcript control with an undefined agent ID, so the backend request fails and transcript START/STOP is dropped for that task.

Useful? React with 👍 / 👎.

Once again, if the CC_EVENTS.REAL_TIME_TRANSCRIPTION is what we receive in payload.type and we emit an event for it, shouldn't we skip sending the event for payload.data.type ?

Emit task-specific event type before wrapper type

This now prefers the websocket envelope payload.type when re-emitting task events, but routing task messages carry a top-level wrapper type (typically RoutingMessage) while the actionable event is in payload.data.type. In those normal payloads, task listeners subscribed to backend events (including REAL_TIME_TRANSCRIPTION) will stop firing because they receive RoutingMessage instead of the CC event name.

Useful? React with 👍 / 👎.