A Look at What Changed in Voice Live SDK 1.2.0

Microsoft Foundry's Voice Live API is an API for building agents that converse using voice. Its .NET SDK (Azure.AI.VoiceLive) had reached version 1.2.0, so I wanted to take a look at the available features and decided to investigate. In the previous article, I wrote that, as of SDK 1.1.0, "because the official SDK cannot select 2026-06-01-preview, the only way to try the latest preview is to call the API directly." However, with 1.2.0, that premise has changed.

In terms of their respective roles, functionality tends to be implemented in the API first, including through preview releases, while the SDK appears to catch up with the API afterward. The API itself, however, generally has few constraints on the development language or similar factors, as long as there is a mechanism for making API calls. On the other hand, many parts, such as messages, must be constructed manually, which can be somewhat troublesome.
When the SDK is provided, its biggest practical benefit is that features that previously could only be tested by calling the API directly can now be implemented in just a few lines of code. These include creating an avatar from a photo, receiving avatar video over WebSocket, MCP, and interim responses—short utterances made while waiting for a tool.

This article introduces the API versions that can now be selected in SDK 1.2.0, the types that have been added, a classification of features for which the SDK has no types, and migration from 1.1.0.

This article will serve as the foundation for the Voice Live feature-explainer series that will follow. In subsequent articles, we will explore the features one by one on top of SDK 1.2.0 and API 2026-07-15 (GA).

The code used for testing is available here (it already supports SDK 1.2.0).

API Versions Selectable from the SDK

The .NET SDK uses VoiceLiveClientOptions.ServiceVersion to select the API version to connect to. The options available in 1.1.0 and 1.2.0 are as follows.

ServiceVersion	API version	Category	1.1.0	1.2.0
V2025_10_01	2025-10-01	GA	○	○
V2026_01_01_PREVIEW	2026-01-01-preview	preview	○	○
V2026_07_15	2026-07-15	GA	-	○
(None)	2026-06-01-preview	preview	-	-
V2026_07_15	2026-07-15	GA	-	○

2026-06-01-preview is not included in 1.2.0 either. In other words, the point that "the June version cannot be selected from the SDK" remains unchanged; it would be more accurate to say that most of the features of the June version are now available from the SDK as GA (2026-07-15).

The API version can only be specified when creating VoiceLiveClientOptions, and cannot be changed when starting a session. When changing versions, recreate the options and client. For example, begin by writing the following:

SDK Support for Features Available on 2026-07-15

The API reference for 2026-07-15 has been published on MS Learn.

The key points of What's new are as follows:

• Compared with the 2026-06-01-preview, the only addition is the session's expires_at (the session validity period determined by the server)
• The June release's native voice, client EC reference, streaming text input, parallel tool calls, and hosted agent invocation remain usable in 07-15
• Smart turn detection and WebRTC remain in preview

Comparing this with the contents of SDK 1.2.0, support for each feature is as follows. In the SDK column, ○ means it can be written with types, △ means types are available but it is cumbersome to write, and × means it cannot be written with the SDK (call the API directly).

Feature	API 2026-07-15	SDK 1.2.0	How to write it with the SDK
Photo avatar (including scene)	○	○ (type support since 1.1.0)	Can be written with types
WebSocket video	○	○ (type support since 1.1.0)	Can be written with types
Personal voice / avatar-sync voice	○	〇 (typed since 1.1.0)	Can be written using types
Semantic EOU / Auto-truncation	〇	〇 (typed since 1.1.0)	Can be written using types
MCP	〇	〇 (added in 1.2.0)	AllowParallelToolCalls
Parallel tool calls	〇	〇 (added in 1.2.0)	AllowParallelToolCalls
Hosted agent invocation	〇	〇 (added in 1.2.0)	InvokeInput and ServerEventResponseInvocationDelta
Session expiration (expires_at)	〇 (added on 07-15)	〇 (added in 1.2.0)	ExpiresOn
Interim response	〇	△	Create a type, write it to BinaryData, and pass it
client EC reference	〇	△ (added in 1.2.0)	The configuration can be written using types, but the reference audio is created on the app side
native voice / streaming text input	〇	× (the type is internal)	Call the API directly
foundry_agent tool	〇 (from 2026-04-10)	× (no type)	Call the API directly
smart turn detection / WebRTC audio connection	preview	×	Call the API directly (specify the preview version)

With the sample SDK console, we were able to verify the following 10 features marked 〇 in the table on physical devices on 2026-07-15.

Photo avatar / Photo avatar + scene / WebSocket video (response.video.delta) / azure-personal voice / Semantic EOU (multilingual) / Auto-truncation / MCP server / Interim response / Parallel tool calls / avatar-sync voice

The 〇△× in this table change each time the SDK catches up. Features that were tested by directly calling the API using the June version have moved to the SDK side now that they are GA and supported in 1.2.0. I think foundry_agent, which currently calls the API directly, will also move to 〇 once the SDK supports it.

What changed since 1.1.0

I had thought that all the features from the June release had come into the SDK at once in 1.2.0, but when I compared the types in 1.1.0 and 1.2.0, only six types had been added (no types were removed). In fact, the types for photo avatar, WebSocket video, interim response, and MCP had already been included starting with 1.1.0.

The reason I had judged that they could not be tested "through the SDK" even though the types existed in 1.1.0 was that, even when the types existed, I could not select an API version that would return those features.

An easy-to-understand example is WebSocket video. The ServerEventResponseVideoDelta type existed in 1.1.0, but response.video.delta was not included in the latest server event, 2026-01-01-preview, that could be selected in 1.1.0. In other words, there was a type for receiving it, but no way to connect it to a version that would send it.

What changed in 1.2.0 was not the types, but the ability to connect to the GA versions, 2026-04-10 / 2026-07-15. As a result, the types that had been included since 1.1.0 became actually usable.

During the 1.1.0 era, testing these required calling the API directly, but now they can be implemented in just a few lines of SDK code. For example, an avatar created from a photo only requires assembling the type and placing it in Avatar.

The details of each feature will be covered one by one in the rest of this series.

List of types added in 1.2.0 and types that have been present since 1.1.0

How it was determined: We extracted the lists of types and members from the XML documentation bundled with the NuGet package and compared the differences between versions. Since internal types also appear in the XML, visibility was confirmed using the assembly metadata (reading TypeAttributes with System.Reflection.Metadata).

Types added in 1.2.0	Corresponding feature	Visibility
EchoCancellationReferenceSource	client EC reference	public
ServerEventResponseInvocationDelta	hosted agent invocation	public
AzureRealtimeNativeVoice	azure-realtime-native voice	internal
AzureRealtimeNativeVoiceName	Same as above	internal
ClientEventInputTextDelta	streaming text input	internal
ClientEventInputTextDone	Same as above	internal

The following were added as members rather than as types.

• ServiceVersion.V2026_04_10 / V2026_07_15
• VoiceLiveSessionOptions.AllowParallelToolCalls (parallel tool calls)
• AudioEchoCancellation.ReferenceSource / Channels (client EC reference)
• ResponseCreateParams.InvokeInput (hosted agent invocation)
• VoiceLiveSessionResponse.ExpiresOn (expires_at)

The following types have been present since 1.1.0.

Feature	Type (present since 1.1.0)
Photo avatar	AvatarConfigKind.PhotoAvatar / PhotoAvatarBaseMode / SceneParams
WebSocket video	AvatarOutputProtocol / ServerEventResponseVideoDelta
Interim response	LlmInterimResponseConfig / StaticInterimResponseConfig
MCP	VoiceLiveMcpServerDefinition / McpApprovalKind
Personal voice / avatar-sync voice	AzurePersonalVoice / AzureAvatarSyncVoice
Semantic EOU	AzureSemanticEouDetectionMultilingual and others
Auto-truncation	AzureSemanticVadTurnDetection.AutoTruncate

Notes on writing with the SDK

Even in 1.2.0, there are still features that cannot be used straightforwardly through the SDK. The important point here is that the absence of a type in the SDK and the feature being in preview are separate matters. We will look at the items marked × and △ in the feature table, grouped by reason.

Features that cannot be implemented with the SDK

foundry_agent tool (the API is GA, but there is no type in the SDK)

The foundry_agent tool, which calls a Foundry agent as a session tool (the chat-supervisor pattern, as the official documentation calls it), is already defined in the 2026-04-10 (GA) reference. Nevertheless, there is no type for it in SDK 1.2.0.

This is not because it is a preview; the SDK implementation simply has not caught up with the API. If you specify it in JSON in the tools parameter of session.update, it can be used through the GA API. In this series, too, I plan to write only this installment by calling the API directly.

Native voice and streaming text input (the API is GA, but the types are internal)

Four of the six types added in 1.2.0 are internal.
The types AzureRealtimeNativeVoice (native voice) and ClientEventInputTextDelta / Done (streaming text input) are present in the SDK, but they cannot be used from applications.
As of 07-15, both are described as GA features that "remain available," so using them requires calling the API directly.

Smart turn detection and WebRTC (preview in the API as well)

The What's new section for 07-15 explicitly states the following.

Smart turn detection and WebRTC remain in preview.
― Voice Live 2026-07-15 API Reference

The endpoint-of-utterance (EOU) detection types in SDK 1.2.0 are also limited to the three semantic types (AzureSemanticEouDetection / ...En / ...Multilingual; the model names sent are semantic_detection_v1 / _en / _multilingual), and there is no type corresponding to smart turn detection.

Because it is officially a preview and is also absent from the SDK, this is a "feature provided as a preview."When 2026-06-01-preview is specified by calling the API directly, smart turn detection worked on a physical device.

Things to be careful about when calling the API directly

If you implement the features covered so far using the API, you will have to write the parts that the SDK was handling yourself.

• You have to construct the JSON for messages (such as session.update) yourself. All key names are in snake_case, which is easy to get wrong when writing them by hand.
• For preview features, specify a preview version (such as 2026-06-01-preview) as the API version to connect to.
• Some features, such as client EC reference, are enabled through a query parameter at connection time (&features=client_ec_reference:true).

Features for which types exist but are difficult to implement

Interim response

For interim response, which makes the system say a short utterance such as “Let me check” while waiting for a tool call, there is a type called LlmInterimResponseConfig for configuration. However, the type of VoiceLiveSessionOptions.InterimResponse, which receives it, is BinaryData.

Therefore, you have to construct it using the type, then serialize and pass it yourself.

SdkFeatureCatalog.cs (excerpt)@@

var interim = new LlmInterimResponseConfig { Triggers = { InterimResponseTrigger.Tool, InterimResponseTrigger.Latency }, LatencyThreshold = TimeSpan.FromMilliseconds (2000), Model = "gpt-4.1-mini", Instructions = "Say a short, natural filler in the user's language while you wait.", MaxCompletionTokens = 50 }; // The setting can be written using a type, but since the receiving side uses BinaryData, write it out and pass it options.InterimResponse = ModelReaderWriter.Write(interim);

By using ModelReaderWriter.Write, the key names in the JSON that is actually sent (all snake_case, such as interim_response / llm_interim_response) will be output correctly. Since it is easy to mistype key names when writing JSON by hand, it is safer to use the type whenever possible.

client EC reference

The client EC reference feature uses the sound actually played through the speaker, rather than the server's internal TTS, as the reference for echo cancellation. Since EchoCancellationReferenceSource and AudioEchoCancellation.ReferenceSource / Channels were added in 1.2.0, the setting itself can be written using a type.

However, the audio being sent must be stereo PCM with the "microphone" and the "actual playback sound" interleaved. Synchronizing this reference audio in time is difficult, so even when a type is available, most of the implementation will be on the app side. We will also discuss adding &features=client_ec_reference:true when connecting in more detail in the session on audio input quality.

Points to note when handling types

Here are three points that gave me trouble while working with 1.2.0. All of them compile, so they are easy to overlook.

Types for video and audio Delta

The audio's SessionUpdateResponseAudioDelta.Delta is decoded BinaryData, whereas the video's ServerEventResponseVideoDelta.Delta remains a base64 string. IntelliSense describes both as "base64-encoded", so they cannot be distinguished by the description alone. Check the type to determine which it is.

VoiceLiveAssistant.cs (excerpt)

case ServerEventResponseVideoDelta videoDelta: // Unlike audio, it arrives as a base64 string, so decode it yourself byte[] frame = Convert.FromBase64String(videoDelta@@.Delta); webSocketVideo.WriteFrame(frame); break;

AzureAvatarSyncVoice constructor

The AzureAvatarSyncVoice constructor accepts a base model (PersonalVoiceModels). However, because PersonalVoiceModels can be implicitly converted from a string, passing an avatar name will still compile, and the avatar name will be sent as the model name.
Put the avatar name in AvatarConfiguration's Character (with Customized = true).

semantic EOU and smart turn detection

Both semantic EOU and smart turn detection are nested under VAD's end_of_utterance_detection, so their configuration structures are very similar. In the sample SDK console as well, semantic EOU was initially sent under the name "smart end-of-turn" (it has now been renamed to semantic_eou).

semantic EOU and smart turn detection are different things. In SDK 1.2.0, it is semantic EOU that is available.

Migration from 1.1.0 to 1.2.0

Code changes

Migrating from 1.1.0 to 1.2.0 is easy. In the sample, simply updating the package version was enough for the build to succeed, and all tests passed. Transitively, the Azure.Core dependency was upgraded from 1.57.0 to 1.61.0, and System.ClientModel 1.15.0 was added.

The Azure.Core (1.61.0) that SDK 1.2.0 depends on contains credential types such as DefaultAzureCredential. If you continue to reference an older Azure.Identity (1.14.2 in the sample), the same types will be defined twice, resulting in CS0433. In that case, remove the reference to Azure.Identity. In newer versions of Azure.Identity (such as 1.21.0), the types appear to have been moved to Azure.Core.

Breaking changes from the 1.1.0 beta

When upgrading from a 1.1.0 beta (such as 1.1.0-beta.4), you will encounter types whose names changed between the beta and GA. Since 1.0.0 did not have types for MCP or avatar kinds to begin with, only people who used them during the beta prior to GA are affected. The following three issues were fixed in the sample.

1.1.0-beta.4	1.1.0 (GA) and later
MCPApprovalType	McpApprovalKind
AvatarConfiguration.Type	AvatarConfiguration.AvatarKind
Pass the URL as a string	Pass a System.Uri

SdkFeatureCatalog.cs (excerpt)

options.Tools.Add(new VoiceLiveMcpServerDefinition("deepwiki", new Uri(url)) { RequireApproval = new RequireApprovalOption(McpApprovalKind.Never) });

Summary

• With SDK 1.2.0, you can now select 2026-04-10 / 2026-07-15 (both of which are GA). You cannot select 2026-06-01-preview.
• What changed in 1.2.0 was not the types themselves, but the fact that the types that had existed since 1.1.0 are now connected to a GA version that can actually be used.
• Six types were added in 1.2.0, four of which are internal.
• Features that cannot be implemented with the SDK fall into two categories: those whose APIs are GA but are not yet supported by the SDK (foundry_agent, native voice, streaming text input), and those whose APIs are still in preview (smart turn detection, WebRTC).
• Types exist for interim response and client EC reference, but writing them is laborious.
• If a feature is GA and its type is exposed in the SDK, use the SDK; otherwise, call the API directly.
• It was possible to migrate from 1.1.0 to 1.2.0 without modifying the code.

From the next installment onward, we will use SDK 1.2.0 + 2026-07-15 as the foundation and cover the features one by one.

Series Structure

Episode	Theme	Can it be written with SDK 1.2.0?
1	Filling in the agent’s “gaps” (semantic EOU / auto-truncation / interim response)	〇
2	Improving voice input quality (noise reduction / echo cancellation / client EC reference)	△ client EC reference requires you to create your own reference audio
3	MCP server tools and parallel tool calls	〇
4	Calling a Foundry agent as a tool (foundry_agent)	× Direct API call
5	Personal Voice (already released)	〇
6	Choosing between avatars (standard / photo / video)	〇
7	WebSocket video and WebRTC	〇
Extra	Connecting to WebRTC audio connections with SIPSorcery for .NET	× Direct API calls (preview)

Reference links

• Voice Live 2026-07-15 API reference
• Voice Live 2026-04-10 API reference
• How to use the Voice Live API
• Azure.AI.VoiceLive 1.2.0 (NuGet)
• VoiceLiveAPISamples (GitHub)
• Foundry Tools - Voice Live trends (2026-08)